コンテキストスイッチは実際に何のコストがかかり、なぜそれが重要なのですか?

Question

IT Interview Practice · Accepted Answer

**コンテキストスイッチ (context switch)** は、kernel が現在実行中のスレッドの CPU 状態 (レジスタ、プログラムカウンタ、スタックポインタ) を保存し、別のスレッドのそれを復元することで、1 つのコアが多数のスレッドを多重化できるようにするものです。scheduler のプリエンプション、ブロッキング syscall、割り込みのたびに起こり — そして無料ではありません。

## コストはどこに隠れているか

```text
DIRECT cost (visible, ~1–5 µs):
  save/restore registers · run scheduler logic · switch kernel stacks
  if PROCESS switch: also swap page tables (CR3) → FLUSHES the TLB

INDIRECT cost (often much larger):
  cold CPU CACHES → the new thread's data isn't in L1/L2/L3 → cache misses to RAM
  cold TLB        → address translations must be re-walked
  lost pipeline / branch-predictor state
```

**直接的な** コストは数マイクロ秒です。**間接的な** コスト — スイッチ後の冷えたキャッシュと TLB — がしばしばより大きな打撃です: 入ってきたスレッドは、メインメモリからキャッシュを再び暖める間しばらく遅く走ります (ミスごとに数十〜数百サイクル)。

## スレッド切り替え vs プロセス切り替え

**同じプロセスのスレッド間** の切り替えは安価です: アドレス空間を共有するので、page table (と、タグ付き TLB / PCID のないハードウェアでは TLB) を変える必要がありません。**プロセス** の切り替えは、加えて page-table のベースレジスタを再ロードし、伝統的には TLB をフラッシュします — だからコストが高いのです。

## 実際になぜ重要か

- **スレッドが多すぎる** → scheduler がスラッシュし、仕事ではなく切り替えにサイクルを費やします。ある点を超えると、コアより多いスレッドはスループットを *減らします*。
- これは **async / event-loop** モデル (Node、nginx、`io_uring`) や **goroutine / green thread** の中核的な論拠です: 少数の OS スレッドで多数の接続を処理し、リクエストごとの切り替えを避けます。
- **CPU ピンニング / affinity** がレイテンシに敏感なサービスを助ける理由です — スレッドを 1 つのコアに保ち、暖かいキャッシュを保存します。
- 高い非自発的 (involuntary) コンテキストスイッチ数 (`vmstat`、`pidstat` で見える) は、lock 競合や CPU の過剰割り当ての典型的な症状です。

## なぜ重要なのか

これはシニアレベルの質問です。*用語* を知る人と、*なぜ* 高コストかを理解する人を分けるからです — そして本当の答え (単なるレジスタ保存でなく cache/TLB の汚染) がアーキテクチャ判断を左右します: thread-per-request より async I/O、スレッドプールをコア数に合わせる、affinity の使用。スケジューリング、仮想メモリ、CPU キャッシュを 1 つのパフォーマンスの物語に結びつけます。

コストはどこに隠れているか

スレッド切り替え vs プロセス切り替え

実際になぜ重要か

なぜ重要なのか

関連する質問