In #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 #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.
| intprocessorsPerPoller= |
| AppContextConfigHelper.GetInt32Config("System.Threading.ThreadPool.ProcessorsPerIOPollerThread",12,false); |
| return(Environment.ProcessorCount-1)/processorsPerPoller+1; |
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.
In #45943, we did a breaking change to have
Environment.ProcessorCounttake 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 #47427, calls out that the code that relies on
Environment.ProcessorCountfor parallelism, should update it to scale better because of reduced return value. However, there is performance sensitive code in IOThreadPool that relies onEnvironment.Processorto decide on the number of "IO completion poller threads" to use in the application.runtime/src/libraries/System.Private.CoreLib/src/System/Threading/PortableThreadPool.IO.Windows.cs
Lines 41 to 43 in 32320b1
On higher core Arm64 machine, had
ProcessorCountreturned 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 by2.25Xon higher core Arm64 machines.