LWN 145973: HZ 值应该多少合适

原文：How fast should HZ be? 原创：By corbet @ Aug. 2, 2005 翻译：By unicornx of TinyLab.org 校对：By guojian-at-wowo

There has been a debate slowly simmering on linux-kernel over an issue which, to most Linux users, will be invisible. Still, it points at the sorts of tradeoffs which must be made when configuring a system, and thus merits a look.

在 Linux 内核社区中，有一个问题，它并不是很引人关注，但却时不时地被人提及。而且我们在配置内核时也经常在这个问题上左右权衡，因此值得在此给大家介绍一下。

One of the features which will be included in the 2.6.13 kernel is the ability to configure the frequency of the timer interrupt at kernel build time - at least, on the i386 architecture. This capability, by itself, is not controversial, but the new default value for HZ (250) is. Some developers think it is too low, while others (fewer) think it is too high. It does not appear that there is a single “right” value for this variable.

2.6.13 内核中引入的一个新特性是能够在构建内核时配置定时器中断的频率（译者注：指下文的 HZ 值），目前仅限于 i386 架构。针对该功能本身并没有什么争议，但引人注意的是，这次内核把新的 HZ 默认值修改为 250。有些开发人员认为它太低了，而另一些人（相对少数）则认为它太高。该值究竟应该取多少似乎并没有一个统一的答案。

HZ is the frequency with which the system’s timer hardware is programmed to interrupt the kernel. Much of the kernel’s internal housekeeping, including process accounting, scheduler time slice accounting, and internal time management, is done in the timer interrupt handler. Thus, the frequency of the timer interrupt affects a number of things; in particular, it puts an upper bound on the resolution of timers used with the kernel. If HZ is 1000 (the i386 default for 2.6 kernels through 2.6.12), then timers will have a best-case resolution of 1ms. If, instead, HZ is 100 (the 2.4 and prior default), that resolution is 10ms.

内核根据配置的 HZ 值对定时器硬件编程，设置其产生时钟中断的频率。内核中大部分的内部事务，包括进程统计，调度器时间片统计和内部时间管理都在定时器中断处理函数中完成。 因此，定时器中断的频率大小会影响许多事情；特别是它的值限制了内核内部定时器分辨率的上限。如果 HZ 是 1000（以 i386 架构为例，在 2.6 系列中 2.6.12 版本之前的默认值），则定时器的最高分辨率为 1 ms。 如果 HZ 是 100（内核版本 2.4 系列以及之前的默认值），那么分辨率仅为 10 ms。

The 250Hz default in 2.6.13 gives a maximum timer resolution of 4ms, which is said to be insufficient for many multimedia-oriented applications (and others which need higher-resolution timers). Such applications, in that environment, will be forced to use busy-waiting to achieve delays which are below the best resolution offered by the system, with the usual effect on CPU utilization. It is not the way the developers of these applications want to go.

2.6.13 中将 HZ 的默认值修改为 250 Hz，这决定了定时器分辨率的最大值可以达到 4ms，但即便这样，对于许多面向多媒体的应用程序（以及其他需要更高分辨率定时器的应用）来说仍然不够。 所以，有些应用程序会使用忙等待来实现更低的延迟，但这么做对 CPU 的利用率通常会产生影响，并不推荐使用。

The arguments in favor of reducing HZ center around efficiency. A slower timer interrupt is said to require less power, since the processor (if relatively idle) will wake up less often. Thus, a lower value of HZ is supposed to be better for laptop users. The timer interrupt handler also requires CPU time (and a context switch, and cache space) every time it runs; running that handler less often will clearly reduce its overhead.

赞成降低 HZ 值的人主要是从减少能耗的观点出发。定时器中断频率越慢，系统消耗的能量就越少，因为这种情况下相对空闲的处理器就不会被频繁地唤醒。可见，对于笔记本电脑的用户来说，选择较低的 HZ 值会更好一些。定时器中断处理函数每次运行时都会消耗 CPU 时间（除此之外还会引入额外的上下文切换，或者导致当前执行路径的高速缓存被替换）; 较少地执行该中断自然会明显地降低整体的开销。

