高分解能タイマとカーネルの時間管理

カーネルが扱う「時間」は一種類ではない

カーネルにとって時間は単一の概念ではありません。少なくとも三つの役割があります。(1) 経過時間を数える時間軸、(2) 「いつ何かを起こすか」という期限の管理、(3) 「今が何時か」という時刻の提供です。これらを別々の仕組みで実現し、組み合わせているのが Linux の時間管理です。役割を混同すると、なぜ計測値がときどき巻き戻るのか、なぜ低負荷でも電力が下がらないのか、といった現象を読み解けません。

jiffies と tick ── 粗いが安価な時間軸

最も古典的な時間軸が jiffies です。これはカーネル起動からのタイマ割り込み（tick）の累積回数を数えた単純なカウンタです。tick の頻度はビルド時定数 HZ で決まり、HZ が 250 なら 1 秒あたり 250 回、すなわち 1 jiffy ＝ 4 ミリ秒です。

1 jiffy = 1 / HZ 秒
  HZ=100  → 10 ms 粒度（旧来サーバー向け）
  HZ=250  → 4 ms 粒度（汎用デスクトップの既定）
  HZ=1000 → 1 ms 粒度（低遅延寄り）

経過判定は引き算ではなく time_after()/time_before() マクロで行う
（jiffies は wrap するため符号付き差分で比較する）

tick は周期割り込みとして到来し、その都度カーネルは時刻の更新、タイムスライスの消費、各種タイマの満了チェックといった定常作業をまとめて処理します。jiffies の利点は 読み出しが極めて安価（メモリ上のカウンタを読むだけ）なことです。欠点は 粒度が tick まかせ で、HZ=250 なら 4 ミリ秒より細かい期限は表現できない点です。長く眠るタイマ（タイムアウトなど精度が要らない用途）には今でも timer_list（バケット分割した timer wheel という仕組みで管理される）が使われ、これは jiffies 基準で動きます。

hrtimer ── ナノ秒粒度の期限を別系統で

ミリ秒粒度では足りない用途——オーディオの再生間隔、nanosleep、SCHED_DEADLINE の予算管理など——のために、jiffies とは独立した hrtimer（高分解能タイマ） があります。hrtimer は満了時刻を ナノ秒の絶対時刻 で保持し、tick の周期に縛られません。

仕組みの要は「期限ごとに割り込みを鳴らす」ことです。tick のように一定間隔で割り込むのではなく、次に満了する hrtimer の時刻に合わせて、ハードウェアタイマへ一発の割り込みを予約 します（後述の clockevent をワンショットモードで使う）。満了したらコールバックを呼び、次の最早期限へ向けて割り込みを再予約します。期限は赤黒木で時刻順に並べられ、挿入・削除は O(log n)、最左端（最も早い期限）はキャッシュされたポインタで O(1) に参照できます。常に必要なのはこの最早期限なので、割り込み予約は安価です。

clocksource と clockevent ── 読む源と鳴らす器の分離

ここまで「時刻を読む」「割り込みを鳴らす」と書いてきました。Linux はこの二つを 別の抽象 として明確に分離します。これが時間管理の設計の核です。

• clocksource（クロックソース）: 単調増加するカウンタを提供し、「今の時刻」を読むための源。TSC、HPET、ACPI PM タイマ、アーキテクチャ固有カウンタなどがこれを実装します。read() でカウンタ値を返し、カーネルが周波数とオフセットからナノ秒へ換算します。役割は 読む。
• clockevent（クロックイベント）: 「指定した未来の時刻に割り込みを発生させる」器。周期モードとワンショットモードを持ち、tick も hrtimer もこれを使って割り込みを鳴らします。役割は 鳴らす。

時刻を知りたい            →  clocksource.read() を読み、ns へ換算
将来の一点で起こしたい    →  clockevent をワンショット設定
一定周期で起こしたい      →  clockevent を周期設定（従来の tick）

clocksource と clockevent は同じ物理タイマでも別チップでもよい。
カーネルは精度・安定性で最良の clocksource を実行時に選ぶ。

分離の利点は、ハードウェアごとの差をこの二層で吸収し、上位の jiffies／hrtimer／時刻 API を共通化できることです。たとえば TSC が周波数可変や CPU 間ずれで信頼できない環境では、カーネルが clocksource を HPET へ切り替えても上位は無変更で動きます。この一発予約の割り込みは /os/interrupt-io/ のハンドラとして配送され、満了処理が走ります。

tickless（NO_HZ）── 周期 tick を止める

周期 tick には弱点があります。CPU が暇でも、あるいは 1 個のタスクしか走っていなくても、HZ 回／秒の割り込みが律儀に入り続けることです。これは省電力を妨げ（アイドルから何度も起こされる）、計算専用コアではジッタの原因にもなります。そこで導入されたのが tickless（NO_HZ） です。

ここで重要な原理があります。tick を止めても時間は止まりません。 周期割り込みで jiffies を逐次インクリメントする代わりに、tick を再開するとき clocksource を読んで「眠っていた間に何 jiffy 進んだか」をまとめて補正します。時刻そのものは clocksource という連続カウンタが握っているので、割り込みを間引いても失われないのです。tick を止める直前には「次に満了する hrtimer はいつか」を確認し、その時刻まで割り込みを予約してから眠ります。

単調時計とウォール時計 ── 巻き戻る時間と巻き戻らない時間

最後に、提供される「時刻」が一種類でない点を押さえます。代表的な二つを区別します。

• ウォール時計（CLOCK_REALTIME）: 人間が読む壁掛け時計の時刻。1970年からの経過秒（UNIX 時刻）で表され、gettimeofday 等が返すもの。これは NTP による補正、管理者の手動変更、うるう秒 で前後に飛びます。つまり 巻き戻りうる。
• 単調時計（CLOCK_MONOTONIC）: ある起点からの経過時間で、決して巻き戻らず後退しない。NTP は刻みの速度を微調整（slew）はしますが、時刻を飛ばすことはありません。区間計測やタイムアウトはこれを使います。

経過時間を測りたい・タイムアウトを置きたい
  → CLOCK_MONOTONIC（巻き戻らない／飛ばない）

「今が何時か」を人間向けに出したい・ログのタイムスタンプ
  → CLOCK_REALTIME（NTP・うるう秒で飛びうる）

派生:
  CLOCK_MONOTONIC_RAW  … NTPのslew補正すら掛けない生カウンタ
  CLOCK_BOOTTIME       … サスペンド中の時間も加算した単調時計

両者の関係は単純です。カーネルは clocksource から得た単調なナノ秒値を基準に持ち、それへ「現在の壁時計オフセット」を足したものをウォール時計として提供します。NTP やうるう秒はこのオフセットを動かすだけで、単調側の連続性には触れません。だから一方は飛び、もう一方は飛ばないのです。

まとめ

• 時間管理は 数える（jiffies）／鳴らす（clockevent）／読む（clocksource） の三役に分解できる。jiffies は tick 回数を数える安価だが粗い軸、hrtimer はそれと独立したナノ秒粒度の期限。
• clocksource は時刻を読む源、clockevent は将来の割り込みを鳴らす器 で、両者の分離がハードウェア差の吸収と上位 API の共通化を可能にする。hrtimer は clockevent のワンショットで動く。
• tickless（NO_HZ） は周期 tick を止めて省電力とジッタ削減を図るが、時刻は連続カウンタの clocksource が握るので止まらない。NO_HZ_FULL は割り込みアフィニティの併用が前提。
• 単調時計は巻き戻らず、ウォール時計は NTP・うるう秒で飛ぶ。 区間計測・タイムアウトには必ず CLOCK_MONOTONIC を使う。
• 高分解能タイマの実精度はプリエンプション設計に依存する。応答レイテンシは /os/kernel-preemption/、締め切り保証は /os/realtime-scheduling/ も参照。