Tickless Linux内核是否引入基准时序变化?

Edd*_*ett 7 linux performance benchmarking kernel scheduling

我正在运行一些基准测试,我想知道使用"无滴答"(又称CONFIG_NO_HZ_FULL_ALL)Linux内核是否对基准测试有用或有害.

我运行的基准测试每次都会使用一个新进程重复多次.我想控制尽可能多的变异来源.

我在互联网上做了一些阅读:

从这些来源我了解到:

  • 在默认配置(CONFIG_NO_HZ=y)中,只有非空闲CPU接收滴答.因此,在这种模式下,我的基准测试总会得到滴答声.

  • 在"无空闲"模式(CONFIG_NO_HZ_FULL_ALL)中,除了一个(启动处理器)之外的所有CPU都处于"自适应滴答"模式.当CPU处于自适应滴答模式时,仅当CPU的调度队列中有多个作业时才会收到滴答.这个想法是,如果队列中有唯一的进程,则不能进行上下文切换,因此不需要发送tick.

一方面,没有基准测试接收滴答声似乎是一个好主意,因为我们排除了滴答程序作为变异的来源(我们不知道滴答程序需要多长时间).另一方面,我认为无滴答模式可能会引入基准时序的变化.

考虑我在无滴答内核上运行的基准测试场景.假设我们重复两次基准测试.

  • 假设第一次运行是幸运的,并被安排到先前空闲的自适应滴答CPU上.因此,该基准不会被刻度中断.

  • 当基准测试第二次运行时,也许它不是那么幸运,并且被放置在已经安排了一些进程的CPU上.此运行将定期中断刻度,以确定是否应切换其中一个其他进程.

我们知道滴答声会影响性能(上下文切换加上运行例程所花费的时间).因此,第一次基准测试具有不公平的优势,并且似乎运行得更快.

另请注意,最初具有自适应滴答CPU的基准测试可能会发现中间基准测试将另一个进程投入到同一个CPU中.在这种情况下,基准测试最初不接收滴答,然后开始接收它们.这意味着基准性能可能会随时间而变化.

所以我认为无滴答模式(至少在我的基准测试场景下)会引入时序变化.我的推理是否正确?

一种解决方案是使用隔离的自适应滴答CPU进行基准测试(isolcpus+ taskset),但是我们已经排除了隔离的CPU,因为这会在我们的多线程基准测试中引入人工减速.

谢谢

dav*_*mac 5

对于上面的"不幸"场景,必须在同一处理器上安排活动作业.假设您有多个处理器,那么在其他通常空闲的系统上就不太可能出现这种情况.即使这种情况发生在一两次,这意味着你的基准可能会看到一两个滴答的影响 - 这几乎不会成为问题.

另一方面,如果它发生在更多场合,这将是高处理器负载的一般指示 - 无论如何不是运行基准测试的理想方案.

不过,我建议,"滴答"不一定是基准时间变化的重要来源.调度程序应该是O(1).我怀疑你会看到无滴答和非无滴答模式之间的差异有很大差异.