The Linux kernel has been accidentally hardcoded to a maximum of 8 cores

From what I understand what was limited to 8 cores is the scaling of the preemption delay (min_granularity / min_slice). Again from what I understand that what this is is the window during which a process can not be preempted, so this is only relevant when the scheduler has more tasks to run than available slices (the system is heavily / over - loaded).

I would assume well-administered systems where this would be relevant:

1. Are not overloaded

2. Have the important tasks pinned to avoid migrations

3. Have priorities configured to avoid preempting / descheduling their primary workloads

As such, on a well-administered system this would mostly translate to possibly over-pre-empting low-priority tasks (and most likely not pre-empting anything because the machine is configured with capacity for those ancillary / transient low priority tasks). This may show up during transient overloads, and worsen an already bad situation, but it probably wouldn’t show up during normal operations.

It also doesn’t seem accidental, the maintainers literally slapped an `min(8, …)` on there, so they explicitly designed the scaling to have an upper bound. Maybe it’s a mistake, maybe it’s too low, maybe it should be a tunable, but I’d think it makes sense to not allow the preemption delay to grow infinitely.

One thing I noticed is that min/max functions are tricky to use and it's easily to accidentally do the wrong thing, like in this case

Because you think "you want the minimum (that is, the number should be at least 8) of those numbers to be 8" then you slap min(). And you got it wrong. You should have used max()

i’m doing high performance gamedev on a 7950x with smt off. 16 cores.

i can only use 8 to run the game.

mutex and other synchronization gets highly variable latency if the first 8 cores try to talk to the second 8.

i hadn’t heard of this before i started this game, but apparently it’s well known, and nobody makes a chip with more than 8 cores that can have low variability synchronization.

linux running on 8 cores seems like a potentially good idea. one wants the kernel to have low latency with low variability.

Why? The article show no evidence of this being problematic.

> It can’t be good to reschedule hundreds of tasks every few milliseconds, maybe on a different core, maybe on a different die. It can’t be good for performance and cache locality.

Make a PoC and prove it.