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，因为这会在多线程基准测试中引入人为的减速。
谢谢
- 我不这么认为，否则它就不是真正的无滴答系统了...（正如您所指出的，通常会为每个处理器分配进程 - 其中一些进程可能正在睡眠，等待网络I/O等 - 无滴答系统的整个重点在于当您不需要它们时不要有滴答声）。
- 只有当处理器上有2个或更多活动进程调度时，它才会接收到滴答声，对吗？如果这种情况发生超过几次，您的系统将负载过重。如果您正在进行基准测试，则不应该出现这种情况。
- davmac