Part of the problem, however, is that nobody has quantified the savings which can be expected from a slower timer interrupt. That changed, however, when Marc Ballarin posted some results from tests he had run. His initial test, involving an idle system, showed that power consumption varied from 7.59 watts with a 100Hz timer frequency to 8.15W at 1000Hz. A subsequent test with KDE running showed a smaller savings, especially when artsd was running.

当然，在这个问题上之所以大家一直没有统一的结论，究其原因，也在于一直没有人能够针对降低定时器中断频率所带来的节能效果给出可量化的数据说明。 但该问题目前有了新的进展，Marc Ballarin 发布了他的一些测试结果。 初步的测试基于一个空闲的系统，对比情况如下：HZ 值为 100 时功耗为 7.59 瓦特，升高到 1000 时功耗变为 8.15 瓦特。后续测试 表明，当系统运行 KDE 时功耗的节能效果对比趋向不明显，尤其是在 artsd 运行的时候（译者注，即一旦系统进入繁忙状态后，降低定时器中断频率并没有给节能带来大的改善）。

These results have given ammunition to both sides. Advocates of a low HZ value see the potential for a half-watt savings as worthwhile. Those who want HZ to be high see, instead, a change which makes the system less effective for them while yielding minimal advantages in real-world use.

这样的测试结果使得问题的争论更加相持不下。拥护低 HZ 值的人认为即使只节省 0.5 瓦也是值得尝试的。而那些希望使用较高 HZ 的人则认为降低 HZ 值所带来的能耗节省实在有限，而采用较低的 HZ 值只会影响他们实际应用的运行效率。

If there is a consensus on this issue, it would appear to be that the real solution is the dynamic tick patch. By causing timer interrupts to happen only when there is actually something to be done, the kernel can simultaneously support higher-resolution timers and reduce the actual incidence of timer interrupts. No commitments have been made, but there seems to be a widely-held opinion that the dynamic tick patch will be merged once it has been sufficiently cleaned up; some architectures (e.g. ARM) already have it. To that end, Con Kolivas has posted a reworked version of that patch for review.

看来只有寄希望于动态时钟（dynamic tick） 这样的解决方案才可以让大家在这个问题上达成共识。通过仅在实际需要执行某些任务时才触发定时器中断，内核可以支持更高精度的定时器同时还能减少定时器中断的实际发生次数。虽然还没有完全确定，但主流的观点认为，一旦清理完成，动态时钟补丁应该很快就会被内核主线所接纳；其实有些体系结构（例如 ARM）已经支持了该功能。 为此，Con Kolivas 发布了一个修改后的版本 供大家进一步审查。

If this patch is to be merged soon, it has been asked, why make a change to HZ in the mean time? No answers to that question have been posted. It is true that the lower value of HZ has been in the mainline for some time (and in -mm for even longer) and the number of real complaints has been small. In the absence of problems noted by a wider group of testers, the default value of 250 for HZ seems likely to persist into the final 2.6.13 release. It remains to be seen, however, what value the distributors will pick for the kernels they ship.

有人不禁会问，如果这个补丁很快就会被合入，为什么内核还要修改 HZ 的缺省值呢？看起来没有人愿意回答这个问题。诚然，在主线内核上，HZ 的缺省值曾经在很长一段时间内一直维持在一个更低的值（在 -mm 代码库中其历史甚至更长），而真正对此产生抱怨的情况其实并不多。看起来只要没有什么特别明显的问题会引起广大测试人员的注意，新的 HZ 默认值 250 也会被 2.6.13 版本所接受。至于各个系统发行版的制作人员具体会为他们的内核选择什么样的 HZ 值，还有待进一步的观察。