Ambiguity in what `Environment.ProcessorCount` returns

[kouvel]

We seem to also have ambiguity about what Environment.ProcessorCount returns. According to the docs, it should return "the number of processors on the current machine".

• On Windows without NUMA, it returns SYSTEM_INFO::dwNumberOfProcessors. This sounds correct. I assume that this number cannot change during the process lifetime.
• On Windows with NUMA, it returns CPUGroupInfo::GetNumActiveProcessors. Can this number change during the process lifetime?
• On Unix, with HAVE_SCHED_GETAFFINITY, it returns the process affinity at the process start: https://github.com/dotnet/coreclr/blob/6ce179a17061abbbe9f904f878943a28c8041a62/src/pal/src/misc/sysinfo.cpp#L161
• On Unix ARM and ARM64, it returns _SC_NPROCESSORS_CONF. This sounds correct.
• On Unix on other platforms, it returns _SC_NPROCESSORS_ONLN at the process start. That does not sound right.

cc @janvorli @kouvel

Originally posted by @jkotas in dotnet/coreclr#27543 (comment)

[janvorli]

The comment in Mono repo (https://github.com/mono/mono/blob/6dff5fc81321a4fd9dd493e215d4ace543475054/mono/utils/mono-proclib.c#L760-L880) explains the reasons why we use _SC_NPROCESSORS_CONF instead of _SC_NPROCESSORS_ONLN on ARM.

However, on contrary to Mono, we still use the process affinity at startup if available and that breaks us on Jetson TK1 unless the power management is set to never take CPUs offline. There is an issue #12510 to track that problem.
I am still not sure whether taking the Mono route and ignore the affinity mask on ARM is a good solution. That would basically prevent .NET Core to behave well in containers (we would always report the number of processors on the machine instead of the number of processors assigned to the specific container).
I am currently leaning towards a solution where an environment variable could be used to disable using the affinity (matching Mono behavior) on systems where people hit this problem.

[janvorli]

• On Windows with NUMA, it returns CPUGroupInfo::GetNumActiveProcessors. Can this number change during the process lifetime?

While I believe the number of active processors can change during process runtime on a system that allows hot-pluggin processors, we query that from the system only once at process startup and cache all the topology information. So the value we return from CPUGroupInfo::GetNumActiveProcessors doesn't change during the process runtime.

[jkotas]

I am currently leaning towards a solution

Part of the solution should be updating the documentation to explain what Environment.ProcessorCount actually returns. I think it is reasonable to say that:

• It returns "expected level of parallelism" that the process gets. This meaning is the most common use of this API.
• It is computed at process startup and does not track environment changes (e.g. changes in process affinity)
• It is not safe to use it for optimizations that affect correctness, like skipping locks or memory barriers when ProcessorCount == 1. It is safe to use it for optimizations that affect performance only.

an environment variable could be used to disable using the affinity

An environment variable that lets you set the expected level of parallelism (ie the number that ProcessorCount returns) may be more powerful.

[AntonLapounov]

The documentation has been clarified by dotnet/dotnet-api-docs#6668. I think this can be closed now.