LWN:再次推动 sched_ext!

关注了就能看到更多这么棒的文章哦～

Another push for sched_ext

By Jonathan Corbet
May 9, 2024
ChatGLM translation
https://lwn.net/Articles/972710/

可扩展调度器类（extensible scheduler class，或称 "sched_ext"）是一个综合性的框架，它可以支持将 CPU 调度器实现为一组 BPF 程序，这些程序可以在运行时加载。尽管 sched_ext 引起了开发社区的相当大的兴趣，但它也遇到了相当大的阻力，并且似乎远未被 mainline（主线）接受。Tejun Heo 在 5 月初发布的 新版 sched_ext 系列补丁 重新开启了这场旷日持久的讨论，但最终结果尚不清楚。

简单回顾一下：sched_ext 允许创建 BPF 程序来处理调度问题的几乎所有方面；这些程序可以在运行时加载（和卸载）。sched_ext 的设计目标之一就是能在出现问题时（例如，如果进程未能在时间限制内运行）安全地回退到完全公平调度器（completely fair scheduler，CFS）。它已被用于创建许多专用调度器，这些调度器通常为预期工作负载带来了显著的性能提升。有关这项工作的更详细概述，请参阅 这篇 2023 年的文章。

Heo 列出了自 11 月 上一个版本 发布以来对 sched_ext 所做的一些更改。在大多数情况下，这些更改似乎是对 BPF API 的调整，目的是使调度器的编写更容易。还有一个新的关闭机制，该机制的功能之一就是可以在系统挂起（suspend）等电源管理事件期间禁用 BPF 调度器。现在支持 CPU 频率调节，并且添加了一些调试接口从而让调度器开发更加容易。不过，sched_ext 的核心设计似乎已经稳定下来。

关注度日益增长

不过，在谈到这些变化之前，Heo 首先提到了整个社区及其他领域对 sched_ext 的兴趣日益浓厚。Valve 计划在 Steam Deck 上使用 sched_ext 来更好地进行游戏调度。Ubuntu 正在 考虑在 24.10 版本中发布它。Meta 和 Google 正在其生产环境中越来越多地使用它。显然，ChromeOS 也对它很感兴趣，Occulus 也在关注它。Heo 在该部分的结尾写道：

鉴于已经有大量的采用并且还在继续增长，而且 sched_ext 不会以侵入性的方式影响内置调度器或内核的其他部分，我认为考虑将 sched_ext 纳入进来是合理的。

不过，它是否会被纳入仍然是一个悬而未决的问题。第四版 补丁集于 2023 年 7 月发布，引发了关于这项开发的优缺点的长期讨论。调度器维护者 Peter Zijlstra 断然拒绝了这些补丁，他说：

我毫不怀疑，如果我合并了这个补丁，那么将会出现一些企业软件，它们会强制要求使用自己的 BPF 调度程序，否则就无法工作。

他们不会关心，也不会贡献代码，他们甚至可能会像 RedHat 那样，只向客户分享代码。

他还说，他认为合并这些代码没有任何价值，并退出了讨论。Mel Gorman 也 表示反对 合并 sched_ext，他赞同 Zijlstra 的担忧，即企业软件将开始要求使用专用调度器。他后来 补充 说，在他看来（Zijlstra 也持相同观点），sched_ext 会不利于当前调度器的改进：

我通常担心，如果可以选择插件化，那么在已发布的调度器中可能就不会存在某些东西，包括 EAS、节流控制、schedutil 集成、big.Little、适应 chiplet 和为睿频加速选择首选的 SMT 同级线程。在每种情况下，集成支持都是一项耗时且痛苦的工作，而可插拔调度器本来是一个相对容易的选择，但如果它从未被正确集成，最终将会让我们付出代价。

