This is the best summary I could come up with:

The extensible scheduler “sched_ext” code has proven quite versatile for opening up better Linux gaming performance, more quickly prototyping new scheduler changes, Ubuntu/Canonical has been evaluating it for pursuing a more micro-kernel like design, and many other interesting approaches with it.

Torvalds feels the sched_ext code is ready enough and provides real value to the mainline Linux kernel.

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.

I’ve never been a huge believer in trying to make everybody happy with code that is out of tree - we’re better off working together on it in-tree.

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).

So short of any last minute change of plans between now and mid-July when the Linux 6.11 merge window opens, looks for sched_ext in the next kernel cycle.

The original article contains 432 words, the summary contains 206 words. Saved 52%. I’m a bot and I’m open source!

Wow! I didn’t expect sched_ext to be accepted based off historical precedent of not allowing multiple schedulers

I thought the focus would be on optimizing EEVDF now

This is going to be such an awesome addition. I saw an interview with one of the guys working on the project and it sounded so cool. I think the interview was on tech over tea with David Vernet. Great talk about the magic box thay is the Linux kernal.

Awesome. No idea what that means, but AWESOME!

Does this mean anything for me as a consumer?

Sounds good but what does sched_ext do and mean for the future?

So can I bang on the Intel 12th gen P-cores with the enterprise microcode to see if they are really fused? I promise to isolate the CPU set if I can pretty please have access to the full AVX instructions for use with llama.cpp. Pretty please.

I like that he is being decisive about it. I wouldn’t be surprised to learn that the feature was only being delayed because of internal project politics or quirky policies that normally make sense, but don’t in this specific scenario.

Finally, recompiling the kernel to change scheduler will be a thing of the past…