A bit of history I’ve been diving into the Linux kernel scheduler recently. To give a short brief introduction to scheduling, imagine a single CPU single core system. The operating system all…

"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."
  • waigl@lemmy.worldEnglish
    14·
    10 months ago

    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.