“ext”对应的英文单词为“extensible”，意为可扩展的。开发者Tejun Heo通过整整30 个的patchs，提供了一个支持eBPF程序修改调度策略的调度类。其核心目的有三个：
- 让开发者更易于实验和探索新的调度策略，免去编译完整内核镜像的成本
- 通用调度策略难以满足的特殊应用场景，通过该机制可以实现深度定制化
- 可以快速部署新的调度器
可扩展调度器 “sched_ext” 代码在提升 Linux 游戏性能、更快地原型化新的调度器变更方面表现得非常灵活，Ubuntu 也在评估其用于实现类微内核的设计，以及其他许多有趣的方法。尽管它一直未被纳入主线，但这种情况在即将到来的 Linux 6.11 版本周期中将会改变。
Linus Torvalds 作为 Linux 内核的“BDFL(终身仁慈独裁者)”宣布，他打算合并 Linux 6.11 的 sched_ext 补丁，尽管其他内核开发人员提出了一些反对意见。 Torvalds 认为 sched_ext 代码已经足够准备好，并为主线 Linux 内核提供了真正的价值。不值得将 sched_ext 继续留在代码树外。
6月11日，Torvalds 在围绕sched_ext v6 补丁的 Linux 内核邮件列表线程中利用了他的权威，宣布了他将代码与 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.
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).
Maybe the people who have concerns about this can work on those
concerns when it's in-tree.
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.
Anyway, this is the heads-up to Tejun to please just send me a pull
request for the next merge window.
And for everybody else as a "It's happening" heads-up.
[ Please just mentally insert the "IT'S HAPPENING" meme gif here -
because if I actually were to include it here, lkml would just reject
this email. Sometimes the anti-html rules don't work in our favor ].
Linus
From: Linus Torvalds torvalds@linux-foundation.org
https://lore.kernel.org/lkml/CAHk-=wg8APE61e5Ddq5mwH55Eh0ZLDV4Tr+c6_gFS7g2AxnuHQ@mail.gmail.com/
“老实说，我认为没有理由再拖延了。这整个补丁集是去年内核维护者峰会上的主要（私人）讨论，我认为进行相同的讨论没有任何价值（无论是在列表外还是作为实际事件）在一年后即将举行的维护者峰会上，因此为了取得任何实质的进展，我目前的计划是将其合并到 6.11。
至少这样，我们正在取得进展，KS 2024 上的讨论可以是关于我的精神敏锐度（或缺乏），而不是重复去年显然没有取得任何进展的同一件事。
我从来都不太相信要让每个人都对树外的代码感到满意——我们最好在代码树内一起工作。
并且使用“为了接受这一点，必须首先解决其他一些问题”的论点也不太有效（而且这个问题已经在各种维护者峰会上讨论了十多年）。
也许对此有担忧的人可以在代码树内解决这些问题。
我也不相信（多次）使用过的论点，即 BPF 调度程序会阻止人们参与调度程序开发。我个人认为，阻碍人们参与的主要原因是参与门槛太高。
不管怎样，这是对开发者 Tejun 的提醒，请向我发送下一个合并窗口的提交请求。
对于其他人来说，这是一个“正在发生”的警告。”
因此，从现在到七月中旬 Linux 6.11 合并窗口开启期间，如果没有任何最后一分钟的计划改变，下一个内核周期我们就可以看到 sched_ext。
参考文档：
[1]The extensible scheduler class：https://lwn.net/Articles/922405/
[2]https://lwn.net/ml/linux-kernel/20230128001639.3510083-1-tj@kernel.org/
[3]Linux-6.11-Extensible-Scheduler：https://www.phoronix.com/news/Linux-6.11-Extensible-Scheduler
[4]内核调度客制化利器SCHED_EXT ：https://www.sohu.com/a/783330459_121124374
[5]Linux 核心設計: Scheduler(7): sched_ext https://hackmd.io/@RinHizakura/r1uSVAWwp
[6]sched_ext机制研究 https://rqdmap.top/posts/scx/
[7] https://mp.weixin.qq.com/s/UbS7tr_vmc1GAK-fpH8nQg
