I did some tests: SetProcessAffinityMask (available Windows XP+) and SetProcessDefaultCpuSetMasks (available Windows 11+) kill Windows 11 automatic scheduling. However, if executed again and only passing 0/NULL parameters, the original state can be restored. SetThreadAffinityMask, SetThreadGroupAffinity, SetProcessDefaultCpuSets, SetThreadSelectedCpuSets, SetThreadSelectedCpuSetMasks don't seem to disable Windows 11 automatic scheduling. CreateRemoteThreadEx does not influence Windows 11 automatic...
I did some tests: SetProcessAffinityMask (available Windows XP+) and SetProcessDefaultCpuSetMasks (available Windows 11+) kill Windows 11 automatic scheduling. However, if executed again and only passing 0/NULL parameters, the original state can be restored. SetThreadAffinityMask, SetThreadGroupAffinity, SetProcessDefaultCpuSets, SetThreadSelectedCpuSets don't seem to disable Windows 11 automatic scheduling. CreateRemoteThreadEx does not influence Windows 11 automatic scheduling, if used to launch...
Ok, now I see where my error of thoughts was: On Windows 11, a vanilla process who never touched any affinity settings is assigned to processor groups 0/1/2. So one could create 192 threads and Windows would distribute them over 192 cores. On Windows 11, a process who already moved its threads to individual processor groups would also show up as using processor groups 0/1/2. However, if one would create 192 threads in this situation, they would all stay in one processor group of 64 since Windows...
I think there is some misunderstanding. So the code that counts the cores can return 192 cores in Windows 10 at some conditions. No, it can not. It only could return 64 on Windows 10. If an application wants to use 192 cores on Windows 10, then that application has to manually do all the scheduling work and manually move around its own threads to the processor groups it wants them to run on. (otherwise it will be limited to at most 64 cores in its primary processor group) If any of those 192 manually...
I don't understand. There is no "192-but affinity mask". The affinity mask will always be 64-bit since one processor group can only contain up to 64 logical CPUs. There is no hypothetical affinity mask a process would have if one of its threads would get moved to a different processor group. (the user just cannot set such a value) The feature to spread the threads to different processor groups only exists on Windows 11+ and Windows Server 2022+. On Windows 10, there is no way to ever have the code...
I did not code anything for this, start is a build-in command of the Windows Command Processor (cmd.exe) which allows setting the affinity of the process it launches with /affinity <mask>. (it also has a parameter /node to select the NUMA node, but doesn't appear to work for selecting processor groups) If you don't want to use SetThreadSelectedCpuSetMasks, maybe checking the Windows build number would be better? Windows Server 2022 has build number 20348, Windows 11 started with 22000. The most recent...
I did not code anything for this, start is a build-in command of the Windows Command Processor (cmd.exe) which allows setting the affinity of the process it launches with /affinity <mask>. (it also has a parameter /node to select the NUMA node, but doesn't appear to work for selecting processor groups) If you don't want to use SetThreadSelectedCpuSetMasks, maybe checking the Windows build number would be better? Windows Server 2022 has build number 20348, Windows 11 started with 22621. The most recent...
Using SetThreadSelectedCpuSetMasks allows to define which processor groups a process should run on. On Windows 11, the default value is "all available groups". (or maybe "all groups of one NUMA node", but I don't have a dual-CPU system, so I can't test) The CreateThread function does not allow specifying processor groups. One would need to use CreateRemoteThreadEx (yes, "remote" to create a thread in the current process) and provide process group information in the lpAttributeList parameter. And...