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