Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

thehftguy.com

Post reply on HN
Print view View original

21–30 of 58 posts

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

#21

Post by blkhawk »

throwbadubadu wrote: post #8
blkhawk wrote: post #4

Earlier quoted context omitted.

If i skimmed this correctly then its a malus on performance not a complete cliff. I guess people just thought "hohum - there gotta be some overhead in scheduling".

Yes, when you run in parallel, and e.g. see all >8 cores nicely nagging up to 100% why assume something wrong? Still don't get after rereading the article, what is the malus, it must be small by that? Because you definitely saw linear scaling with parallelizable problems on >8 cores, otherwise people would have noticed?

maybe processes that are persistent get pinned anyway and this would only impact process or thread thrashing where each job is small.

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

#22

Post by zygentoma »

This article is clickbait and in no way has the kernel been hardcoded to a maximum of 8 cores.

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.

[0] https://github.com/torvalds/linux/commit/acb4a848da821a095ae...

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

#23

Post by [deleted] »

nanofortnight wrote: post #9
fsckboy wrote: post #2

> The Linux kernel has been accidentally hardcoded to a maximum of 8 cores for the past 15 years and nobody noticed 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

Because it’s a completely misleading headline. The number of cores in the heuristic used to calculate task switch frequency was capped to 8. This is a reasonable thing to do as a heuristic, because you don’t want your time slice to grow indefinitely with core count on an interactive system.

[deleted]

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

#24

Post by extropy »

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.

And the function that does this uses the same value for 8 and more cores.

So the performance impact is likely <<1%.

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

#25

Post by quietbritishjim »

If I've understood this article right (possibly not as it's not so clear):

* On single core machines the scheduler interval is quite fine grained to ensure responsiveness.

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

* BUT – and this is the point of the article – above 8 cores, the scheduler interval remains constant rather than increasing further.

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.

If there is a bug here at all then it's a minor one, nothing like the title suggests.

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

#27

Post by dannyw »

nathants wrote: post #16

this may not be an error. 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. li…

You’re describing behaviour with AMD’s Infinity Fabric, which groups cores into CCDs of 8 on 7000 series chips.

Essentially, a 16 core AMD CPU is actually two separate 8 core CPUs glued together with a link.

Intel does not have this limitation.

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

#28

Post by blueflow »

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.

Either the author is deranged or this was written by AI.

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

#29

Post by scharman »

nanofortnight wrote: post #9
fsckboy wrote: post #2

> The Linux kernel has been accidentally hardcoded to a maximum of 8 cores for the past 15 years and nobody noticed 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

Because it’s a completely misleading headline. The number of cores in the heuristic used to calculate task switch frequency was capped to 8. This is a reasonable thing to do as a heuristic, because you don’t want your time slice to grow indefinitely with core count on an interactive system.

Exactly. The code is adjusting for responsiveness. With less cpus you need a smaller minimum slice. As you have more cpus you can increase the slice and still schedule the same number of processes per second.

E.g. 1 ms slice with 1 core = 1000 process switches per second. With 2 cores you can increase the slice to 2 ms and still maintain the same number of switches per second for the system, but reducing the switches per second on each core to 500. This reduces the overhead for the scheduler.

It seems like at around 8 times the slice efficiency starts to go the other way, so they’ve limited it. Seems reasonable, but scheduler math is crazy.

Note, that this has nothing to do with the scheduler assignments per core which have clearly been working or people would’ve noticed!

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

#30

Post by [deleted] »

zygentoma wrote: post #22

This article is clickbait and in no way has the kernel been hardcoded to a maximum of 8 cores. 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. [0] https://github.com/torvalds…

[deleted]
Post reply on HN