The default is GOMAXPROCS == numCPU and the runtime is optimized and tested for this. There are use cases involving co-tenancy where setting GOMAXPROCS < numCPU tells the OS to limit HW allocation and improves overall throughput when several programs are running concurrently.
Setting GOMAXPROCS > numCPU seems to indicate that the Go scheduler and the OS scheduler are out of sync. Perhaps the delay between the OS knowing a call is blocked and the Go scheduler knowing it is blocked is the root cause. Any insight into why setting GOMAXPROCS > numCPU is a win might lead to improving the Go scheduler or perhaps Go / OS interaction. On Wednesday, December 28, 2016 at 3:41:31 PM UTC-5, Dave Cheney wrote: > > There may be a bug here. IMO the runtime should never try to start more > that numCPUs background workers regardless of the size of GOMAXPROCS as > that'll just cause contention during the GC cycle. > > -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