当然，Heo 不同意 很多反对意见。他说，有些调度问题是无法通过调整当前调度器来解决的，尤其是在像 Meta 这样的 "超大规模" 环境中。他不同意 sched_ext 会带来维护负担的观点，他认为 BPF 对内核其他部分的侵入并没有造成这种结果。让用户能够做一些新的事情是有益的，即使不可避免地会出现一些 "愚蠢的案例"，因为有些人会选择如何使用新功能。总之，他说，反对者只关注 sched_ext 的潜在成本（在他看来，这些成本被夸大了），而没有考虑到它带来的好处。

重新开启讨论

Heo 在 10 月份发的这条消息，就是当时讨论的终点。他显然希望这次能有一个更好的结果，但 Zijlstra 的 回复 并不乐观：

我从根本上认为这种方法不利于调度器生态系统。看看为它编写的大量调度器玩具就知道了，这些工作都没有用于改进现有代码。

他说，在 "cgroup 问题" 得到解决之前，他不会接受这个补丁系列的任何部分。这个 "问题" 是指在使用大量控制组时，某些工作负载的性能会受到影响。Rik van Riel 在 2019 年就提出了 一个补丁系列 来解决这个问题，但它从未被合并；Zijlstra 似乎坚持认为，在考虑 sched_ext 之前，这项工作必须完成，而且他几乎没有明确说过在那之后会更加认真地考虑合入 sched_ext。

Heo 表示愿意（尽管不情愿）着手解决控制组问题，如果这能为 sched_ext 扫清障碍的话。不过，他强烈反对 Zijlstra 将 sched_ext 调度器称为 "玩具调度器" 的说法，也反对开发 sched_ext 会分散 mainline 调度器的精力的说法。他说，任何一个 CPU 调度器都不可能是完美的，所以 mainline 调度器只能做到对所有用户来说都足够好。这使得尝试 "激进的想法" 变得几乎不可能，并严重限制了可以参与调度器工作的人才数量。他说，如果没有 sched_ext 调度器，那么现在投入到其中的大部分工作都根本不会出现，也就不利于调度器的开发演进。

他说，有些激进的想法是有价值的：

然而，即使是简单的调度器，其多种不同的方式有时也能为特定的工作负载带来显著的行为和性能优势，这表明该领域还有很多容易实现的目标。而这些容易实现的目标，我们很难从目前的局部最优状态中找到。一个必须始终满足所有用户的单一实现，不太可能成为描绘这种前景的有效工具。

Igalia 开发者 Changwoo Min 正在与 Valve 合作开发面向游戏的调度程序，他 支持 Heo 的论点，他说："sched_ext 的成功实现为调度器社区带来了新鲜的见解、想法和代码"。截至本文撰写之时，这就是这场讨论的最新进展了。

接下来的发展？

sched_ext 已被列入 Linux 存储、文件系统、内存管理和 BPF 峰会 的 BPF 分论坛程，该峰会将于 5 月 13 日开始。届时将讨论 sched_ext 的未来发展，但很可能无法解决这项工作是否应该被合并的问题。 这个 讨论可能会在邮件列表和其他地方继续进行一段时间。

有时，当一项重要的内核开发陷入这种僵局时，那些认为它有价值的发行版会选择直接发布这些补丁，就像 Ubuntu、Valve 和 ChromeOS 正在考虑做的那样。虽然发布 out-of-tree（树外）代码通常不被鼓励，但它也可以用来证明人们对某项功能的兴趣，并及早发现将其纳入后出现的任何问题。如果一切顺利，这种做法可以加强将代码合并到 mainline 的理由，尽管随之而来的是可能对早期采用者带来的麻烦。

sched_ext 是否会走上这条道路还有待观察。可以肯定的是，这项工作已经引起了很多人的兴趣，并且不太可能在短期内消失。sched_ext 有潜力在调度器开发中带来新的创造力，即使它还没有进入 mainline 之内 — 但如果它最终被合并，这种潜力将会更大。即使没有任何争议，那些重要的调度器补丁也不会很快被合并；如果这个补丁最终被接受，那么它的速度将会比大多数补丁都要慢。

全文完
LWN 文章遵循 CC BY-SA 4.0 许可协议。

长按下面二维码关注，关注 LWN 深度文章以及开源社区的各种新近言论～