How does USER_HZ solve jiffy's scaling issue?

Question

As I understand it, the USER_HZ constant was added in Linux 2.6 to solve the problems associated with waiting for the HZ value in user space: in previous versions of Linux, changing the HZ value can cause the value in user space applications to be unintentionally scaled.

I am confused by how the constant USER_HZ solves this scaling problem. For example, let's say a user space application converts jiffies into seconds:

 long MY_HZ = sysconf(_SC_CLK_TCK); /* num_jiffies acquired from /proc but * simplified to 1000 here for clarity */ long num_jiffies = 1000; long num_seconds = num_jiffies / MY_HZ; 

Since the user space application determines the HZ value by calling sysconf , will this not prevent the scaling problem?

If, on the other hand, applications with user space had an HZ value hardcoded in their source, as if the constant USER_HZ prevented the scaling problem - user space applications would use their hardcoded constants, not the USER_HZ system, and there is no guarantee that hardcoded USER_HZ constants match USER_HZ ?

Also, are all the clock values ​​available for user space (e.g. /proc ) already scaled to USER_HZ ? How does a user-space program know if a value in jiffies scales to HZ or USER_HZ ?

Answer 1

USER_HZ was implemented as a compromise: although the user code may have a hard-coded value different from USER_HZ , the Linux kernel has historically had a HZ value of 100 - almost all hard-coded HZ values ​​in the existing user code have been set to 100 .

Here is the essence of what is happening:

 The Linux kernel used to have HZ set at a constant 100 for all architectures. As additional architecture support was added, the HZ value became variable: eg Linux on one machine could have a HZ value of 1000 while Linux on another machine could have a HZ value of 100. This possibility of a variable HZ value caused existing user code, which had hardcoded an expectation of HZ set to 100, to break due to the exposure in userspace of kernel jiffies which may have be based on a HZ value that was not equal to 100. To prevent the chaos that would occur from years of existing user code hardcoding a constant HZ value of 100, a compromise was made: any exposure of kernel jiffies to userspace should be scaled via a new USER_HZ value -- thus preventing existing user code from breaking on machines with a different HZ value, while still allowing the kernel on those machines to have a HZ value different from the historic 100 value. 

Now the question arises as to why some kernel jiffies are exposed to user space without scaling (for example, in /proc/timer_list ). Thomas Glakesner explains :

All instances that are actual APIs, syscalls, as well as various files in proc / must be in USER_HZ, since user space applications depend on the value of USER_HZ.

proc / timer_list is freed from this, as its more debugging interface, which is not part of the strict kernel API. And we really want to see real values, not scaled USER_HZ for this purpose. Hope this answers your question.

Thus, all instances that are part of a strict kernel API are designed to scale the kernel USER_HZ through USER_HZ to impact on user space, which frees up other instances.

see also

Tick ​​Metric: HZ section in Linux Second Kernel Development> Robert Love

Answer 2

From Linux Kernel Development (or the online version of the second edition )

In kernels prior to 2.6, a change in the HZ value led to user space anomalies. This happened because values ​​were exported to user space in units of ticks per second. As these interfaces became permanent, applications grew to rely on a specific HZ value. Therefore, changing the HZ will scale the various exported values ​​with some constants - without knowing the user space. A pastime will read 20 hours when it was actually two.

To prevent such problems, the kernel must scale all exported jiffies. It does this by defining USER_HZ , which is the HZ value that user space expects. On x86, since HZ was historically 100, USER_HZ is 100.

Ticks-per-seconds always scales to USER_HZ when exporting to user space.