Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

runtime: NumCPU does not change when process affinity changes #11609

Closed
marcosnils opened this issue Jul 6, 2015 · 7 comments
Closed

runtime: NumCPU does not change when process affinity changes #11609

marcosnils opened this issue Jul 6, 2015 · 7 comments
Milestone

Comments

@marcosnils
Copy link

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

@bradfitz bradfitz changed the title NumCPU reporting incorrect value when process affinity is set runtime: NumCPU reporting incorrect value when process affinity is set Jul 6, 2015
@ianlancetaylor ianlancetaylor added this to the Go1.5Maybe milestone Jul 10, 2015
@ianlancetaylor
Copy link
Contributor

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.

@ianlancetaylor ianlancetaylor changed the title runtime: NumCPU reporting incorrect value when process affinity is set runtime: NumCPU does not change when process affinity changes Jul 10, 2015
@ianlancetaylor ianlancetaylor modified the milestones: Go1.6, Go1.5Maybe Jul 10, 2015
@dominikh
Copy link
Member

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
Copy link
Contributor

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
Copy link

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

ianlancetaylor added a commit that referenced this issue Jul 10, 2015
Update #11609.

Change-Id: Ie363facf13f5e62f1af4a8bdc42a18fb36e16ebf
Reviewed-on: https://go-review.googlesource.com/12022
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
@rsc
Copy link
Contributor

rsc commented Nov 23, 2015

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
Copy link
Member

minux commented Nov 24, 2015 via email

@gopherbot
Copy link

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

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

7 participants