在 Linux Plumbers Conference (LPC) 2025 上，Qais Yousef 与 John Stultz、Steven Rostedt、Vincent Guittot 共同介绍了他们为 Linux 引入高层级服务质量（Quality-of-Service，QoS）API 的计划。该演讲专注于调度器的 QoS 机制，目标是为不同类型的进程提供差异化的 CPU 资源访问优先级，从而改善系统的交互响应能力。
服务质量（QoS）机制旨在提升特定进程（或网络流量、磁盘 I/O 等）的优先级，以满足系统的性能目标。在 Linux 世界中，由于工作负载、硬件和用户预期的巨大差异，这个话题处理起来颇为棘手。
Yousef 指出，历史上，服务器市场一直是优化 Linux 内核调度器性能的主要驱动力。虽然近年来人们开始更多地关注交互性，但在如何从 Linux 系统中压榨出最佳性能方面，仍然存在许多陈旧的假设。POSIX 标准尚未充分涵盖这些新进展，应用程序也常常按照每个 CPU 核心生成一个线程的模式编写，仿佛系统中没有其他工作负载在运行。
当前内核的默认调度器 EEVDF 拥有许多可配置参数，可以在系统级或进程级进行调整。Yousef 认为，在 Linux 中实现 QoS API 的最佳方式，是向调度器提供足够的进程信息，从而为现有配置选项设置合理的默认值。问题的核心并非与调度器通信的内核接口，而是为应用程序提供一个高层级 API，让开发者无需深入理解复杂的调度器配置就能使用。
iOS（以及相关的 macOS 和 watchOS 等平台）已经拥有类似的接口。它提供了四个 QoS 级别供程序选择：
- 用户交互：用于更新程序界面的任务。
- 用户发起：用于用户正在进行的操作。
- 实用工具：用于应及时发生但不会直接影响用户的任务。
- 后台：用于对延迟没有特殊要求的任务。
程序中的每个线程都可以独立设置 QoS 级别。
Yousef 提议将这一设计借鉴到 Linux 中，并将这些类别分别映射到调度器的时间片、策略、升频乘数和 uclamp 设置。线程将默认属于“实用工具”类，这与调度器当前的默认行为相匹配。“用户交互”或“用户发起”类的线程将被分配更短的时间片，这告诉调度器应优先考虑延迟而非吞吐量。“后台”类的线程则被分配更长的时间片，以便在系统空闲时能够长时间运行而不受干扰，但一旦有更高优先级的线程变为可运行状态，它们就会被立即中断。
现场有观众提出，Linux 已有的 deadline 调度器就可以控制不同线程的时间分配。Rostedt 随即反问：“大家真的想在 deadline 调度器下运行 Chrome 吗？”他澄清说，使用 deadline 调度器需要 root 权限，而 Yousef 的提案旨在允许普通的、非特权应用程序提供性能暗示。这引发了观众席上关于 deadline 调度与性能暗示的长时间争论。
Yousef 表示，在调度器中采用 QoS 类别还需要对处理任务分配到不同 CPU 的代码进行一些更改。Guittot 解释道，目前内核根据 CPU 负载、能效、NUMA域或核心亲和性等标准来决定任务运行在哪个 CPU 上。未来，这应该扩展到考虑被放置任务本身的特性。例如，当负载均衡器放置一个带有短时间片（高交互性）的任务时，它应优先考虑空闲 CPU；如果没有，则应倾向于将任务放在正在处理长时间片（后台）任务的 CPU 上，以便高优先级任务可以抢占。
然而，Yousef 声称内核中所需的代码更改并非主要障碍。真正的挑战在于如何鼓励应用程序开发者采用新的 API。他指出，开发者往往需要数年时间才会真正开始使用新的内核接口。他认为可以做得更好：与其采用基于函数调用的接口（要求开发者主动更新代码），不如使用基于配置文件的方法。这样，应用程序可以随附默认配置文件，而用户和发行版维护者也可以为任何希望支持新 API 的程序添加或修改配置文件。这也赋予了系统用户最终的控制权——如果应用程序提供了糟糕的默认配置，用户可以覆盖它。
有人质疑，如果应用程序开发者直接将所有线程都设为最高优先级怎么办？另一位观众指出，提议的 QoS API 实际上对单个应用程序内部的线程优先级排序最为有用。例如，一款视频游戏会希望将用户界面线程设为“用户交互”类，但如果将后台清理任务也设为同一类别，只会导致界面抖动或延迟，同时还会降低后台处理的吞吐量。
Yousef 补充道，内核不应被迫盲目遵循应用程序的配置。应该有适当的访问控制机制。例如，如果应用程序请求“用户交互”QoS 类别，但系统知道该程序当前并不在前台运行（可能基于来自桌面环境的提示或控制组设置），系统可以将其限制在“实用工具”类。另一方面，任何应用程序都应该被允许将线程标记为“后台”类，以获得吞吐量优势，因为这些线程不会影响前台交互的延迟。
Yousef 总结道，重点在于向调度器提供更多信息，使其能针对不同的工作负载做出更合理的决策。对于主要关注吞吐量的服务器，将所有内容保持在默认 QoS 级别，让现有（已为服务器优化过的）代码来处理是合理的。而对于笔记本电脑、手机等延迟比纯吞吐量更重要的场景，向调度器指明少数关键线程能帮助它做出更好的决策。
他还提到，内核中其他正在进行的工作也将对此有所帮助。例如，工具链轨道讨论的“性能继承”机制，允许高优先级任务将 CPU 时间或调度设置“捐赠”给当前持有其所需锁的低优先级任务，从而缓解优先级反转问题，改善用户可见的延迟。
Linux 最终是否会采用 QoS API，以及它是否会紧密模仿 Apple 的 API，仍有待观察。但显而易见的是，近年来内核调度子系统已经开始更多地关注吞吐量之外的问题。如果这种趋势持续下去，用户可以期待未来拥有更具响应性的用户界面。
LWN 评论概述
评论区对提案的公平性与响应性展开了深入讨论。有用户质疑为何要对批处理任务保持“公平”，认为系统应更激进地优先保障前端 UI 工作，而非仅仅缩短时间片。针对资源限制，有人指出许多应用会忽略 cgroups 或亲和性设置，建议通过修改 /proc/cpuinfo 隐藏不可用 CPU 来强制约束应用。此外，用户对比了不同操作系统的健壮性，强调即便在极端负载下，系统也应保留足够的资源用于基本交互（如鼠标移动和启动终端），以避免用户只能强行重启。还有评论提醒，内核中已存在 pm_qos 和 tc 等 QoS 框架，需注意功能重叠与集成问题。整体讨论反映了用户对 Linux 在移动和桌面端维持基本交互能力的迫切需求。
全文完
LWN 文章遵循 CC BY-SA 4.0 许可协议。
发表于 昨天 23:38
|
查看: 0|
回复: 0
