Question

据我所知，Linux内核中的“jiffies”是引导后的刻度数，一秒内的刻度数由“HZ”定义，所以理论上：

(uptime in seconds) = jiffies / HZ

但根据我的测试，上述情况并非如此。例如：

$ uname -r
2.6.32-504.el6.x86_64
$ grep CONFIG_HZ /boot/config-2.6.32-504.el6.x86_64
# CONFIG_HZ_100 is not set
# CONFIG_HZ_250 is not set
# CONFIG_HZ_300 is not set
CONFIG_HZ_1000=y
CONFIG_HZ=1000

所以“HZ”是1000，现在看看jiffies和正常运行时间：

$ grep ^jiffies /proc/timer_list
jiffies: 8833841974
jiffies: 8833841974
...
$ cat /proc/uptime
4539183.14 144549693.77

正如我们所看到的，“jiffies”与正常运行时间大不相同。我已经在很多箱子上进行过测试，没有任何一款机器能够接近正常运行时间。我做错了什么？

Answer 1

你要做的是Linux以前的工作方式 - 10年前。

从那以后它变得更加复杂。我所知道的一些并发症是：

有一个-5分钟的偏移，因此内核总是测试jiffy翻转。
内核命令行可以设置一个jiffy跳过值，这样1000 Hz内核可以运行250或100或10。
NoHZ的各种尝试根本不使用计时器刻度，只依赖于计时器环和HPET。
我相信有一些虚拟的访客扩展会禁用勾选，并在需要滴答时询问主机虚拟机管理程序。例如Xen或UML版本。

这就是为什么内核具有告诉你时间的功能。使用它们或弄清楚它们正在做什么并复制它。

Answer 2

好吧，我遇到了同样的问题。经过一番研究，我终于找到了与正常运行时间相比，jiffies看起来那么大的原因。

这仅仅是因为

#define INITIAL_JIFFIES ((unsigned long)(unsigned int) (-300*HZ))

如果HZ为1000，则INITIAL_JIFFIES的实际值为0xfffb6c20。不是0xfffffffffffb6c20。

因此，如果您想通过打桩计算出正常运行时间；你必须要做

(jiffies - 0xfffb6c20)/HZ

为什么我不能将jiffies与正常运行时间相匹配？

2 个答案: