runtime: Arm64: Environment.ProcessorCount returns wrong value on higher core machine

In https://github.com/dotnet/runtime/pull/45943, we did a breaking change to have Environment.ProcessorCount take processor affinity into account on Windows. It works well on x64 machines, but on arm64 machines with higher CPU count, it returns wrong value.

Although https://github.com/dotnet/runtime/issues/47427, calls out that the code that relies on Environment.ProcessorCount for parallelism, should update it to scale better because of reduced return value. However, there is performance sensitive code in IOThreadPool that relies on Environment.Processor to decide on the number of “IO completion poller threads” to use in the application.

https://github.com/dotnet/runtime/blob/32320b11c945c506c7b3d24d4dc16aa9b2119ac9/src/libraries/System.Private.CoreLib/src/System/Threading/PortableThreadPool.IO.Windows.cs#L41-L43

On higher core Arm64 machine, had ProcessorCount returned correct value, I could see that we would create more IO completion threads to handle more concurrent requests. In an internal application, I can see it boosts performance by 2.25X on higher core Arm64 machines.

About this issue

  • Original URL
  • State: closed
  • Created 2 years ago
  • Comments: 19 (19 by maintainers)

Most upvoted comments

Under what API/category should the documentation go to?

Affected APIs should get a note:

I suspect that we may still end up doing more product changes here given the feedback in https://github.com/dotnet/runtime/issues/72441. I would wait for that issue to get resolved before starting on documentation edits.

(If you have access to a Win2022 machine with large number of cores, it would be useful to get answer to https://github.com/dotnet/runtime/issues/72441#issuecomment-1189440332 .)

According to documentation, in Windows 11 processes are no longer constrained to a single processor group by default. I guess that means we should consider UseAllCpuGroups enabled by default, which would allow to avoid this issue.