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

我正在运行一些基准测试,我想知道使用“无滴答”(a.k.a 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任务集),但是我们已经排除了隔离的cpu,因为这会在我们的多线程基准测试中引入人工减速.

谢谢