Ø Any insight into why setting GOMAXPROCS > numCPU is a win might lead to
improving the Go scheduler or perhaps Go / OS interaction.
I’ve found it useful if you happen to have a number of compute-bound goroutines
which don’t reschedule. Setting more processes than CPUs causes the kernel to
do some scheduling for them.
John
John Souvestre - New Orleans LA
From: [email protected] [mailto:[email protected]] On
Behalf Of [email protected]
Sent: 2016 December 30, Fri 09:53
To: golang-nuts
Subject: [go-nuts] Re: too many runtime.gcBgMarkStartWorkers ?
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 [email protected].
For more options, visit https://groups.google.com/d/optout.
--
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 [email protected].
For more options, visit https://groups.google.com/d/optout.
