this post was submitted on 14 Nov 2023
-41 points (37.7% liked)

Linux

47237 readers
3343 users here now

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

Related Communities

Community icon by Alpár-Etele Méder, licensed under CC BY 3.0

founded 5 years ago
MODERATORS
 

"The min_granularity setting was renamed to base_slice in this commit in v6 kernel.

The comment says it scales with CPU count and the comment is incorrect. I wonder whether kernel developers are aware of that mistake as they are rewriting the scheduler!

  • Official comments in the code says it’s scaling with log2(1+cores) but it doesn’t.
  • All the comments in the code are incorrect.
  • Official documentation and man pages are incorrect.
  • Every blog article, stack overflow answer and guide ever published about the scheduler is incorrect."
you are viewing a single comment's thread
view the rest of the comments
[–] [email protected] 11 points 10 months ago* (last edited 10 months ago)

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?