Hacker News Reader

Comment by jiggawatts | Hacker News Reader

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.

View on HN

Windows '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/p...

Default locking every process onto a random chiplet doesn't sound like a great plan either.

AFAIK it doesn’t lock them, it just preferentially co-schedules things into a socket.

My 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?

That 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.

Reply on news.ycombinator.com