LWN：the deadline scheduler and CPU idle states

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

The deadline scheduler and CPU idle states

By Jonathan Corbet

May 22, 2020

OSPM

原文来自：https://lwn.net/Articles/820882/

主译：DeepL

Rafael Wysocki在2020年Linux内核峰会(OSPM)的一次会议一开始就承认，deadline scheduling class与CPU idle state组合在一起，看起来有点奇怪。deadline scheduling是用在realtime环境中，在这种情况下，如果让CPU idle就会引入延迟，人们肯定会反对。但他认为，这两种技术可能真的就是可以一起配合工作的。

为什么人们要试着把deadline scheduling和CPU idle state结合起来呢？他认为，只要有任何方法能节省功耗，我们就不应该错过。另外，在某些系统上，其实完全无法避免idle state，因为没有空闲状态的话CPU会过热，CPU就可能会因为温控措施而降频。同时，这两者的组合在他看来是完全可行的。至少理论上来说，用来决定进入哪个idle state所需的所有信息都已经是现在就具备的了，scheduler知道所有task的预计执行时间和截止时间，而且它又知道CPU idle state的属性。只是它需要能正确使用这些信息。

他的想法是维护一个global latency quality-of-service request，这个QoS机制取决于系统中所有的deadline task。综合这个QoS request信息，就可以看出是不是现在是完全无法进入idle state。也就是说如果已经接纳了足够多的deadline task，会用掉所有可用的CPU时间，那么CPU显然不能空闲。但其他时候，会有一些时间可以进入idle state。他提出了两条规则来判断是否应该进入idle state：

- latency limit不可以大于任何一个task的下一个deadline同其runtime之间的差值。如果一个任务在5ms后的deadline前有2ms的工作要做，那么就不可以引入超过3ms的延迟。

- latency limit在乘以deadline task数量之后，不能超过去除所有deadline运行时间后预留的可用runtime。换句话说，系统因exit latency而导致的CPU time不能超过所有deadline task使用全部预留时间后剩余的时间。

Juri Lelli认为这个基本想法是合理的。Daniel Bristot de Oliveira则表示，虽然第一条规则有道理，但第二条规则过于悲观（pessimistic）。并非所有的wakeup都发生在idle CPU上，所以exit latency有些时候是可以省掉的。通过SCHED_FIFO realtime class，你可以知道所有任务他们自己的最大latency，但对于deadline任务来说就不一样了，无法保证它会遇到什么样的latency。deadline task其实可以接受在wakeup时候有一些延迟，只要它还能在自己的deadline时间内完成任务就好。

Wysocki说，这里还是有一些棘手的问题，CPU可能每隔一段时间就要进入C1 idle state，不管操作系统是否希望它进入。这引起了一些关于如何对这种强制发生的C1时间进行建模的讨论。Tommaso Cucinotta建议可以把它本身也设置为一个特殊的deadline task，这样scheduler的admission control policy就可以对它也起作用。Wysocki认为这是一个有趣的想法，但他还是希望在workload许可的情况下，能尽量找机会额外增加idle时间。

Lelli指出，scheduler现在为non-realtime非实时任务预留了一些时间，以确保它们至少有机会可以运行一下。也许可以做类似的事情来为idle thread预留时间？Cucinotta说，这种特殊的idle要求要在恰当的时间点来触发。Lelli说，可能也需要在不同CPU之间交流确保idle time达到满足，但Wysocki说，他现在还没有考虑更深层次的空闲状态（deeper idle state）或让整个系统idle这些更进一步的问题。

Lelli问现在是否有patch可以看看，Wysocki说他还没有做任何实际工作。这是件好事，因为他在这次讨论中了解到了一些内容，这些会影响他最终提出来的方案。

这时Wysocki已经讲完了，但谈话还在继续。Dietmar Eggemann指出，虽然deadline task的admission control是在全局范围内进行的，但deadline task的实际调度是在每个CPU上进行的（per-CPU）。他问，应该在哪个层面上来考虑idle time？Bristot说，这种划分是deadline scheduling的理论和实际实践之间的差异造成的。Cucinotta说，随时可以对系统进行分区管理来将admission-control的决定权往下移。

此后的讨论就完全进入deadline-scheduling theory讨论了，具体内容请等video recording提供出来之后大家自己看吧。

全文完

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

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

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