linux - USER_HZ 如何解决 jiffy 缩放问题？

Question

据我了解，USER_HZ 常量是在 Linux 2.6 中添加的，以解决由用户空间中的 HZ 值期望引起的问题:在以前的版本中Linux，更改 HZ 值可能会导致用户空间应用程序中的值无意间缩放。

我对 USER_HZ 常量如何解决这个缩放问题感到困惑。例如，假设用户空间应用程序将 jiffies 转换为秒:

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;

由于用户空间应用程序通过 sysconf 调用确定 HZ 值，这是否可以防止缩放问题？

另一方面，如果用户空间应用程序确实将 HZ 值硬编码到它们的源代码中，那么 USER_HZ 常量防止缩放问题——用户空间应用程序将使用它们的硬编码常量而不是系统的USER_HZ，并且不能保证硬编码-coded 常量匹配 USER_HZ?

此外，用户空间可用的所有时钟滴答值(例如 /proc)是否都已缩放到 USER_HZ？用户空间程序如何知道 jiffies 中的值是缩放到 HZ 还是 USER_HZ？

Answer 1

USER_HZ作为折衷方案实现:尽管用户代码可以具有不同于 USER_HZ 的硬编码值, Linux 内核历史上有一个 HZ 100 的值——因此几乎所有硬编码 HZ现有用户代码中的值已设置为 100。

这是发生的事情的本质:

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: e.g. 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.

现在，这留下了为什么一些内核 jiffies 暴露给未缩放的用户空间的问题(例如在 /proc/timer_list 中)。 Thomas Gleixner explains :

All instances which are de facto APIs, syscalls and also various files in proc/ must be in USER_HZ because userspace applications depend on the USER_HZ value.

proc/timer_list is exempt from that because its more a debugging interface which is not part of the strict kernel API. And we really want to see the real values and not the scaled USER_HZ ones for that purpose. I hope that answers your question.

因此，所有属于严格内核 API 的实例都旨在通过 USER_HZ 扩展内核 jiffies。在暴露于用户空间之前，其他实例是免除的。

另见

The Tick Rate: HZ section of Linux Kernel Development Second Edition by Robert Love