While Linus Torvalds stated in mid-June that [1]he intended to merge sched_ext for Linux 6.11 as the exciting extensible scheduler code, it didn't end up happening... The [2]Linux 6.11-rc1 kernel was just released to close the Linux 6.11 merge window and the sched_ext code wasn't pulled.

Many kernel developers have been excited about sched_ext as making it easier and quicker to iterate on kernel scheduler changes, prototype new scheduler behavior, etc. Linus Torvalds expressed last month he didn't want to keep delaying it from merging and his plan was to merge it for Linux 6.11.

So as requested, back on 15 July as soon as the Linux 6.11 merge window opened, Tejun Heo submitted [3]the sched_ext pull request . Sched_ext has evolved into nearly 14k lines of new code, including tests and related infrastructure.

But since then [4]a few code problems were pointed out for improvement. Then a few days ago Qais Yousef [5]raised some concernes:

I just reviewed this and I think you're going in the wrong direction here. I don't think the current level of review was sufficient and we're rushing things to get them into 6.11.

We really shouldn't change how schedutil works. The governor is supposed to behave in a certain way, and we need to ensure consistency. I think you should look on how you make your scheduler compatible with it. Adding hooks to say apply this perf value that I want is a recipe for randomness.

Generally I do have big concerns about sched_ext being loaded causing spurious bug report as it changes the behavior of the scheduler and the kernel is not trusted when sched_ext scheduler is loaded. Like out-of-tree modules, it should cause the kernel to be tainted. Something I asked for few years back when Gushchin sent the first proposal

How can we trust bug and regression report when out-of-tree code was loaded that intrusively changes the way the kernel behaves? This must be marked as a kernel TAINT otherwise we're doomed trying to fix out of tree code.

And there's another general problem of regression reports due to failure to load code due to changes to how the scheduler evolves. We need to continue to be able to change our code freely without worrying about breaking out-of-tree code. What is the regression rule? We don't want to be limited to be able to make in-kernel changes because out-of-tree code will fail now; either to load or to run as intended. How is the current code designed to handle failsafe when the external scheduler is no longer compatible with existing kernel and *they* need to rewrite their code, pretty much the way it goes for out-of-tree modules now?

Now [6]Linux 6.11-rc1 is out and the code wasn't merged. Linus Torvalds didn't comment on that pull request publicly at least not yet. Looks like some sched_ext refinements will ultimately be needed.

We'll see if sched_ext is further baked in time for the Linux 6.12 kernel cycle to end out the year. Linux 6.12 is also likely to be this year's Long Term Support (LTS) kernel version.



[1] https://www.phoronix.com/news/Linux-6.11-Extensible-Scheduler

[2] https://www.phoronix.com/news/Linux-6.11-rc1-Released

[3] https://lore.kernel.org/lkml/ZpWjbCQPtuUcvo8r@slm.duckdns.org/

[4] https://lore.kernel.org/lkml/20240723163358.GM26750@noisy.programming.kicks-ass.net/

[5] https://lore.kernel.org/lkml/20240725011907.3f5ropfai3xoy3l3@airbuntu/

[6] https://www.phoronix.com/news/Linux-6.11-rc1-Released