Linux

Wish this BS article would stop getting posted everywhere.

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/acb4a848da821a095ae9e4d8b22ae2d9633ba5cd

this is a very misleading headline and does not reflect reality. the linux kernel absolutely uses more than 8 cores. there may be some timing changes that cap out at 8 cores. it's really not the big deal the headline and article suggests.

I love the arrogant confidently incorrect at the end of the blog.

• The comments in the code are wrong
• The official documentation is wrong
• The manpage is wrong
• Every blog article ever written is wrong
• Linus Torvalds is wrong
• Everyone who knows what they're talking about is wrong
• No, I don't know how to read kernel code. Why do you ask? You're wrong
• Shut up. You're wrong

Isn't there quite some information missing? Which scheduler is affected? What are the are the exact consequences since we're talking about latency in the first part of the article. Did it affect the AMD Epyc processors that run all the VPS?

The title is highly misleading — which should be obvious enough to anybody who has been using Linux in the last 15 years. Of course Linux has been able to use more than 8 cores this entire time. Many of us would have noticed a long time ago if it didn't

The article is talking about a minor optimization of scheduler granularity to make better use of multi-core machines. It would increase the size of the scheduler's time slice to make use of the fact that in a highly multi-cored system, you would very likely have some core available to react to user inputs fast, even if processes are running, thereby saving on some context switches. Apparently, this optimization didn't not go as far as originally planned for CPUs with more than eight cores.

Personally, I don't expect it would have made a major difference of it had.

The headline here is frankly going past a simplified summary and well into dishonest territory. I would take everything this author says with a huge helping of salt, including his claims that all the documentation and even code comments about that mechanism are wrong.

This feels misleading? They're claiming Linux has been hard coded to 8 cores but from what they describe in the article it is specifically the scaling of the scheduler?

If I understood correctly the more cores you have, the more you could scale up the time each individual task gets on a CPU core without experiencing latency for the end user?

I can see that would have a benefit in terms of user perception Vs efficient use of processing time but it doesn't mean all the cores aren't being used? It just means the kernel is still switching between tasks at say 5ms when it could be doing it at 20ms if you have lots of cores and the user wouldn't notice. I can imagine that would be more efficient but it's definitely not the same as being capped to 8 cores; all the cores and CPUs are being scheduled just not in a way that might be the most optimal for some users.

Is that right? I feel like the title massively overplays the issue if so. It should be fixed but it doesn't affect how many cores are used or even how fasr they work, merely how big the chunks of time each task get to run and how you can "hide" that from desktop users so the experience feels slick?

I noticed I just didn't say anything

How has no one noticed a server first kernel being limited to 8 cores?

Cf. https://derp.foo/post/399415

New version when?

We all know more than 8 cores is bloat.

good thing i can't afford such extravagant luxuries as a cpu with more than 8 cores. never would have affected me.