カーネルプリエンプションとレイテンシ

プリエンプションが決めるのは「応答の速さ」

プリエンプション（preemption、横取り）とは、実行中のタスクを途中で止めて、より優先すべき別タスクへ CPU を移すことです。ユーザー空間のコードは古くから横取りできました——タイマー割り込みでタイムスライスを切れば、/os/scheduling/ が次のタスクを選んで /os/context-switch/ を起こせます。

問題は カーネルの中で実行している最中 です。プロセスがシステムコールを発行してカーネルコードを走らせている間、より高優先度のタスクが起床したとき、ただちに横取りしてよいのか。それとも今のカーネル処理が一区切りつくまで待たせるのか。この一点の設計判断が、システムの 最悪応答レイテンシ と スループット を正反対の方向へ引っ張ります。

4つのプリエンプションモデル

Linux はビルド時の設定（CONFIG_PREEMPT_*）で、カーネル内の横取り可否を4段階から選びます。応答性を取るかスループットを取るかの段階的なトレードオフです。

非プリエンプティブ（CONFIG_PREEMPT_NONE）

カーネルコードに入ったタスクは、自分でカーネルを抜ける（ユーザー空間へ戻る）か、明示的にブロックするまで横取りされません。長いシステムコールの最中に緊急タスクが起きても、その処理が終わるまで待たされます。横取りチェックや余計な切り替えが無い分、キャッシュ局所性が保たれ スループットは最大。一括処理に徹するサーバー向けです。

自発的プリエンプション（CONFIG_PREEMPT_VOLUNTARY）

非プリエンプティブを土台に、カーネルの随所へ 明示的なチェックポイント を仕込みます。Linux ではこれが might_resched() / cond_resched() です。長く走るループの区切りで「今、より優先すべきタスクがあるなら譲る」と能動的に問い合わせる方式です。

/* 長いカーネル処理ループの中に置く譲渡ポイント */
for (i = 0; i < huge_count; i++) {
    do_some_work(i);
    cond_resched();   /* 必要なら自発的に横取りを許す */
}

横取りできる地点が「あらかじめ仕込んだ場所」に限られるため、最悪レイテンシは チェックポイント間の最長区間 で決まります。スループットへの悪影響を抑えつつ、突出した遅延だけを削るバランス型です。

フルプリエンプティブ（CONFIG_PREEMPT）

保持区間（後述）でない限り、カーネルコードの任意の地点で横取りを許します。高優先度タスクが起きれば、割り込みからの復帰時などにただちにスケジューラが走ります。最悪レイテンシは小さくなりますが、横取りチェックと切り替えが増える分、/os/context-switch/ のオーバーヘッドが乗り、スループットはやや落ちます。

PREEMPT_RT

リアルタイムパッチ群（長らく out-of-tree、近年メインラインへ統合進行）。フルプリエンプティブでも残る「横取りできない区間」そのものを潰しにいきます。具体的には次のような作り替えを行います。

• スピンロックの多くをスリープ可能なミューテックスに変換し、ロック保持中でも横取り可能にする（優先度継承付き）。
• 割り込みハンドラをカーネルスレッド化（threaded IRQ）し、ハードIRQで止める区間を最小化、本処理をスケジュール可能なスレッドへ追い出す。

これにより最悪レイテンシを 数十マイクロ秒級 まで詰めます。代償は、ロックがスリープ化することによる平均コスト増とスループット低下。遅延の予測可能性（determinism）をスループットで買う のが PREEMPT_RT の本質です。

preempt_count ── 横取りの可否を握る数

「いつ横取りしてよいか」を実際に判定するのが、CPU ごとに持つ プリエンプションカウンタ（preempt_count） です。これが 0 のときだけ横取りを許可 します。

preempt_count は1つの整数に複数の意味を詰めたビットフィールド:

  [ NMI | ハードIRQ | ソフトIRQ | preemptネスト深さ ]

  preempt_disable() → preemptネスト部を +1
  preempt_enable()  → preemptネスト部を -1（0になった瞬間に再スケジュール判定）

  preempt_count != 0  →  横取り保留（atomic context）
  preempt_count == 0  →  横取り許可

スピンロックの取得は内部で preempt_disable() を呼ぶため、ロック保持中は自動的に preempt_count が上がり、横取りされません。割り込み（/os/interrupt-io/）に入ればハードIRQ部のカウントが立ち、これも非ゼロになります。

横取り要求は即実行されるのではなく、まずタスクに TIF_NEED_RESCHED フラグが立つだけです。そして preempt_count が 0 に戻る瞬間（preempt_enable() や割り込み復帰路）に 保留されていた再スケジュールがまとめて実行 されます。

トレードオフを設計判断に落とす

4モデルは「優劣」ではなく 要求の違いへの最適化 です。判断軸を整理します。

決定的なのは「平均が速いか」ではなく「最悪が保証されるか」です。スループット最適のシステムは平均応答が良くても、運悪く長いカーネル処理に重なった瞬間に大きく遅れます。リアルタイム用途が嫌うのはまさにこの テールレイテンシ（tail latency） で、平均を多少犠牲にしてでも上限を縮める PREEMPT_RT が選ばれます。

逆に、機械学習の学習や大規模バッチでは1回の遅延より総スループットが効くため、横取りを増やすのは損です。「何を最適化対象に置くか」を先に決め、それに合うプリエンプションモデルを選ぶ——順序を逆にしてはいけません。

まとめ

• カーネルプリエンプションは カーネルコード実行中の横取りをどこまで許すか の設計で、最悪レイテンシとスループットを正反対に動かす。
• 非プリエンプティブ→自発的→フルプリエンプティブ→PREEMPT_RT の順に最悪レイテンシは縮み、切替増でスループットは下がる。
• preempt_count が0のときだけ横取り可。スピンロック保持中や割り込み中は非ゼロになり、横取りは preempt_enable() や割り込み復帰時まで保留される。
• 選定基準は平均ではなく 最悪値の保証。最適化対象（総処理量か締め切り遵守か）を先に定めてモデルを選ぶ。
• 関連して、切り替えそのもののコストは /os/context-switch/、横取りで選び直す側の仕組みは /os/cfs-scheduler-internals/ も参照。