linux – USER_HZ如何解决jiffy扩展问题？

概述据我所知,在 Linux 2.6中添加了USER_HZ常量,以解决用户空间中HZ值预期所引起的问题：在以前版本的Linux中,更改HZ值可能会导致用户空间应用程序中的值无意中缩放. 我对USER_HZ常量如何解决这个缩放问题感到困惑.例如,假设用户空间应用程序将jiffies转换为秒： long MY_HZ = sysconf(_SC_CLK_TCK);/* num_jiffies acqui 据我所知,在 Linux 2.6中添加了USER_HZ常量,以解决用户空间中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,并不能保证硬编码的常量与USER_HZ匹配？

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

解决方法 从 Linux Kernel Development(或 online version of the 2nd Edition)

In kernels earlIEr than 2.6,changing the value of HZ resulted 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 of HZ.
Consequently,changing HZ would 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 defining USER_HZ,which is the HZ
value that user-space expects. On x86,because HZ was historically
100,USER_HZ is 100.

导出到用户空间时,每秒刻度始终会缩放到USER_HZ.

总结

以上是内存溢出为你收集整理的linux – USER_HZ如何解决jiffy扩展问题？全部内容，希望文章能够帮你解决linux – USER_HZ如何解决jiffy扩展问题？所遇到的程序开发问题。

如果觉得内存溢出网站内容还不错，欢迎将内存溢出网站推荐给程序员好友。