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

Evaluating vendor changes

By Jonathan Corbet

May 19, 2020

OSPM

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

主译：DeepL

内核的CPU scheduler尽力希望能为各种类型的workload做出正确的调度决策。多年来，它已经被扩展从而能够更好地处理移动设备的进程调度工作。但手机厂商最终还是会对mainline的scheduler代码打上厂商自己特有的patch。以这种方式提供的代码并不在mainline git tree里面，内核社区不喜欢这种方式。但正如Vincent Donnefort在2020年Linux内核峰会（OSPM）上的演讲中指出的那样，这些patch的存在是有其必要性的。他检视了一些厂商的scheduler patch来调查为什么要使用这些patch。

关于这些patch的测试平台，Donnefort选择了Pixel 4手机。这是一款在upstream中拥有非常好的代码支持的设备，更换其内核很容易，不需要许多额外代码。这款设备有三种不同的CPU核心，分别是小核、中核、大核，其中小核确实计算能力非常有限。对于任何给定的任务，必须要选择使用合适的CPU，否则在性能或功耗上都不是最高效的。我们使用PCMark benchmark来评估性能，而功耗测量则是直接从手机的供电电路上进行的。测试中使用了4.14内核。

第一个用来测试的patch，通过主动将任务疏散到其他CPU来执行CPU isolation。其意图是让这个CPU能够idle下来，从而进入sleep状态。任务会被迁移走，中断也被安排到其他CPU，这个CPU就完全不在系统的多CPU负载平衡策略中考虑了。但该CPU的kernel thread仍然在运行。他说，这是一种轻量级的CPU hotplug。

这个patch的工作原理是通过查看所有运行中的task所带来的工作量，计算出需要多少CPU功耗。如果运行中的CPU数量超过了理论所需要的CPU数，那么软件就会尝试把其中一个或多个CPU给隔离出来。这个决定是在user space中做出的。

在性能测试中，Donnefort发现，CPU isolation会略微降低throughput，但也会让功耗下降4%。Vincent Guittot问道：为什么内核中内置的energy model功耗模型不能满足这个需求呢？Donnefort回答说，他没有尝试调查这个问题的其他潜在替代方案。但至少数据表明，kernel内置的energy model还是有改进的空间。

其他的patch合成了一组来介绍，包括：

• "Migration margins"：这个patch会在非对称系统上改变内核为task选择CPU的策略。这是通过比较task的预计utilization（CPU利用率）和CPU的计算能力（capacity）来实现的。mainline kernel只有在看到CPU还有至少20%的空余计算能力的情况下，才会把任务放在这个CPU上。而手机厂商的patch将这个阈值降低到5%，从而增加了把这个task最终放在更小、更节能的CPU上的几率。

• 改变了scheduler的task packing的机制。mainline kernel会尽量将task控制在单个cluster内（从而允许其他cluster在idle），但会尽量将task分散到cluster中的各个CPU上。厂商的patch则不同，它会更努力地将task打包到单个CPU中，尽量在导致CPU的频率提升之前就停止。

• mainline会花许多精力来寻找针对某个task最适合使用的CPU上。对一些厂商来说，这个动作花的时间有点太多，所以他们对这种算法进行了改变。改动之后，kernel会先看看上次这个task运行的位置，如果当时那个CPU是idle的，而task又适合在此CPU上执行，那么这个选择CPU的流程就会马上终止，直接选择那个CPU。他也指出，在4.14 kernel（此次测试所用的kernel版本）之后，energy-aware task placement算法也有了很大改进。

• 在为一个实时任务选择CPU时，kernel会搜索正在运行的task拥有最低优先级的CPU，因为这是最容易被preempt（抢占）的CPU。厂商的patch则将搜索条件进行了扩展，也会考虑utilization和idle state，试图找到总体上最不繁忙的CPU。搜索的目标也是尽量偏向于在适合的CPU里面寻找最小的那个CPU。

每个patch的benchmark结果都非常相似。它们都大概会牺牲3-5%的性能，同时降低8-11%的能耗。但Donnefort没有把这些patch同时打上来进行benchmark测试，他警告说，不要想当然认为这些数据可以简单的累加起来。

最后，他给出了一个简单的结论，尽管其中的一些改动是有争议的，但在这种场景下显然是有好处的。他后面会继续研究，如何能把这些改动采用适合upstream的方式来实现。

在讨论中，Qais Youssef介绍说，他最近的一些CPU-capacity的改动也许可以替代其中的部分patch。Dietmar Eggemann提问说为什么energy model提供的CPU isolation还不够呢？它应该已经在把task尽量积极推向小核上去做。Peter Zijlstra同意这个观点，认为必须弄清楚为什么需要这种变动。也许scheduler应该在energy-ware的代码路径上更仔细地关注idle state。Donnefort说，这种形式的CPU isolation可能不是mainline kernel内核里可以接受的正确解决方案，但它确实表明了这种方式可以获得一些好处。

详细结果及更多内容请看Donnefort的幻灯片[https://lwn.net/images/conf/2020/ospm/donnefort-slides.pdf]。

全文完

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

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

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