LWN：用deadline server来实现实时任务的限制！

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

Deadline servers as a realtime throttling replacement

By Jonathan Corbet
June 12, 2023
DeepL assisted translation
https://lwn.net/Articles/934415/

CPU 调度器无时无刻不在努力去安排把最需要 CPU 的任务运行起来。有许多因素使得这项工作变得很复杂，其中最主要的一点是 "最需要 CPU （strongest claim to the CPU）" 有时候有点模糊。realtime throttling （实时节流）是一种旨在防止失控的 realtime 任务垄断 CPU 的机制，在这种情况下，开发人员认为表面上具有最高优先级的任务实际上不应该运行。但是，realtime throttling 很少能满足人们的期望。Daniel Bristot de Oliveira 发布的 deadline-server 基础设施 patch 就是在尝试寻找更好解决方案。

POSIX 的 realtime scheduling class（实时调度类）概念很简单；在任何时候，具有最高优先级的任务都需要运行，而不考虑其他任何任务。但在现实世界中，这一规则就导致那些失去控制的 realtime 任务能直接接管系统，甚至恢复正常的唯一方法可能就是拔掉电源插头了。事实也证明了这种掉电处理的优先级其实要比 realtime 任务还要高。

不得不拔掉电源线，对很多人来说是很难接受的，而且往往会导致错过 realtime 任务的 deadline；为了避免这种情况，内核开发者在很多年前就引入了 realtime throttling。简而言之，它可以将实时任务在默认情况下限制只能使用所有可用 CPU 时间的 95%；剩下的 5% 留给低优先级的 task，这其中的目的都是让管理员在需要时可以有机会 kill 一个失控的 task。

大多数时候，这种节流机制表现得还不错。在一个设计合理的实时系统中，实际的 realtime 工作使用的 CPU 时间应该远远少于 95%，所以节流动作实际上不会发生。但是，如果一个实时任务在很长一段时间内需要占用所有 CPU 时间，那么实时节流就会成为一个问题。尤其是哪怕没有低优先级的任务在等待运行，realtime 任务也会被节流机制限制住。在这种情况下，调度器没有选择运行那些仍然需要 CPU 的 realtime 任务，而是简单强迫系统进入 idle 状态。在实现节流机制时，其实并不需要进入这个 idle 状态，这不是它本身所需要的功能。

多年来，人们为解决这个问题做出了各种努力。 https://lwn.net/Articles/931789/ 这里描述了一种方法，也就是如果 realtime throttling 会导致系统 idle 的话就禁用这个 throttling 机制。deadline-server 的想法则是另一个解决这个问题的方法，基于 deadline scheduling class 机制。这个 class 比 POSIX realtime class 的优先级更高，它不是基于优先级来进行调度，而是由各个 task 来声明他们需要的 CPU 时间以及他们最晚在什么时候要能获得 CPU，deadline scheduler 努力确保这些任务都能满足其最后期限。

因此，在需要从实时任务中拿回 5%的 CPU 时，这个 class 成为了一个很自然的选项。只需要在 deadline class 中创建一个 task（称为 "deadline server"），声明它需要 5% 的 CPU，并让该 task 用分配给它的时间来运行低优先级的任务。然后，调度器将划出必要的 CPU 时间，但是，如果 deadline server 不需要 CPU 的时候，它就根本不会去运行，就能让 realtime task 继续运行。

在 Bristot 的 patch set（包含 Peter Zijlstra 和 Juri Lelli 的补丁）中实现的这个想法，相当完美地实现了目标，因为它为低优先级的任务腾出了空间，而没有导致 CPU 不必要的闲置。deadline class 比 realtime class 有更高的优先级，这就使得这个想法可行了，但也带来了一个小问题：一旦 deadline server 被启用之后，就会立即运行，也许会导致一个最终会退出 CPU 的 realtime task 被抢占（preempt）。低优先级的任务确实应该得到他们的 5%，但立即分配给他们的话，可能会给那些正常运行的实时任务造成麻烦。

这里提出的解决方案是延迟启用 deadline server。会使用一个 kernel timer 来偶尔运行一个 watchdog 功能，看一下系统中正常优先级任务的状态。如果这些任务处于 starve 状态（饥饿的定义就是在半秒内没有得到任何 CPU 时间），那么 deadline server 将被启动。否则，在没有出现 starve 问题的情况下，调度工作会按之前规划正常运行。

Bristot 说，有了这一调整之后，这项工作正朝着 "正确的方向" 发展，但仍有改进的余地。deadline server 的启动延迟可以进一步被推后到 "零延迟（zero-laxity） "时间，也就是在它马上就要完全错过 5%的最后期限的时候。starve 监测器也许可以移到不运行实时任务的 CPU 上，以防止产生干扰。不过，总的来说，这项工作看起来可以成为解决 realtime-throttling 问题的一个合理的方案。

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

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

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