我正在运行一些基准测试，我想知道使用“无滴答”（a.k.a CONFIG_NO_HZ_FULL_ALL）Linux内核是否对基准测试有用或有害。
我运行的基准测试每次都会使用新进程重复多次。我想控制尽可能多的变异来源。
我在互联网上做了一些阅读：
从这些来源我了解到：
在默认配置（CONFIG_NO_HZ=y）中，只有非空闲CPU才会收到滴答声。因此，在此模式下，我的基准测试总是接收滴答声。
在“无空闲”模式（CONFIG_NO_HZ_FULL_ALL）中，除了一个（启动处理器）之外的所有CPU都处于“自适应滴答”模式。当CPU处于自适应滴答模式时，仅当CPU的调度队列中有多个作业时才会收到滴答。这个想法是，如果队列中有唯一的进程，就不会发生上下文切换，因此不需要发送滴答。
一方面，由于我们排除了蜱常规作为变异的来源（我们不知道蜱例程需要多长时间），因此没有基准接收蜱似乎是一个好主意。另一方面，我认为无滴答模式可能会引入基准时序的变化。
考虑我在无滴答内核上运行的基准测试场景。假设我们重复两次基准测试。
假设第一次运行是幸运的，并被安排到先前空闲的自适应滴答CPU上。因此，该基准不会被刻度线打断。
当基准测试第二次运行时，也许它不是那么幸运，并且被放置在已经安排了一些进程的CPU上。此次运行将定期打勾，以确定我们是否应该切换其中一个进程。
我们知道滴答声会影响性能（上下文切换加上运行例程所花费的时间）。因此，第一次基准测试具有不公平的优势，并且似乎运行得更快。
另请注意，最初具有自适应滴答CPU的基准测试可能会发现中间基准测试将另一个进程投入到同一个CPU中。在这种情况下，基准测试最初不接收滴答，然后开始接收它们。这意味着基准性能可能会随着时间而变化。
所以我认为无滴答模式（至少在我的基准测试场景下）会引入时序变化。我的推理是否正确？
一种解决方案是使用隔离的自适应滴答CPU进行基准测试（isolcpus + taskset），但是我们已经排除了孤立的CPU，因为这会在我们的多线程基准测试中引入人工减速
由于
答案 0 :(得分：5)
对于上面的“不吉利”场景，必须在同一处理器上安排活动作业。假设您有多个处理器，那么在其他通常空闲的系统上就不太可能出现这种情况。即使这种情况发生在一两次，这意味着你的基准可能会看到一个或两个滴答的效果 - 这几乎不成问题。
另一方面，如果它发生在更多场合，这将是高处理器负载的一般指示 - 无论如何都不是运行基准测试的理想方案。
但我建议，“滴答”不一定是基准时间变异的重要来源。调度程序应该是O（1）。我怀疑你会看到无滴答和非无滴答模式之间的差异很大。