runtime: NumCPU does not change when process affinity changes

[marcosnils]

I have a 32 core linux system and suddenly I found that NumCPU() was returning only two. After discussing about this in the slack channel we've realized that the Go process had a CPU affinity and only two processors were assigned to the process.

According to documentation I'd expect NumCPU() to return the amount of logical cores in the system independently of the process affinity. Also this might bring confusion as we've seen NumCPU() returning different values depending on the underlying platform.

Seems like either the docs need to be updated clarifying what NumCPU() does or implementation should be consistent among different platforms (taking into account process affinity or not).

In addition, it seems like Go only performs the check once. If the user changes the CPU affinity, NumCPU won't change

[ianlancetaylor]

I sent http://golang.org/cl/12022 to clarify the docs.

I'm leaving this issue open to consider whether we want to have a way to update the CPU count if somebody changes the CPU affinity. I don't know how often we should check. Perhaps we should leave it entirely up to the program by checking when it calls GOMAXPROCS.

[dominikh]

The problem with CL 12022 is that it's also not accurate. The behaviour isn't consistent across platforms. On Linux, NumCPU respects affinity. On Windows, however, it always returns the number of CPUs in the system, ignoring affinity, and if I remember correctly, the same is true for FreeBSD.

As such, the doc clarification is rather a design decision: Should affinity be considered or not?

[ianlancetaylor]

Yes: affinity should be considered. That design decision was made long ago, and CL 12022 is intended to make that more clear.

If the Windows code does not respect affinity, that is a bug in the Windows support. I don't know anything about affinity on Windows; I encourage you to open a separate issue with appropriate details to fix the Windows runtime. Thanks.

[gopherbot]

CL https://golang.org/cl/12022 mentions this issue.

[rsc]

It sounds like the only part left here is documenting that Go checks the available CPUs at startup and does not rescan them periodically.

[minux]

Note that the windows runtime got fixed (take process cpu affinity into account for NumCPU) by https://golang.org/cl/14742