泰晓科技 -- 聚焦 Linux - 追本溯源,见微知著!

还在观望?5 小时转进 RISC-V 世界

泰晓资讯·6月 / 第二期 / 2020

Wang Chen 创作于 2020/06/25

“泰晓资讯”,广泛报道 “Linux/开源” 业界资讯。欢迎广大读者投递相关资讯来源和素材,本站将进一步收集整理后发布给大家。

第四届 Linux 内核电源管理和调度研讨会(Power Management and Scheduling in the Linux Kernel (OSPM) )于 5 月 11 日 ~ 13 日在著名的旅游胜地、比萨斜塔所在地 - Pisa(Italy)召开。会议主要讨论 Linux 内核中涉及 power management 和(real-time)调度技术。当然因为疫情的影响,本次会议最终还是采取了线上的方式举行。本期周报基于 LWN 的报道,搜集了该次会议的部分讨论主题和大家一起分享。有关本次会议的详情请访问其官方网页:http://retis.sssup.it/ospm-summit/

使用 MMTests 对调度器进行基准测试

The MMTests benchmarking system is normally associated with its initial use case: testing memory-management changes. Increasingly, though, MMTests is not limited to memory management testing; at the 2020 Power Management and Scheduling in the Linux Kernel summit (OSPM), Dario Faggioli talked about how he is using it to evaluate changes to the CPU scheduler, along with a discussion of the changes he had to make to get useful results for systems hosting virtualized guests.

MMTests benchmarking system,是一个由著名的内核内存管理专家 Mel Gorman 开发的基准测试系统,人们对它的了解通常都来自它最初的应用场景:测试内存管理子系统相关的代码改动。但是,MMTests 越来越多地在内存管理测试之外找到了用武之地。在 2020 年的 OSPM(Power Management and Scheduling in the Linux Kernel) 大会上,Dario Faggioli 介绍了他如何使用 MMTests 来评估 CPU scheduler 改动,他还介绍了为了达到这个目的对该工具进行了哪些改动,以及利用该工具对虚拟机环境测试所产生的有价值的结果。更多详情请阅读原文 “Scheduler benchmarking with MMTests”

关键词: Linux,MMTests,Scheduler


The kernel’s CPU scheduler does its best to make the right decisions for just about any workload; over the years, it has been extended to better handle mobile-device scheduling as well. But handset vendors still end up applying their own patches to the scheduler for the kernels they ship. Shipping out-of-tree code in this way leads to a certain amount of criticism from the kernel community but, as Vincent Donnefort pointed out in his session at the 2020 Power Management and Scheduling in the Linux Kernel summit (OSPM), those patches are applied for a reason. He looked at a set of vendor scheduler patches to see why they are being used.

内核的 CPU scheduler 的主要目标是尽力为各种类型的应用场景做出正确的调度决策。多年来,调度子系统已经被扩展了许多,已经能够非常好地处理移动设备上的进程调度工作。但手机厂商最终还是会对 mainline 上的 scheduler 代码打上自己特有的补丁。这些补丁代码并不会被合入 mainline 的 git 仓库。Vincent Donnefort 在 2020年 Linux OSPM 峰会上的演讲中指出,这些 patch 的存在是有其必要性的。他检查了一些厂商的 scheduler patch,并在会议上公布了他的一些调查结果。

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

