Linus Torvalds 没有为 Linux 6.11 合并窗口合并 sched_ext

虽然 Linus Torvalds 在 6 月中旬表示，他打算将 sched_ext for Linux 6.11 合并为令人兴奋的可扩展调度器代码，但这最终并没有发生……Linux 6.11-rc1 内核刚刚发布，关闭了 Linux 6.11 合并窗口，并且没有拉取sched_ext代码。

许多内核开发人员对sched_ext感到兴奋，因为它使得迭代内核调度器更改、原型新的调度器行为等变得更容易、更快速。 Linus Torvalds上个月表示，他不想继续拖延它的合并，他的计划是在Linux 6.11中合并它。

因此，根据要求，早在 7 月 15 日，当 Linux 6.11 合并窗口打开时，Tejun Heo 就提交了sched_ext拉取请求。Sched_ext已经演变成近 14k 行新代码，包括测试和相关基础设施。

但从那时起，一些代码问题被指出需要改进。几天前，Qais Yousef提出了一些担忧：

我刚刚回顾了这一点，我认为你在这里走错了方向。我认为目前的审查水平还不够，我们正在急于让它们进入 6.11。

我们真的不应该改变 schedutil 的工作方式。州长应该以某种方式行事，我们需要确保一致性。我认为你应该看看如何让你的调度器与它兼容。添加钩子来表示应用我想要的这个性能值是随机性的秘诀。

一般来说，我确实非常担心加载sched_ext会导致虚假的错误报告，因为它会改变调度器的行为，并且在加载调度器时sched_ext内核不受信任。就像树外模块一样，它应该会导致内核被污染。几年前，当 Gushchin 发送第一个提案

时，我曾问过一个问题：当加载了侵入性地改变内核行为方式的树外代码时，我们如何信任 bug 和回归报告？这必须被标记为内核污点，否则我们注定要尝试从树形代码中修复。

此外，还有另一个常见的回归报告问题，这是由于调度器演进方式的改变导致无法加载代码而导致的。我们需要继续能够自由地更改我们的代码，而不必担心破坏树外的代码。什么是回归规则？我们不希望被限制进行内核内更改，因为树外代码现在会失败;要么加载，要么按预期运行。当外部调度器不再与现有内核兼容并且*他们*需要重写他们的代码时，当前的代码是如何设计来处理故障保护的，就像现在树外模块一样？

现在 Linux 6.11-rc1 已经发布，代码没有被合并。Linus Torvalds 没有公开评论这个拉取请求，至少现在还没有。看起来最终需要进行一些sched_ext改进。

我们将看看sched_ext是否能及时在 Linux 6.12 内核周期结束之前得到进一步烘焙。Linux 6.12 也可能是今年的长期支持 （LTS） 内核版本。

转自 Linus Torvalds Doesn’t Merge sched_ext For The Linux 6.11 Merge Window – Phoronix