This week in Linux, Linus Torvalds announced he plans to merge the extensible scheduler “sched_ext” patches for Linux 6.11 even though there has been some objections by other kernel developers.
For those unfamiliar, the kernel scheduler decides which process runs on which CPU core, when that happens and for how long. It also deals with interrupts when a CPU needs to stop what it’s doing and tend to hardware. Its priorities vary with workload. For example, desktop and mobile users want responsiveness and low latency while servers want throughput. This is pretty big deal as this is basically central to everything the kernel does.
For a long time, many core developers insisted that the kernel should have only one scheduler with no plugins and limited customization but the sched_ext patch set added customization using the kernel’s BPF virtual machine, and this proved to be pretty effective.
There are documented performance gains including Linux gaming performance. It also makes it quicker for prototyping new scheduler changes. Some distributions are shipping patched kernels to have these benefits, in fact, Canonical has been evaluating it for pursuing a more micro-kernel like design.
Linus said he feels the sched_ext code is ready enough and provides real value to the mainline Linux kernel. Linus threw down the gauntlet this week on the the Linux kernel mailing list thread around the sched_ext v6 patches to announce his intent to merge the code with Linux 6.11.
“I honestly see no reason to delay this any more. This whole patchset was the major (private) discussion at last year’s kernel maintainer summit, and I don’t find any value in having the same discussion (whether off-list or as an actual event) at the upcoming maintainer summit one year later, so to make any kind of sane progress, my current plan is to merge this for 6.11.
At least that way, we’re making progress, and the discussion at KS 2024 can be about my mental acuity – or lack thereof – rather than about rehashing the same thing that clearly made no progress last year.
It is often claimed that sometimes development in the open can result in things taking a while which apparently this is an example of that but as the BDFL or benevolent dictator for life, these kinds of things can be quickly solved as well. lol
And using the “in order to accept this, some other thing has to be fixed first” argument doesn’t really work well either (and that has been discussed for over a decade at various maintainer summits).
It is true that in some situations that argument can certainly be valid but it can also be used to hold back trying stuff so I feel that is a double edged sword kind of thing.
I’m also not a believer in the argument that has been used (multiple times) that the BPF scheduler would keep people from participating in scheduler development. I personally think the main thing that keeps people from participating is too high barriers to participation.
This right here is something I wanted to address because this is much bigger than just about the Linux kernel development. Obviously, there is going to be an automatic barrier on participating with the kernel because it requires some pretty high development credentials but too high of barrier to entry applies to literally every project. If you are part of an open source project, please try to lower this barrier as much as possible.
I recently tried to communicate with an open source project about some ideas I had for them. This was very very difficult and it took 1.5 to 2 hours just to begin the conversation. In this case it was due to mixed messaging on their website about having a mailing list and when you go to use it you find it was archived. Then you see that they have so many ways to get in touch but not all members of the project actually use all of those platforms. It got pretty frustrating. Anyway, this is a tangent so I’ll just end it here.
What are your thoughts on this topic about Linus throwing down the gauntlet? Let me know in the comments.
source: phoronix
Be the first to comment at forum.tuxdigital.com