我正在运行一些基准测试，我想知道使用"无时钟"（又名CONFIG_NO_HZ_FULL_ALL）Linux内核对基准测试是有用还是有害。
我正在运行的基准测试每次都会使用新流程重复多次。我想控制尽可能多的变异源。
我在互联网上做了一些阅读：
- https://www.kernel.org/doc/Documentation/timers/NO_HZ.txt
- https://lwn.net/Articles/549580/
从这些资料中，我了解到：
-
在默认配置 （
CONFIG_NO_HZ=y） 中，只有非空闲的 CPU 接收即时报价。因此，在这种模式下，我的基准测试将始终收到即时报价。 -
在"无滴答"模式（
CONFIG_NO_HZ_FULL_ALL），除了一个（引导处理器）之外，所有CPU都处于"自适应滴答"模式。当 CPU 处于自适应时钟周期模式时，仅当 CPU 的计划队列中有多个作业时，才会收到时钟周期。这个想法是，如果队列中只有一个进程，则不会发生上下文切换，因此不需要发送即时报价。
一方面，不让基准接收即时报价似乎是一个好主意，因为我们排除了即时报价例程作为变化来源（我们不知道即时报价例程需要多长时间）。另一方面，我认为无时钟模式可能会在基准计时中引入变化。
考虑一下我在无时钟内核上运行的基准测试场景。假设我们重复一个基准测试两次。
-
假设第一次运行很幸运，并被调度到以前空闲的自适应时钟周期 CPU 上。因此，该基准不会因即时报价而中断。
-
当基准测试第二次运行时，也许它就没有那么幸运了，并且被放在已经安排了一些进程的CPU上。此运行将定期被即时报价中断，以决定我们是否应该切换其他进程之一。
我们知道，即时报价会影响性能（上下文切换加上运行例程所花费的时间）。因此，第一次基准测试运行具有不公平的优势，并且看起来运行得更快。
另请注意，最初具有自适应时钟周期 CPU 的基准测试可能会发现中间基准测试中另一个进程被扔到同一个 CPU 上。在这种情况下，基准最初没有收到即时报价，然后开始接收它们。这意味着基准性能可能会随着时间的推移而变化。
所以我认为无时钟模式（至少在我的基准测试场景中）引入了时序变化。我的推理正确吗？
一种解决方案是使用隔离的自适应时钟周期CPU进行基准测试（isolcpus + taskset），但是我们已经排除了隔离的CPU，因为这会在我们的多线程基准测试中引入人为的减速。
谢谢
对于上面的"不幸"场景，必须在同一处理器上安排一个活动作业。假设您有多个处理器，则在其他通常处于空闲状态的系统上，情况不太可能如此。即使这种情况发生在一两次，这也意味着您的基准测试可能会看到一两次即时报价的影响 - 这似乎几乎没有问题。
另一方面，如果它发生在更多情况下，这将是处理器负载高的一般指示 - 无论如何都不是运行基准测试的理想方案。
不过，我建议，"即时报价"不太可能成为基准时间变化的重要来源。调度程序应该是 O（1）。我怀疑你会看到无滴答模式和非无滴答模式之间的差异很大。