LWN：在deadline调度器中支持CPU capacity！

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

Capacity awareness for the deadline scheduler

May 29, 2020

This article was contributed by Marta Rybczyńska 

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

译者：LinuxEverything

Linux deadline调度器支持实时系统（指在这些系统中应用程序需要确保在特定时间内完成工作）。它为deadline task分配CPU时间的时候需要确保每个task的时间限制都要得到满足。然而，目前的实现在非对称（asymmetric）CPU环境下工作的不是很好，比如Arm的big.LITTLE这种情况。Dietmar Eggemann最近发布了一组补丁，通过在deadline scheduler中加入CPU capacity的概念来解决这个问题。

在实时系统中，任务需要满足一定的时效性。Linux内核包括两个realtime scheduling class来满足这些需求，分别是：POSIX realtime（通常只简称为 realtime）和deadline。

POSIX realtime scheduler使用任务优先级作为决策的基础，优先级最高的任务将首先运行。而deadline调度器则不使用优先级，而是使用三个参数来描述任务：运行时长（run time）、周期（period）和截止时间（deadline）。运行时长是指任务完成眼前工作所需要的CPU时间，周期定义了任务两次激活之间的时间，而截止时间是指任务必须确保能够得到CPU使用权的时间。有兴趣的读者可以在前面的文章（https://lwn.net/Articles/743740/ ）中找到更多关于Linux实时调度器背后的理论解释以及它们之间的区别。

The deadline scheduler and asymmetric CPU configuration

deadline scheduler包括一个接纳(admission)算法，当任务请求参与deadline scheduling时，该算法就会运行，并确保系统能够满足任务的需求。如果不能满足实时性要求，系统中的任何任务都会错过其deadline，那么任务将被拒绝进入deadline class。但是，该算法并不能保证deadline总是被满足，它只保证deadline task占有时间有限制，已经非deadline task不会被饿死。这是因为一般情况下能否满足deadline取决于系统中已经存在的任务，此文有详细的解释（https://lwn.net/Articles/743946/ ）。

在非对称CPU系统中如big.LITTLE或DynamIQ中，deadline调度器的工作会更加复杂。这类系统包括不同类型的CPU，性能有高有低。同样的任务在性能较高（"big"）的CPU上运行时，会比在性能较低（"little"）的CPU上运行时耗时更短。当前内核中的deadline调度器并没有考虑到这种差异，它可能会在性能较低的CPU上分配过多CPU时间。Deadline任务可能最终会落在一个小CPU上，使得调度后无法在截止时间前完成，本来放在一个高性能的CPU上其实是可以完成的。在这样的系统中，admission算法假定所有CPU的性能都达到big CPU，所以会使系统接纳过多的deadline task，使系统表现不佳。

deadline scheduler中缺少CPU capacity信息（指在给定时间内可以执行的指令数量）。更多关于它的计算方法的细节可以在这里（https://lwn.net/Articles/639543/ ）找到。CPU capacity已经在负载均衡和其他情况下使用起来了，比如当因为过热而改变CPU频率时就会用。最近它被添加到realtime scheduler中了。Eggemann的工作在deadline scheduler的admission control和任务放置算法中考虑到了CPU capacity。修改后，deadline scheduler在对称和非对称CPU配置下，以可用容量足以让任务满足其deadline的原则来决定任务的执行位置。

The changes

admission-control算法的决策依据是系统提供的CPU总容量。在对称系统中，所有的CPU都具有相同的capacity，总和就是简单的CPU数量乘以一个常数。当前的内核即使在非对称系统中也是这样计算总容量的：所有的CPU都被假定为拥有最大的CPU的容量了。新代码改变了非对称情况下的这一指标，让它来仔细计算所有active CPU的实际capacity之和。

deadline scheduler的任务放置决策代码还必须更好地了解系统的CPU拓扑结构。在将一个任务迁移到一个新的CPU之前，调度器需要确保新的CPU能够处理该任务。在非对称系统中，需要增加一种检查条件，以判断CPU的能力是否足以在deadline前完成一个给定任务的工作。这种检查使用以下公式进行：

(CPU capacity) / 1024 >= (task runtime) / (task deadline)

默认的CPU capacity是1024，低性能的CPU的capacity低于这个数字。因此，这个公式的左边会产生一个分数，表示有关CPU的相对容量。例如，假设一个小CPU的容量是462，那么这个分数就是462/1024，即0.45。该公式将只允许运行时间（相对于大CPU而言）与截止时间之比小于或等于0.45的task。一个运行时间为13,000µs而截止时间为16,000µs的任务将不会被接纳，因为13,000/16,000是0.81，超过标准了。

在唤醒deadline task，或者将deadline任务移到不同的CPU上、将任务从即将offline的CPU中迁移出来时，都会用到这个检查条件。Eggemann在讨论早期版本的patchset中提供了一些计算capacity的例子。

如果一个任务得到的CPU时间不能满足它的deadline需求，它就会错过这个截止时间。这种情况在 deadline scheduler中总是会发生的。比如说，任务被成功接纳之后，其中一个 CPU 下线，系统的整体capacity就会减少。在patch set中引入了相应的改动，在非对称配置中处理这种情况时，scheduler会选择可用容量最大的CPU。如果有几个CPU的话，它会尽可能选择当前的CPU，以尽可能利用cache里面的内容。

Limitations and further work

deadline scheduler中对非对称CPU支持所需的工作并非到此为止。目前的patch set要求至少有一个CPU没有任何deadline task，否则task placement可能仍然不合理。而更重负载的情况也需要以后再解决。

在讨论过程中，Juri Lelli指出了一个可能的问题：如果一组小的deadline任务先开始，它们将被放置在大的CPU上。如果再接纳一个更大的任务，它可能找不到足够大的CPU来运行。Luca Abeni（这组补丁的共同作者）回应说，他们确实有一个新patch，其中调度器会将任务放在能完成工作的最小CPU上。这个patch将在稍后提交。

这组patch set得到了积极的评价，可以预期这个修复很快会成为主线内核的一部分。我们也可以期待看到更多这方面的patch，因为有更多的工作要做。随着更多非对称CPU架构的出现，用户可能需要在自己的workload中更好地支持这种情况。

全文完

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

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

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