我对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,并不能保证硬编码的常量与USER_HZ匹配？
此外,用户空间(例如/ proc)可用的所有时钟滴答值是否已经缩放到USER_HZ？用户空间程序如何知道jiffies中的值是否缩放为HZ或USER_HZ？
解决方法
In kernels earlier than 2.6,changing the value of
HZresulted in
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 value ofHZ.
Consequently,changingHZwould scale varIoUs exported values by
some constant—without user-space knowing. Uptime would read 20 hours
when it was in fact two.To prevent such problems,the kernel needs to scale all exported
jiffies values. It does this by definingUSER_HZ,which is theHZ
value that user-space expects. On x86,becauseHZwas historically
100,USER_HZis 100.
导出到用户空间时,每秒刻度始终会缩放到USER_HZ.
