This article is clickbait and in no way has the kernel been hardcoded to a maximum of 8 cores.<p>If you read the commit [0], you can see, that a /certain/ scaling factor for scheduling can scale linearly or logarithmically with the number of cores and for calculating this scaling factor, the number is capped to 8. This has nothing to do with the number of cores that can actually be used.<p>[0] <a href="https://github.com/torvalds/linux/commit/acb4a848da821a095ae9e4d8b22ae2d9633ba5cd">https://github.com/torvalds/linux/commit/acb4a848da821a095ae...</a>
If I've understood this article right (possibly not as it's not so clear):<p>* On single core machines the scheduler interval is quite fine grained to ensure responsiveness.<p>* As the number of cores grows, the scheduler interval increases (by default), presumably because there's greater cost to task switching across more cores and the greater number of cores inherently increases the responsiveness anyway.<p>* BUT – and this is the point of the article – above 8 cores, the scheduler interval remains constant rather than increasing further.<p>If I have read it right, then surely that's exactly what you want? If you have done enormously beefy server with hundreds of cores then you don't want a CPU bound task persisting for several seconds! You almost certainly have proportionally more tasks to run and need to keep that interval down. There's presumably also diminishing increases to the cost of switching across more cores (admittedly a logarithmically increasing interval, as mentioned in the article, world also cope with that). And, in any case, a huge server is more likely to have this sort of setting manually tuned.<p>If there is a bug here at all then it's a minor one, nothing like the title suggests.
I'm not well enough versed in the Linux kernel to comment on the post, but as a funny anecdote, 15 years ago, we were developing a system that relied heavily on using as many cores as possible simultaneously.<p>Performance was critical, and we had beefy developer machines (for the time), all with 8 cores. Development was done in C++, and as the project progressed the system performed very well, and more than exceeded our performance goals.<p>Fast forward a couple of years and it became time to put the thing into production on a massive 128 core Windows server. Much to our surprise the performance completely tanked when scaled to all 128 cores.<p>After much debugging, it turned out that the system spent most of its time context switching instead of doing actual work, and because we used atomic operations for message queue functionality (compare & swap), it effectively meant clearing the cache for every core working with/on that piece of heap memory, so every time a task passed a message to something else, it effectively reset the CPU cache, which would then have to be refetched from RAM. This was not (as big) a problem on the developer machines, as there were fewer cores and each task had more work queued up for it, but with 16 as many cores to work with, it simply ran out of tasks to do faster.<p>The "cure" was to limit the system to run on 8 cores just like the developer machines, and AFAIK it still runs in that way all these years later.
> It’s problematic that the kernel was hardcoded to a maximum of 8 cores<p>Why? The article show no evidence of this being problematic.<p>> 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.<p>Make a PoC and prove it.
Is this an actual bug, or intentional behavior? I mean someone must have put the min in there for a reason…? I can imagine scenarios were it would be nice to have something scale with cores up to a certain point, maybe this is one of those? I didn’t see much analysis beyond “oh hey there is a 8 here that means the kernel people are dumb for 15 years”. Did this get fixed?
> The Linux kernel has been accidentally hardcoded to a maximum of 8 cores <i>for the past 15 years and nobody noticed</i><p>I can understand having a bug like that, but unnoticed for 15 years? more than 8 cores was rare 15 years ago, and as a percentage of chips sold is still rare, but presumably people with threadrippers ran benchmarks? optimized? etc? just doesn't seem possible
At first i thought, this is a big bug, but all the commits the author linked do not even back up his point. And the argumentation around is not following through. So basically we are looking at big claims with zero evidence.<p>Either the author is deranged or this was written by AI.
If this was true, many of us would have noticed including myself. Who hasn't run `make -j 32` and then `make -j 64` to see if it is faster? Many times on a 64 cores machine I've seen that increasing the core count for large compile tasks makes scale as expected up to 64 cores, then a bit faster up to 128 threads (because the threads are bottlenecking on I/O so there is some CPU leftover), and then it gets slower again past 128+.<p>If capped to 8 it would be very clear
I used to work on a supercomputer with 128 cores on it that ran Linux (I actually seem to remember it had 256 cores, but someone said the kernel had a limit of 128). This was less than 15 years ago. There were surely many systems just like that one. Does that mean the kernel had been patched? But nobody thought to push that patch upstream?<p>Reading the other comments here it seems the title is stupid and wrong and my suspicion that this can't be right was correct.
The statement looks very misleading or even fraudulent. I used a system with 192 cores often and with GNU parallel, it did not stagnate at 8 parallel tasks for simple demonstrations. If we're talking about a case where 8 is intentionally the maximum (it's possible that some tasks should not parallelize more than 8), then the statement is misleading as well, since it gives the wrong impression. I have the service tag and the output from nproc and the exact version of everything where I used 192 CPUs. I suppose pseudoscience will always return and claim that the statement is true anyway, no matter what observations the rest of the world can give. There is pseudoscience forever who always says that the rest of the world is misunderstood.
The minimum run time of a tread before it's potentially preempted when load is high is computed based on number of cores available giving more time when there are more cores since rescheduling latency is apparently longer with more cores.<p>And the function that does this uses the same value for 8 and more cores.<p>So the performance impact is likely <<1%.
I'm annoyed that the author knows perfectly well what the code does, and yet he multiple times draws the clickbaity wrong conclusion that "the kernel has been hardcoded to use only 8 cores for 15 years" which is just patently wrong as the discussion is just about pre-emption timing and NOTHING about how many cores are used.
this may not be an error.<p>i’m doing high performance gamedev on a 7950x with smt off. 16 cores.<p>i can only use 8 to run the game.<p>mutex and other synchronization gets highly variable latency if the first 8 cores try to talk to the second 8.<p>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.<p>linux running on 8 cores seems like a potentially good idea. one wants the kernel to have low latency with low variability.
Wow big oooff<p>One thing I noticed is that min/max functions are <i>tricky</i> to use and it's easily to accidentally do the wrong thing, like in this case<p>Because you think "you want the minimum (that is, the number should be <i>at least</i> 8) of those numbers to be 8" then you slap min(). And you got it wrong. You should have used max()