4 ms·
> 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 thre
by tapirl 8y ago
> 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 8y ago> 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 8y agoAh, 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.