GOMAXPROCS > num of CPU

Vincent Blanchon

unread,

Dec 4, 2019, 12:24:13 PM12/4/19

to golang-nuts

Hello,

I've read on GitHub (https://github.com/golang/go/issues/20303#issuecomment-329418911) "there are good reasons" to set GOMAXPROCS to > num CPU.

Just out of curiosity, I want to know if someone has an example of it or any good reason to set it up more than the number of CPUs?

Thanks

Serhat Şevki Dinçer

unread,

Dec 5, 2019, 2:33:10 AM12/5/19

to golang-nuts

In runtime it says:

The GOMAXPROCS variable limits the number of operating system threads that can execute user-level Go code simultaneously. There is no limit to the number of threads that can be blocked in system calls on behalf of Go code; those do not count against the GOMAXPROCS limit. This package's GOMAXPROCS function queries and changes the limit.

So normally it does not make sense to increase it beyond available physical "HW threads" (I think this is what you meant with cpu) count (since blocked threads do not count towards this limit).

As long as "active thread accounting" is accurate in the OS, I dont see any reason to set it higher. I think it is easy to test >HWthreads effects with a concurrent cpu-intensive job.

Vincent Blanchon

unread,

Dec 5, 2019, 4:51:50 AM12/5/19

to golang-nuts

Hello Serhat,

Yes, I do not see a use case either. This is why I opened this thread, to know if someone sees a use case since it has been mentioned on GitHub :)

Didier Spezia

unread,

Dec 21, 2019, 5:20:52 AM12/21/19

to golang-nuts

You may be interested in this thread started by the Badger people:

https://groups.google.com/d/msg/golang-nuts/jPb_h3TvlKE/qdoHhxXeAwAJ

Apparently it can be used to increase the throughput of concurrent disk I/O heavy programs.