linux tick异常变化,Tickless Linux内核是否引入基准时序变化？

我正在运行一些基准测试,我想知道使用"无滴答"(又称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,因为这会在我们的多线程基准测试中引入人工减速.

谢谢