-
Notifications
You must be signed in to change notification settings - Fork 4.8k
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
Update Environment.ProcessorCount
on Windows to take into account the processor affinity mask
#45943
Conversation
… processor affinity mask - Similarly to cases on Unixes where sched_getaffinity is available - If `GCCpuGroup` and `Thread_UseAllCpuGroups` are both enabled, I'm not sure if the `CPUGroupInfo` count of active processors takes affinity into account as the docs are not clear, for now I'm not modifying that path until I can verify it - Otherwise, a process that is started with a specific processor affinity mask still shows full CPU count - This is one of the differences in the portable managed thread pool implementation, which relies on Environment.ProcessorCount, as opposed to the native thread pool, which uses the affinity mask - After this change, in affinitized cases on Windows the behavior is consistent perf-wise with Linux in similar situations: - The portable thread pool uses the same worker thread count as the native thread pool - `Environment.ProcessorCount` returns the number of processors the the process is affinitized to, which may be less than it would have returned before
I don't think this is a good idea. After this change, how would one obtain the processor count, for instance to check whether an affinity mask is applied? For instance, I have a piece of code that uses this property and compares it to the affinity mask to make sure the application is allowed to run on all CPUs. |
@pgrawehr The number of processors that the application can run on can be limited by number of mechanism. Process affinity, job control on Windows and cgroups on Linux are the most common mechanisms. We have found through trial-and-failure that returning the restricted number of processors from this property is the most appropriate behavior that makes most callers work well, and it is what we do on non-Windows systems already.
You can PInvoke the appropriate OS APIs. @kouvel I agree that this is a good change to make, but it needs to be marked as breaking change. |
I think that's bad, because it's again OS dependent. The properties and methods in the |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM, thank you!
@pgrawehr you could make an API proposal, with the template. |
@kouvel, can this be merged? |
I just need to file an issue and document some things for the breaking change process, will try to do that early next week. |
Ok, cool. |
@kouvel when you open that breaking change issue please remove the "needs breaking change doc" label |
…he processor affinity mask Port of dotnet/runtime#45943 Delete some dead code
…he processor affinity mask Port of dotnet/runtime#45943 Delete some dead code
…he processor affinity mask Port of dotnet/runtime#45943 Delete some dead code
…he processor affinity mask Port of dotnet/runtime#45943 Delete some dead code
Port of dotnet/runtime#45943 Delete some dead code
GCCpuGroup
andThread_UseAllCpuGroups
are both enabled, I'm not sure if theCPUGroupInfo
count of active processors takes affinity into account as the docs are not clear, for now I'm not modifying that path until I can verify itEnvironment.ProcessorCount
, as opposed to the native thread pool, which uses the affinity maskEnvironment.ProcessorCount
returns the number of processors the process is affinitized to, which may be less than it would have returned before, similarly to LinuxBreaking change issue: #47427