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?
Nothing is affected. The headline is largely bullshit. A minor optimization for high core-count systems did not go as far as originally planned, and that may or may not have made a barely noticable difference.
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?
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.
Yeah I was wondering this too - is 8 the floor, 8 cores or below the value is always the same, but above 8 cores you then get your log progression? I don’t know enough about this though.
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.
The abbreviation cf. (short for either Latin confer or conferatur, both meaning ‘compare’)[1] is used in writing to refer the reader to other material to make a comparison with the topic being discussed. Style guides recommend that “cf.” be used only to suggest a comparison, and the words “see” or “vide” be used generally to point to a source of information.[2][3]
Because it isn’t. This impacts when the scheduler kicks in, not on how many cores stuff is running on. With fewer cores scheduler is faster triggered again, and and at 8 cores the adjustment for that stops. Which may be an intentional decision to avoid high latency issues.
You are not logged in. However you can subscribe from another Fediverse account, for example Lemmy or Mastodon. To do this, paste the following into the search field of your instance: !linux@lemmy.ml
From Wikipedia, the free encyclopedia
Linux is a family of open source Unix-like operating systems based on the Linux kernel, an operating system kernel first released on September 17, 1991 by Linus Torvalds. Linux is typically packaged in a Linux distribution (or distro for short).
Distributions include the Linux kernel and supporting system software and libraries, many of which are provided by the GNU Project. Many Linux distributions use the word “Linux” in their name, but the Free Software Foundation uses the name GNU/Linux to emphasize the importance of GNU software, causing some controversy.
Rules
Posts must be relevant to operating systems running the Linux kernel. GNU/Linux or otherwise.
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?
Nothing is affected. The headline is largely bullshit. A minor optimization for high core-count systems did not go as far as originally planned, and that may or may not have made a barely noticable difference.
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?
New version when?
How fast can you compile Linux?
deleted by creator
Depends on how many cores I can use.
I love the arrogant confidently incorrect at the end of the blog.
Wish this BS article would stop getting posted everywhere.
[0] https://github.com/torvalds/linux/commit/acb4a848da821a095ae9e4d8b22ae2d9633ba5cd
doesn’t that mean it’s actually at least 8, as in if you have 4 cores
cpuswill be assigned8, if you have 20 corescpuswill be assigned20.No, I think min() returns the lower of two arguments. If you had 4 cores,
min(4, 8) == 4, and if you had 20 cores,min(20, 8) == 8Yeah I was wondering this too - is 8 the floor, 8 cores or below the value is always the same, but above 8 cores you then get your log progression? I don’t know enough about this though.
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.
We all know more than 8 cores is bloat.
Right you are.
“8 cores should always be enough for anybody”
I noticed I just didn’t say anything
Cf. https://derp.foo/post/399415
What’s this for?
Another Lemmy thread on the same article.
Context:
https://en.wikipedia.org/wiki/Cf.
Lol, all the comments there say this is bogus for one reason or another.
As of now most of the top comments here are also in agreement with that take.
good thing i can’t afford such extravagant luxuries as a cpu with more than 8 cores. never would have affected me.
How has no one noticed a server first kernel being limited to 8 cores?
Because it isn’t. This impacts when the scheduler kicks in, not on how many cores stuff is running on. With fewer cores scheduler is faster triggered again, and and at 8 cores the adjustment for that stops. Which may be an intentional decision to avoid high latency issues.
@aard @Fizz
Wasn’t the scheduler a one byte/bit at a time on/off scheme at some point?
Yeah its mum used to say “you eat to fast eat one byte at a time”