Tickless Linux内核是否会引入基准时序变化？

概述我正在运行一些基准测试,我想知道使用“无滴答”(a.k.a CONFIG_NO_HZ_FULL_ALL) Linux内核是否对基准测试有用或有害. 我运行的基准测试每次都会使用一个新进程重复多次.我想控制尽可能多的变异来源. 我在互联网上做了一些阅读： > https://www.kernel.org/doc/Documentation/timers/NO_HZ.txt > https://lwn 我正在运行一些基准测试,我想知道使用“无滴答”(a.k.a 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的调度队列中有多个作业时才会收到滴答.这个想法是,如果队列中有一个唯一的进程,就不会发生上下文切换,因此不需要发送tick.

一方面,没有基准测试得到滴答声似乎是一个好主意,因为我们排除了蜱常规作为变异的来源(我们不知道蜱例程需要多长时间).另一方面,我认为无滴答模式可能会引入基准时序的变化.

考虑我在无滴答内核上运行的基准测试场景.假设我们重复两次基准测试.

>假设第一次运行是幸运的,并被安排到以前空闲的自适应滴答cpu上.因此,该基准不会被刻度中断.
>当基准测试第二次运行时,也许它不是那么幸运,并且被放置在已经安排了一些进程的cpu上.此运行将定期中断刻度,以确定是否应切换其中一个其他进程.

我们知道滴答声会影响性能(上下文切换加上运行例程所花费的时间).因此,第一次基准测试具有不公平的优势,并且似乎运行得更快.

另请注意,最初具有自适应滴答cpu的基准测试可能会发现中间基准测试将另一个进程投入到同一个cpu中.在这种情况下,基准测试最初不接收滴答,然后开始接收它们.这意味着基准性能可能会随时间而变化.

所以我认为无滴答模式(至少在我的基准测试场景下)会引入时序变化.我的推理是否正确？

一种解决方案是使用隔离的自适应滴答cpu进行基准测试(isolcpus任务集),但是我们已经排除了隔离的cpu,因为这会在我们的多线程基准测试中引入人工减速.

谢谢

@H_502_32@解决方法 对于上面的“不吉利”场景,必须在同一处理器上安排活动作业.假设您有多个处理器,则在其他通常空闲的系统上不太可能出现这种情况.即使这种情况发生在一两次,这意味着你的基准可能会看到一两个滴答声的影响 – 这几乎不成问题.

另一方面,如果它发生在更多场合,这将是高处理器负载的一般指示 – 无论如何不是运行基准测试的理想方案.

不过,我建议“滴答”不一定是基准时间变化的重要来源.调度程序应该是O(1).我怀疑你会看到无滴答和非无滴答模式之间的差异有很大差异.

总结

以上是内存溢出为你收集整理的Tickless Linux内核是否会引入基准时序变化？全部内容，希望文章能够帮你解决Tickless Linux内核是否会引入基准时序变化？所遇到的程序开发问题。

如果觉得内存溢出网站内容还不错，欢迎将内存溢出网站推荐给程序员好友。