Where is config hz

System timer tick rate is called frequency tick rate , expressed as HZ in the kernel. To X86, for example, before the kernel size of 2. This change makes the accuracy of the system timer resolution increased from 10ms to 1ms, which greatly improves the system drive events scheduled for time accuracy. Too often the clock interrupt inevitably increases system overhead. The system timer is relatively dynamic timer, which is scheduled events execution scheduler time to happen at some point in the future.

Kernel can dynamically create or destroy a dynamic timer. And the system timer interrupt handler kernel is the central management mechanism, following the work interrupt handlers work done some of the timer period using the system to perform:. On the run queue 3 in a symmetric multiprocessor system SMP , each of the equalizer processor scheduling. Core dynamic timer depends on the system clock interrupt, because only the system clock interrupt occurs after the kernel will go to check whether the current dynamic timer expires.

X86 architecture, the 2. Dynamic timers may time out at any time, but only when the system clock interrupt arrives kernel will check the implementation of dynamic timer timeout, the average error is about half the dynamic timer system clock cycle ie 0. Tech Community Register Log in. FaceBook Share. For different reasons you can or have to choose some options at compile time.

For linux you have a whole system: the config family of make Configuration targets to configure the Kconfig "symbols" in a logical hierarchical way, with good explanations online help. Because there are a lot of dependencies, intra- and extraplatform. I had a hard time finding this "HZ" from inside make nconfig. So the Timer frequency is a submenu of "Processor type This ncurses popup "window" contains the relevant info to "where is HZ defined".

Just by checking where these 19 Kconfigs lie their directory names you get a good impression. So yes, some kind of magic , a selfmade preprocessor partly in C source code!

There is a fine line between "make magic" and "header soup". Thanks to your hints I found a nice find-prune-grep sequence. Sign up to join this community. The best answers are voted up and rise to the top. Of course, this all balances out and fairness is preserved, because all tasks receive the same imprecision in schedulingbut that is not the issue. The problem stems from the latency created by the delayed preemption.

If the to-be-scheduled task had something time sensitive to do, such as refill an audio buffer, the delay might not be acceptable. Increasing the tick rate to Hz lowers the worst-case scheduling overrun to just 1 millisecond, and the average-case overrun to just 0. Now, there must be some downside to increasing the tick rate or it would have been Hz or even higher to start. Indeed, there is one large issue: A higher tick rate implies more frequent timer interrupts, which implies higher overhead, because the processor must spend more time executing the timer interrupt handler.

The higher the tick rate, the more time the processor spends executing the timer interrupt. This adds up to not just less processor time available for other work, but also a more frequent thrashing of the processor's cache. The issue of the overhead's impact is debatable. However, how substantial is the overhead to begin with?

Nevertheless, it is possible in 2. On x86, , , and , all work fine. A Tickless OS? You might wonder whether an operating system even needs a fixed timer interrupt.

Is it possible to design an OS without ticks? Yes, it is possible but it might not be pretty. There is no absolute need for a fixed timer interrupt. 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 the i default for 2. If, instead, HZ is the 2. The Hz default in 2. 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. 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.