LWN: OSPM会议讨论如何测试scheduler行为

点击上方蓝色字关注我们~

Scheduler behavioral testing

July 10, 2019

---

OSPM

译者注：OSPM是刚刚结束的第三届Operating-System-Directed Power-Management summit会议。近期LWN发布了一部分会议议题的讨论。本文正是其中一篇。

对scheduler的行为进行测试，是件很麻烦的事情，因为有多个决策依据来共同决定了task的执行分配情况。来自Arm的Valentin Schneider介绍了他的团队（实现energy-aware scheduling也就是EAS的团队）怎么处理这个问题的。

Energy-aware scheduling依赖多个模块的配合工作，这里出现的任何bug都可能会影响task在多个CPU上的分布。模块列表包括这些：

1. per-entity load tracking (PELT)，用来了解这些task实际上使用了多大的CPU计算量。

2. cpufreq (schedutil), 根据给定的workload来决定CPU应该调整到哪个频率。

3. misfit，来将那些CPU密集型的task从小核迁移到大核上去。

Arm设计了一个LISA test framework来帮助验证这些功能，主要用于下面两种方式：

1. 两周一次mainline integration：这部分工作包括提取最新的tip/sched/core目录代码，打上团队内部那些尚未合入的patch（主要包含已经在mailing list上讨论的patch）。然后在各种Arm开发板上进行几百轮的测试。这里Rafael J. Wysocki提出他的那些patch不在tip/sched/core目录下，但是Arm应该也带上这些patch，因为Arm肯定还是需要一个能正常工作的cpufreq实现方案的。这里没有什么反对意见，后续Wysocki的linux-pm分支代码也会被包含进后续的mainline integration流程里。

2. patch验证：想要快速验证自己的patch（或者自己正在review的patch）的开发者可以使用LISA来进行测试，既可以基于他们自己桌上的开发板，也可以基于CI（continuous integration）系统的开发板。

简略来说，LISA所运行的测试包含一些通过rt-app工具人为造出来的workload，会跟踪记录执行过程中的trace，然后对trace结果进行后处理。之所以使用rt-app，是希望能仔细造出各种scheduler特定场景下的workload，也希望能尽量减少引入其他功能的影响。因此hackbench这类工具并不能替代rt-app的作用。

以EAS行为测试集为例，因为LISA使用rt-app来造出workload，它就很容易能读入rt-app workload的定义，来估计生成的每个task所占用的计算量，甚至在真正运行之前就能推算出正确的行为。而EAS使用的energy model模型也是对user space可见的（通过debugfs），因此测试工具也能取到这些参数。

拿到这两部分数据之后，就可以估计出这些task最节能的运行方式应该是怎样的，分别运行在哪些CPU上，从而算出一个较优的“energe budget”。然后可以真正运行这些workload，记录下这些task执行的时间以及利用了哪个CPU（通过sched_switch和sched_wakeup trace events记录的信息）。利用同样的energy model计算之后，就能估计出这种执行策略耗费了多少功耗，从而跟之前估计的最优值“energy budget”做对比。

不过，功耗并不是唯一需要关注的。我们必须要确保也达到足够的性能指标。rt-app提供了一些执行之后的统计信息，这样就能在执行一轮之后提供足够数据来分析功耗以及性能了。

Load-tracking signal (PELT)测试也依赖于kernel trace events。不过在upstream kernel里还没有PELT相关的event，并且scheduler maintainer希望尽量避免增加新的scheduler trace events。主要是担心这会增加一些其他user-space工具依赖的接口（ABI），今后就不得不一直维持着、无法删除掉了。目前来说，这部分测试使用的这些trace events还没有合入Linux mainline。

Giovanni Gherdovich在这里插进来补充，他认为这些trace event对debug来说非常游泳，他已经在几年前就开始把这些trace event backport回他的kernel代码里了。好在Qais Yousef已经在准备一个很可能被接受进mainline的方案了，包括怎么区分这些trace point，以及相对应的trace event的含义，至少目前还没有太多反对意见。详情见此：https://lwn.net/ml/linux-kernel/20190604111459.2862-1-qais.yousef@arm.com/

Schneider也指出他曾经利用这个framework来写了一个test case，用于他进行第一次mainling list patch review做参考。据他所说，LISA framework很简单清晰，能轻松创建各种workload，然后通过trace event来验证系统的行为是否和patch set相符，哪怕他看不懂代码实现机制，也能通过这个framework的结果展示来更好的理解。他认为对patch reviewer和developer来说都是一个很好上手的工具。

正如之前所说的，这类测试需要尽量针对某一类特定的scheduler行为，需要尽可能避免引入其他不受控制的任务的干扰。这里就需要使用buildroot来生成一个最小化的能正常工作的系统。如果没法使用特定的user space（例如正在测试Android的商用设备），就可以用freezer cgroup来获得具有参考价值的（但是仍然有干扰的）数据。

所有这些试图构造一个纯净工作环境的措施，仍然无法完全避免系统中某些task的执行，例如sshd, adbd, NFS数据交互等。这就是为什么这些测试中也需要监控那些与测试无关的task（noisy tasks）的执行，确保它们占用的CPU时间比例要足够小。如果不满足要求的话，就得把测试结果标为“undecided”。这种测试结果（既不是pass也不是fail）主要是加进来希望能避免忽略掉一些真正的错误：如果某个test已知非常容易受到其他后台进程动作的影响、通常都会有~20%左右的失败率，那么这些失败的结果其实就不会有人去看了（就像狼来了的故事）。为了能更容易的检测出bug和error，就需要明确标示出这些未能满足较纯净测试环境要求的test，忽略这些测试结果可以合理的节省大家时间。

在HiKey 960开发板上，经常出现的noisy tasks就有：

- irq/63-tsensor (温度报警的IRQ）

- sshd

- rcu_preempt

- sugov (scheduler governor kthread)

这些task通常都只占1%不到的时间，影响不大。知道系统上定制的workload之外还有哪些workload在进行，对分析scheduler行为是很有必要的。

全文完

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

极度欢迎将文章分享到朋友圈 
热烈欢迎转载以及基于现有协议上的修改再创作～

长按下面二维码关注：Linux News搬运工，希望每周的深度文章以及开源社区的各种新近言论，能够让大家满意～