3 ms·
This sounds like a trivial fix: put the two chiplets into separate processor groups, because that's effectively what they are. This feature was originally abou
by jiggawatts 2y ago
This sounds like a trivial fix: put the two chiplets into separate processor groups, because that's effectively what they are.
This feature was originally about non-uniform memory access (NUMA), but effectively it is "core-to-socket" mapping. If a processor has chiplets on it, then it's effectively sockets-within-sockets. The software needs just a minor update to consider the chiplets to be the scheduling boundary instead of the AM5 socket.
- Dylan16807 2y agoDefault locking every process onto a random chiplet doesn't sound like a great plan either.
- jiggawatts 2y agoAFAIK it doesn’t lock them, it just preferentially co-schedules things into a socket.
- Dylan16807 2y agoMy understanding was that a thread is only eligible to be scheduled in a single processor group at any given time, and that windows will not change the group. Is that wrong?
- Out_of_Characte 2y agoThat WAS correct. They corrected that after realising a 96-core processor has less cores available than a 64-core processor since processor groups split cores evenly.
- Out_of_Characte 2y agoWindows 'processor groups' aren't at all similar to linux NUMA aware scheduling, which is the proper method regardless, There's 64 bits that represent all cores on the system, setting those bits defines how a process is assigned to a core. The 'processor groups' is a hack that keeps the same bitmask that they originally used. Nowadays windows can and will schedule across processor groups as per https://learn.microsoft.com/en-us/windows/win32/procthread/processor-groups https://learn.microsoft.com/en-us/windows/win32/procthread/p...