CPUアフィニティとロードバランシングの内部

なぜ「全CPUを一つのキュー」にしないのか

マルチコア機でタスクを公平に走らせたいなら、全CPUで1本のグローバルランキューを共有すればよさそうに思えます。しかしそれは破綻します。ランキューは1つのロックで守られるため、コア数に比例してロック競合が悪化し、しかも別ソケットのコアへ無頓着にタスクを移すとL1/L2/LLCのキャッシュ温度を毎回捨ててしまうからです。

そこでLinuxはCPUごとに独立したランキューを持たせます（ランキュー構造）。ロック競合は局所化されますが、今度は別の問題が生まれます。あるCPUに4タスク、隣に0タスクという偏りが放置されると、せっかくのコアが遊びます。この偏りを定期的に均すのがロードバランシングで、本記事の主題です。鍵は「どこへ動かすか」をハードウェアの距離に基づいて決めることにあります。

スケジューラドメイン：CPUを距離の階層で捉える

カーネルはCPUトポロジを**スケジューラドメイン（sched domain）の入れ子として表現します。下位ほどCPU間が近く（移動が安く）、上位ほど遠い（移動が高い）という階層です。各ドメインはスケジューラグループ（sched group）**に分割され、バランシングはタスク単位ではなく「グループ間の負荷差」を見て判断します。

バランサは下位ドメインから順に均しを試みます。SMT内で偏りが解消できればそこで止め、駄目なら一つ上のMC、それでも駄目ならNUMAへ——と範囲を広げます。これは「できるだけ安いペナルティで偏りを直す」貪欲な方針で、キャッシュコヒーレンシの観点でも、近いCPUへ移すほど無効化すべきキャッシュラインが少なくて済みます。負荷の指標はタスク数そのものではなく、各タスクの実行可能性を加重平均したPELT（Per-Entity Load Tracking）由来の負荷で、CFS／EEVDFの実行時間会計と同じ重み付けに基づきます。

3種類のロードバランシング

均しは単一の仕組みではなく、起動契機の違う3系統が役割分担します。混同すると「なぜこのタスクがこのCPUに居るのか」を読み違えます。

定期バランシングはtickのたびに、ただし各ドメインに設定された間隔（balance_interval）を満たしたときだけ走ります。最も負荷の高いグループ（busiest group）を探し、そこから自CPUへタスクを引っ張るpull型が基本です。pull型を選ぶのは、引く側（暇なCPU）が自分のランキューロックを起点に動けて競合が小さいためです。

newidleバランシングは、あるCPUのランキューが空になりidleへ入る寸前に発火します。「アイドルするくらいなら近場から1つ引いてこよう」という発想で、レイテンシ重視ゆえに探索範囲を絞ります。これが効きすぎると逆効果になるため、sysctlのsched_migration_cost_nsが「直近に走ったばかりのタスクはキャッシュが温かいので引かない」というガードとして働きます。

wakeupバランシングだけは性質が異なります。タスクが起床したとき、select_task_rqが走り先を選びます。ここでは「直前に走っていたCPU（キャッシュが温かい）」と「起こした側のCPU（データが近い可能性）」を天秤にかけ、wake_affineヒューリスティクスがLLCを共有する範囲で温かい方へ寄せます。プロデューサ／コンシューマ型ワークロードの性能はこの判断に強く依存します。

キャッシュ温存とピン留め

タスクを動かすコストの正体はキャッシュの作り直しです。CPU-Aで走っていたタスクのワーキングセットはAのL1/L2に載っています。これをCPU-Bへ移すと、Bでは全てキャッシュミスから始まり、移動先がリモートNUMAノードならメモリ局所性まで崩れてリモート参照の遅延が上乗せされます。バランサがドメイン階層を下位優先で辿るのは、この作り直しコストを最小化するためでした。

それでもバランサの自動判断は確率的で、レイテンシが厳しいワークロードでは「たまに遠くへ飛ばされる」だけで尾レイテンシ（テールレイテンシ）が悪化します。そこで明示的に**CPUアフィニティ（ピン留め）**を設定し、タスクが走れるCPU集合を 0x1 のようなビットマスクで固定します。手段は taskset か sched_setaffinity(2) で、cgroup v2 なら cpuset.cpus でグループ単位に縛れます。

隔離：isolcpusとnohz_full

ピン留めは「このタスクをここで走らせたい」という指定ですが、それだけでは指定CPUに他のタスクやバランサが入り込むのを防げません。レイテンシが最優先の用途（高頻度取引、リアルタイムDSP、DPDKのポーリングループ）では、CPUを丸ごと隔離して汎用スケジューラの管轄から外します。

カーネル起動パラメータ isolcpus=2,3 を渡すと、対象CPUはロードバランシングの対象から除外され、自動配置でタスクが流れ込まなくなります。そのCPUで走らせるには明示的なアフィニティ指定が必要になり、結果として「指定したスレッドだけが、邪魔されずに占有する」状態を作れます。さらに nohz_full=2,3 を併せると、そのCPUで実行可能タスクが1つだけのときスケジューラtickを止めることができ、周期割り込みによるジッタすら排除できます。

隔離は強力ですが、外したCPUの数だけ汎用プールが痩せます。OSの雑多な処理（カーネルスレッド、割り込みハンドラ、RCU猶予期間処理）は残りのCPUへ寄せる必要があり、irqaffinity や RCU の rcu_nocbs を併用してハウスキーピングCPUへ追い出す設計が伴います。隔離は単一の設定ではなく、tick・割り込み・RCU・バランサを一貫して外すシステム全体の設計判断だと捉えるのが正確です。

まとめ

• Linuxは全CPUで1本のキューを共有せず、CPUごとのランキュー＋ロードバランシングで偏りを均す。判断の土台はCPUをSMT→LLC→NUMAの距離で捉えるスケジューラドメイン階層で、下位（安い）から順に均す。
• 均しには定期（tick起点でpull）・newidle（idle直前に近場から引く）・wakeup（起床タスクの配置先選択）の3系統があり、目的とコストが異なる。migration_cost や wake_affine がキャッシュ温度を守るガードとして働く。
• タスク移動コストの正体はキャッシュの作り直しとNUMAリモート参照。ピン留めはこれを抑える手段だが、公平性と引き換えになる。
• レイテンシ最優先ならisolcpus/nohz_fullでCPUをバランサ・tickごと隔離する。ただし隔離は割り込み・RCU・ハウスキーピングまで一貫して設計すべき上位判断で、「まず測り、最小限を外す」順序が安全。