LWN: 针对突发情况改善CFS分配器！

内核CFS带宽控制器：支持突发性工作负载

最新推荐文章于 2025-08-07 09:07:53 发布

翻译最新推荐文章于 2025-08-07 09:07:53 发布 · 852 阅读

2 ·

CC 4.0 BY-SA版权

原文链接：https://lwn.net/Articles/844976/

文章标签：

#linux #kernel #实时操作系统

Linux内核中的CFS带宽控制器通过限制每个控制组的CPU时间，防止某些进程过度消耗资源。新的补丁集旨在改善其对突发性和延迟敏感工作负载的处理，允许cgroup将未使用的配额累积到下一个周期，以适应偶尔的高需求，同时在长期统计中保持不超过配额。这种方法减少了最坏情况下的延迟，有望在未来的内核版本中被采纳。

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

The burstable CFS bandwidth controller

By Jonathan Corbet
February 8, 2021
DeepL assisted translation
https://lwn.net/Articles/844976/

内核中的 CFS bandwidth controller 是控制每个 cgroup 可以使用多少 CPU 时间的一种有效方式。它可以避免某些进程消耗过多的 CPU 时间，并确保所有需要 CPU 的进程都能拿到足够的时间。可以想象，bandwidth controller 并未完全满足每一个 workload 的全部需求。Huaixin Chang 提出的这组 patch 旨在让它更好地适用于突发的(bursty)、对延迟敏感(latency-sensitive)的 workload。

bandwidth controller 只适用于 "完全公平调度"（CFS, completely fair scheduling）任务（也就是人们常说的所谓 "正常进程"），而实时任务（realtime tasks）的 CPU 分配情况由其他方式处理。这个 bandwidth controller 提供了两个参数来管理针对各个 cgroup 的限制。

cpu.cfs_quota_us, 是这个 cgroup 在每个统计周期（accounting period）内可用的 CPU 时间（以微秒为单位）。
cpu.cfs_period_us, 是统计周期的长度，也是以微秒为单位。

因此，假如我们将 cpu.cfs_quota_us 设置为 50000，cpu.cfs_period_us 设置为 100000，将使该组在每 100ms 周期内消耗 50ms 的 CPU 时间。将这些值减半（将 cpu.cfs_quota_us 设置为 25000，cpu.cfs_period_us 设置为 50000）的话，就是每 50ms 消耗 25ms 的 CPU 时间。在这两种情况下，这个 cgroup 就被授权可以占用一个 CPU 的 50% 资源，但在后一种设置下，可供使用的 CPU 时间会来得更频繁，更小块。

这两种情况的区别很重要。想象一下，某个 cgroup 中只有一个进程，需要运行 30ms。在第一种情况下，30ms 小于被授予的 50ms 时长，所以进程能够完成任务，不会被限制。在第二种情况下，进程在运行 25ms 后将被停止执行，不得不等待下一个 50ms 周期再继续运行来完成工作。如果 workload 对延迟敏感的话，就需要仔细考虑 bandwidth controller 参数的设置。

这种机制对于那些需要持续执行特定 CPU 时长的工作负载来说效果相当不错。不过，对于突发性的工作负载，会比较尴尬。某个进程在大多数时间段内需要使用的时间可能远远少于它的配额(quota)，但偶尔会出现一个突发的工作，此时它所需要用到的 CPU 时间可能又比配额要多。在延迟问题并不敏感的情况下，当然可以让该进程等待到下一个周期来完成它的工作，但如果延迟问题确实影响很大的话，那么我们不应该让它再等到下个周期。

人们尝试了一些方法来解决这个问题。大家都能想到的一种方法是直接给这个进程分配足够大的配额，就可以处理这类突发事件了，但这样做会使该进程总体上消耗更多的 CPU 时间。系统管理员可能不喜欢这种做法，尤其是如果用户只付费购买了一部分 CPU 时间的情况下，系统管理员不希望给他分配更多时间。另一种选择就是同时增加配额和周期，但如果进程最终还是要等到下一个周期才能完成工作的话，那也会导致延迟增加。

Chang 的 patch set 采用了与之前不同的方法：允许 cgroup 将一些未使用的配额从一个周期转到下一个周期。引入的新参数 cpu.cfs_burst_us 就设置了这种方式可以累积的时长上限。举个例子，继续讨论配额为 25ms，周期为 50ms 的 cgroup 配置。如果将 cpu.cfs_burst_us 设置为 40000（40ms），那么这个 cgroup 中的进程在某个周期内最多可以运行 40ms，但前提是它已经在之前的周期中省下了这次额外所需的 15ms。这样一来，这个 cgroup 就可以既满足它的突发性工作需求，又能够在长时间的统计中保证它的 CPU 耗时仍然不超过配额上限。

可以用另一种方式来解释这个做法，当使用了 cpu.cfs_burst_us 的时候，配额（quota）的定义就跟从前不一样了。配额不再是绝对的数值上限，而是在每个周期内向此 CPU 时间账户内存入的时长，cfs_burst_us 值就是这个账户的封顶值。需要预先为突发事件做准备的 cgroup 就可以在该账户中来储蓄一些（有限的） CPU 时间，在需要时使用。

默认情况下，cpu.cfs_burst_us 为 0，这就禁用了 burst 机制，而遵照传统行为执行。系统中有一个 sysctl 开关可以用来在整个系统中禁止使用 burst 方式。还有另一个开关 (sysctl_sched_cfs_bw_burst_onset_percent)，用来每个周期开始时给每个组一个规定百分比的突发配额（burst quota），不管以前的周期中是否积累出了这些时间。

这组 patch set 附带了一些 benchmark 数据，结果显示当使用 burstable controller 时，最坏情况延迟数据有数量级的减少。这个想法目前已经在 mailing list 上看到过好几次，既有当前这个版本，也有 Cong Wang 和 Konstantin Khlebnikov 独立实现的版本。目前看来，最大的障碍已经被克服了，所以这个改动可能会在 5.13 合并窗口中进入 mainline。

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

欢迎分享、转载及基于现有协议再创作～

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