通过测试他发现,尽管其中的一些改动具有争议,但在它们各自关注的场景下显然各有各的好处。他后面会继续研究,看看是否可以把这些改动采用合适的方式提交到内核 upstream 上去。欲了解更多详情请阅读原文 [“Evaluating vendor changes to the scheduler”](https://lwn.net/Articles/820825/)。

关键词: Linux,scheduler,vendor

改进版 TEO 空闲 cpu 管理算法

Life gets complicated for the kernel when there is nothing for the system to do. The obvious response is to put the CPU into an idle state to save power, but which one? CPUs offer a wide range of sleep states with different power-usage and latency characteristics. Picking too shallow a state will waste energy, while going too deep hurts latency and can impact the performance of the system as a whole. The timer-events-oriented (TEO) cpuidle governor is a relatively new attempt to improve the kernel’s choice of sleep states; at the 2020 Power Management and Scheduling in the Linux Kernel Summit, Pratik Sampat presented a variant of the TEO governor that tries to improve its choices further.

当系统空闲时时,内核需要将处理器切换到睡眠状态以节省电能,但具体该处于哪一级睡眠是个让人头痛的问题。CPU 提供多个睡眠状态级别,从而可以维持不同的功耗和延迟特性。如果睡眠过过浅则会浪费能量,而过深又会损害唤醒过程中的响应延迟,从而影响整个系统的性能。

一种称之为 “面向定时器事件的空闲处理机制(timer-events-oriented (TEO) cpuidle governor,简称 TEO)是内核中用于改进处理器睡眠状态选择的一种相对较新的尝试;在 2020 年 Linux 内核 Power Management and Scheduling 会议上,Pratik Sampat 提出了一种 TEO 的变体,试图进一步改善其性能。欲了解更多详情请阅读原文 “The weighted TEO cpuidle governor”

**关键词**: Linux,TEO,CPU-idle

Deadline 调度器和 CPU idle 状态管理

As Rafael Wysocki conceded at the beginning of a session at the 2020 Power Management and Scheduling in the Linux Kernel summit (OSPM), the combination of the deadline scheduling class with CPU idle states might seem a little strange. Deadline scheduling is used in realtime settings, where introducing latency by idling the CPU tends to be frowned upon. But there are reasons to think that these two technologies might just be made to work together.

Rafael Wysocki 提出一个讨论,如何在 deadline 调度中中引入对 CPU idle state 的考虑。这个想法看起来有点奇怪。因为人们首先会认为,deadline scheduling 主要是用在 realtime 环境中,如果在这种情况下,我们还要让 CPU 进入睡眠会引入延迟,这对实时响应自然会有影响。

但他认为,这两种技术在一起配合工作并没有什么不对,有时还必须予以考虑。一方面,这是出于对 cpu 功耗影响的考虑,另一方面,在某些系统上,其实无法完全避免 idle state,因为如果没有空闲态的话 CPU 会过热,这会导致 CPU 因为温控措施而被降频。从技术上来讲,这两者的组合在他看来是完全可行的,既然 scheduler 知道了所有 task 的预计执行时间和截止时间(这是 deadline 调度所必须的),而且它又知道了 CPU idle state 的属性。剩下的就是作为调度器该如何正确地使用这些信息。

会议对如何控制 cpu 进入 idle state 做了深入的讨论。Wysocki 对本次讨论非常满意,因为他在这次讨论中了解到了他需要的一些内容,这些会影响他最终提出来的方案和补丁提交。欲了解更多详情请阅读原文 “The deadline scheduler and CPU idle states”

**关键词**: Linux,Deadline,CPU-idle

云端 “休眠(Hibernation)”

Hibernation is normally thought of as a laptop feature — and an old and obsolete laptop feature at that. One does not normally consider it to be relevant in cloud settings. But, at the 2020 Power Management and Scheduling in the Linux Kernel summit (OSPM), Andrea Righi argued that there may actually be a place for hibernation on cloud-based systems if it can be made to work reliably.

Hibernation(休眠)通常被认为是笔记本电脑专用的功能,而且是老旧过时的笔记本电脑才会用的功能(相对于老旧的 S3 睡眠模式,现代的笔记本已经进入了 “Modern Standby” 的时代)。人们通常不认为休眠是云服务环境的菜。但是,在 2020 年的 OSPM 大会上,Andrea Righi 提出,如果能让 hibernation 可靠地工作,那么在云系统上或许也会有其一席之地。更多详细讨论请见原文 “Hibernation in the cloud”

**关键词**: Linux,cloudy,Hibernation


资讯内容部分来自 “LWN.net“。如果您对某些 LWN 文章感兴趣(譬如希望获得全文翻译的)请扫描二维码加微信联系我们:

tinylab wechat

Read Album:

Read Related:

Read Latest: