Linuxには色々な時間変数がありますが、このjiffiesにハメられたので記録しておきます。（勝手にハマっただけ）

変数jiffies

Kernel起動時からtick（タイマー割込み）を数えた回数。
#define HZのCONFIG_HZの値で計算される。
仕事の環境では、HZ=200だった。

jiffiesはHZの間隔でカウントアップされていく値である。
つまり、jiffiesの値をHZで割れば、secが算出されるハズ。

32bit環境

例

jiffies = 348,264 \\
HZ = 200\\
とした場合、\\
\begin{align}
jiffies\ / HZ &= 348,264\ /\ 200 \\
&= 1,741.3\ [sec] \\
&= 29.8\ [min]
\end{align}

この計算は、公式APIのunsigned int jiffies_to_msecs(const unsinged long j)でも同じ計算をしている。
計算式自体は決して間違っていない。

しかし、64bit環境では思ったように答えが出ないのである。

64bit環境

例

jiffies = 4,295,130,087 \\
HZ = 200\\
とした場合、\\
\begin{align}
jiffies\ / HZ &= 4,795,130,087\ /\ 200 \\
&= 2,395,650.435\ [sec] \\
&= 39,927.50725\ [min]
\end{align}

は？20分ぐらいしか待ってないのに何それ？

jiffiesの初期値

このjiffies、初期値がクッソ特徴的である。

32bit環境初期値-5分
64bit環境 32bitの初期値に、上位32bitを0埋め

-5分が初期値って？

\begin{align}
jiffies &= -5\ _{(10)}\ [min] \\
&= -6,000\ _{(10)}\ [sec] \\
&= FFFF\ E890\ _{(16)} \\
\end{align}\\
ただし、64bit環境では上位32bitを0埋めするため、\\
0000\ 0000\ FFFF\ E890\ _{(16)}

32bit環境の場合 FFFF E890
32bitの領域はこれでお終い。0000 0000は32bit領域外。
64bit環境の場合 0000 0000 FFFF E890
64bit幅なので、上位32bit(0000 0000)は0だが領域として存在している。

jiffiesは符号なし

こいつ、負数を初期値に取るクセしてunsigned型なのだ。
つまり、さっきの-5分はどんどんタイマーカウントを進めていって、5分後に綺麗に0000 0000 0000 0000(16)になる。

メモリ幅による値の変化

5分後、jiffiesの値が綺麗に0になるのはいい。
だが、コンピューターにおける**加算して0になる**には注意が必要だ。

32bit幅の場合

結局、(0000 0000) FFFF E890の羅列はtick毎に加算されて行って0になる。
その瞬間は(0000 0001) 0000 0000となる。
だが、上位32bit（0000 0001の部分）は32bit領域外なので消えてしまう。
みんな大好きオーバーフローだ。

その結果、32bitでは0000 0000だけが残り、真に0となってしまう。

64bit幅の場合

0000 0000 FFFF E890は加算され続けることで0になろうとするが、そうは問屋が卸さない。
0000 0001 0000 0000となり、32bit幅では消えてしまった上位32bitの1が残り続ける。
つまり、
0000 0001 0000 0000 (16) = 4294967296 (10)
**0とはならない**のである。

64bit環境では、この値を引いてやらないと正しく計算できないわけだ。

再度、計算し直してみる。

jiffies = 4295130087\\
4294967296 < jiffiesを満たすため、補正処理を導入する。\\
jiffies - 4294967296 = 162791\\
\begin{align}\\
jiffies / HZ &= 162791 / 200\\
&=813.955\ [sec]\\
&=13.6\ [min]\\
\end{align}\\
さらに、開始が-5分であるため\\
18.6[min]

体感で20分ぐらい経ってから取得した値なので、それなりに合ってそう。

結論

みんな大好き、オーバーフローには気をつけようね！！（雑）