why can't I match jiffies to uptime?

Question

As far as I know, "jiffies" in Linux kernel is the number of ticks since boot, and the number of ticks in one second is defined by "HZ", so in theory:

(uptime in seconds) = jiffies / HZ

But based on my tests, the above is not true. For example:

$ 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

So "HZ" is 1000, now look at the jiffies and uptime:

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

As we can see, "jiffies" is far different to uptime. I have tested on many boxes, none of the jiffies was even close to uptime. What did I do wrong?

Answer 1

What you're trying to do is how Linux used to work -- 10 years ago.

It's become more complicated since then. Some of the complications that I know of are:

• There's an offset of -5 minutes so that the kernel always tests jiffy rollover.
• The kernel command line can set a jiffy skip value so a 1000 Hz kernel can run at 250 or 100 or 10.
• Various attempts at NoHZ don't use a timer tick at all and rely only on the timer ring and the HPET.
• I believe there are some virtual guest extensions that disable the tick and ask the host hypervisor whenever a tick is needed. Such as the Xen or UML builds.

That's why the kernel has functions designed to tell you the time. Use them or figure out what they are doing and copy it.

Answer 2

Well, I hit the same problem. After some research, I finally find the reason why jiffies looks so large compared to uptime.

It is simply because of

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

The real value of INITIAL_JIFFIES is 0xfffb6c20, if HZ is 1000. It's not 0xfffffffffffb6c20.

So if you want compute uptime from jiffies; you have to do

(jiffies - 0xfffb6c20)/HZ