LWN:手机SoC提供商为什么要改动内核scheduler?

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

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深度文章以及开源社区的各种新近言论~

我来评几句
登录后评论

已发表评论数()

相关站点

热门文章