gpt4 book ai didi

linux - Tickless Linux 内核是否会引入基准时序变化?

转载 作者:IT王子 更新时间:2023-10-29 00:32:56 24 4
gpt4 key购买 nike

我正在运行一些基准测试,我想知道使用“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/

24 4 0
Copyright 2021 - 2024 cfsdn All Rights Reserved 蜀ICP备2022000587号
广告合作:1813099741@qq.com 6ren.com