LWN：使用MMTests来对scheduler进行性能测试！

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

Scheduler benchmarking with MMTests

By Jonathan Corbet

May 19, 2020

OSPM

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

主译：DeepL

MMTests benchmarking system，是一个基准测试系统，人们对它的了解通常都来自它最初的应用场景：测试memory-management相关的代码改动。但是，MMTests越来越多地在memory-management测试之外找到了用武之地。在2020 Power Management and Scheduling in the Linux Kernel summit(OSPM)会议上，Dario Faggioli介绍了他如何使用MMTests来评估CPU scheduler改动，也介绍了为了达到这个目的他先进行了哪些改动，并最终获得了对virtualized guests环境测试的有价值的结果。

他的开场白先介绍道，Kernel benchmarking通常是在bare metal环境中完成的。开发人员经常需要知道一个特定的内核更改可能会产生什么样的影响，所以他们会运行一系列测试，试图在可重现的环境（reproducible setting）下测量性能变化。而Faggioli是在SUSE的virualization lab（虚拟化实验室）工作，他们的目标更为复杂。kernel的改变可能会对host宿主机产生某种影响，但对运行在该host上的guest系统却产生了不同的影响。这就导致需要用benchmark来对各种kernel版本（包括baseline基准版本以及各种更改后的版本）进行测试。情况其实更加复杂，就是某个benchmark在host和guest之间运行的时候其实并不确定它分别占用了多少时间，多个guest OS之间竞争时也有同样情况。如果不做一些额外工作的话，仅仅是把这些测试跑起来，得到的结果完全不具备可重复性，很难预测会得到什么结果。

例如，我们在进行一个hypervisor调度公平性的测试。如果调度器是公平的，那么具有同等计算需求的guest应该得到同等数量的CPU时间。也就是我们可以检查是不是每个benchmark的运行时间都是相等的。不过，即使在公平调度（fair scheduling）的情况下，某个虚拟机和另一个虚拟机它们本身的运行时间也可能存在差异。如果运行一系列测试的话，虚拟机具体在什么时间运行测试都是没法预测清楚的，从而使得结果并不稳定。要想得到清晰、确定的结果，唯一的办法就是确保benchmark在所有系统上同步运行(in a synchronized manner)。

他说，有很多benchmarking suites可供选择。不过，没有一个能够在多个虚拟机上同步运行（perform synchronizzed run）。他认为现在是时候实现一个可以做到这一点的测试工具了，但他不想从头开始，所以他基于MMTests开始了自己的工作。

Faggioli说，MMTests suite至少可以追溯到2012年（LWN在那年8月就报道了MMTests）。虽然它最初专注于memory-management代码改动，但现在已经变化很大了。它主要是通过Bash和Perl代码实现的。它的核心代码能够获取、编译、配置和运行一系列的基准测试。也可以进行多次运行然后MMTests会收集保存所使用的配置和所获得的结果。还有一套工具可以比较运行结果，创建图表等。此外，还有一个 "监控（monitor） "功能，可以捕捉各种监控命令（top、vmstat、iostat等）以及ftrace和 perf信息。它可以运行的benchmark集合非常多，包含了内核开发者多年来发现有用的工具中的大多数。

MMTests的配置文件也是一个Bash脚本，其中包含了export行，描述了要运行的test case。有命令用来查询系统特性，比如NUMA node的数量，根据这些信息可以用来选择benchmark的一个子集。Faggioli认为它在使用方法上是很直观的，只要你熟悉你要运行的具体benchmark就可以了。run-mmtests.sh脚本将实际运行测试；有一个compare_mmtests.pl脚本可以查看多次重复运行结果之间的变动。还可以用 graph-mmtests.sh 来制作漂亮的图表。

他也提到可以尝试以普通用户的身份运行MMTests，但这不一定是个好主意。虽然测试不会失败，但MMTests不具备相关的依赖条件就可能进行无效测试。比如说，它可能会尝试对CPU-frequency governor进行修改，却无权改动。MMTests在测试结束后会试图撤销它之前所做的临时改动，但可能的话，最好还是在专门的测试环境中执行，测完重启清理掉最好。MMTests会从互联网来下载benchmark，然后以root身份运行，这可能会吓退一些用户。可以设置一个本地镜像，这对性能和安全都有好处。

专门针对虚拟化的测试，应该使用 run-kvm.sh 脚本；它将从host和guest上收集结果。该脚本会设置并启动所需的虚拟机，同时生成SSH key来方便ssh连接到这些机器。MMTests 目录会被直接复制到虚拟机中，然后在虚拟机里运行测试。他指出host和virtual machine都有独立的配置文件，因为人们可能希望分别独立地调整这两个设置来收集相应的数据。

Faggioli不得不在MMTests中新增的功能，就是Synchronization，这是通过在host和virtual machine之间传递token来实现的。guest系统之间并不会直接对话。在每次基准运行之前，主机起到了一个 "barrier"的作用，等到每个虚拟机都通知主机准备好了下一个测试，才会告诉它们都开始进入下一个测试。这样可以确保所有系统上的测试都在同一时刻开始。

Faggioli有许多patch ，本打算在演讲之前提交，因为他宣称自己很喜欢 "conference-driven development（会议驱动开发）"，但还是没能按时完成。不过应该很快就会提交出来了。关于文档，他说，根本没有文档。但至少在虚拟机同步脚本中有一个漂亮的ASCII-art图。他最后说，他曾考虑过用go来完全重写，但他不确定MMTests的维护者Mel Gorman是否愿意接受这样的想法。Gorman出席了此次活动，现场他并没有跳出来大发雷霆。

Faggioli介绍完毕后，Douglas Raillard发言说，Arm有一个测试套件（https://workload-automation.readthedocs.io/en/latest/ ），不过这个workload-automation工具里面也缺少虚拟机同步的功能。此工具会对结果进行了一些统计性地数据分析。他想知道是否有计划将其添加到MMTests中。Faggioli说，他不是统计学家，并不适合来添加这个功能。Gorman说，MMTests做了许多工作来试图猜测某个差异数值是否值得重视，不过这个信息在输出内容中不够显眼，经常会被错过。不过这个功能也没有记录在文档里。Raillard提问如何能获得JSON格式的输出，Faggioli说JSON确实是有的，只是他没有使用过。

会议到此结束。详细内容、图例、配置文件等请参见Faggioli的幻灯片[https://lwn.net/images/conf/2020/ospm/faggioli-mmtests.pdf]。

全文完

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

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

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