
Mmap in Go considered harmful - valyala
https://medium.com/@valyala/mmap-in-go-considered-harmful-d92a25cb161d
======
tapirl
> What happens when a goroutine accesses cold data in mmaped file? It stucks
> for a looooong time. During this time it occupies an OS thread from
> GOMAXPROCS threads, so other ready goroutines have reduced number of threads
> to be executed on. This leads to CPU under-utilization.

This is not very true. GOMAXPROCS doesn't determine the number of threads (M)
in Go runtime. It determines the number of logicial processors (P). There may
be more system threads created as needed than GOMAXPROCS.

When a system call is invoked, until it finishes, it is true that the caller
goroutine will be parked with a system thread, however, the thread will detach
itself from a P, so that the P can assign other goroutines (G) to other
threads. So there is no CPU under-utilization.

After the system call finishes, the parking thread will try to find a P to
attach or put the caller goroutine in a queue. So I really think there are
really a little context-switch overheads in calling system calls. (Just a
guess)

~~~
valyala
> When a system call is invoked, until it finishes, it is true that the caller
> goroutine will be parked with a system thread, however, the thread will
> detach itself from a P, so that the P can assign other goroutines (G) to
> other threads. So there is no CPU under-utilization.

True. But major page fault doesn't invoke syscall. Go program just accesses
regular memory inside mmap'ed region while running on logical processor (P).
Go runtime doesn't know anything about the hard page fault, so cannot add an
additional OS thread like in the syscall case.

~~~
tapirl
Ah, so setting GOMAXPROCS with a value larger than NumCPUs is good for the
performance of a program sometimes. Glad that I learned something new. Thanks
for this article.

