cgroup v2の階層モデルとコントローラ

なぜ複数階層をやめたのか

cgroup v1 の最大の特徴は、コントローラごとに独立した階層を組めたことでした。CPU 用のツリー、メモリ用のツリー、blkio 用のツリーを別々にマウントし、それぞれで好きな粒度のグループ分けができます。柔軟に見えますが、これは深刻な構造問題を抱えていました。

問題は、あるプロセスがコントローラごとに別のグループへ所属できてしまう点です。プロセス P が CPU 階層では groupA、メモリ階層では groupX に属していると、「P が属するグループ」という概念そのものが一意に定まりません。すると、メモリ逼迫でページキャッシュをライトバックする際に「この I/O はどの CPU 配分・どの I/O 帯域に従うべきか」をカーネルが決められません。メモリ回収が生む I/O を正しい blkio グループへ紐付けられず、コントローラ間で協調が必要な制御が成立しないのです。

cgroup v2 はこの根を断つため、**単一階層（unified hierarchy）**へ移行しました。ツリーは1本だけで、すべてのコントローラがそれを共有します。プロセスの所属は常に1つのノードに定まり、「このプロセスの CPU・メモリ・I/O はすべてこのノードの制約に従う」と一意に言えます。柔軟性を一段手放す代わりに、コントローラ横断の整合性という上位の利得を取った設計判断です。

サブツリー制御の委譲

単一階層では、すべての資源を root 直下で握ると硬直します。そこで v2 は**コントローラの委譲（delegation）**を中心に据えます。鍵となるのが2つのファイルです。あるノードの cgroup.controllers は「ここで利用可能なコントローラ」を示し、cgroup.subtree_control は「子に渡すコントローラ」を示します。

重要なのは、コントローラはトップダウンに親が許した分しか有効化できない点です。親が subtree_control に +memory を書いて初めて、子の cgroup.controllers に memory が現れ、子はさらにその孫へ渡せます。逆に親が渡さなければ、子は配下でメモリ制御を一切有効化できません。この一方向の伝播が、誰がどの資源を再分配できるかを階層に沿って厳密に決めます。

root
  cgroup.subtree_control = "cpu memory"     ← 子に cpu と memory を委譲
  └── workload.slice
        cgroup.controllers     = "cpu memory"   ← 親から渡された
        cgroup.subtree_control = "cpu"           ← 孫には cpu だけ渡す
        ├── app-A   (cpu は制御可、memory はこのノードで制御)
        └── app-B

所有権の観点では、サブツリーの root ディレクトリと cgroup.procs・cgroup.threads・cgroup.subtree_control の所有者を委譲先ユーザーに移せば、非特権ユーザーへサブツリーを委譲できます。委譲先は内側を自由に切り分けられますが、有効化できるコントローラは親が許した範囲に閉じ込められます。systemd の slice/scope や、rootless コンテナがユーザー権限で資源制御を組めるのは、この委譲モデルが土台です。コンテナ基盤としての位置づけは名前空間と cgroupsで扱った隔離と制限の「制限」側の中核にあたります。

コントローラはどう協調するか

単一階層の真価は、コントローラ同士が同じノードを参照して協調できる点に現れます。代表的な4つを押さえます。

協調が効く典型がメモリ回収と I/O の連動です。あるノードで memory.high を超えると、そのノード配下でターゲットなメモリ回収が走り、ダーティページは書き戻しを伴います。v2 ではこの writeback が生む I/O が、同じノードの io コントローラの帯域に課金されます。v1 では所属が分裂して不可能だった「メモリ逼迫が生む I/O を、その原因グループの I/O 予算で律する」が成立するわけです。

cpu コントローラは2系統で効きます。cpu.weight は比例配分——競合時に重みの比でCPU時間を割り振る軟性の制御で、競合が無ければ上限なく使えます。cpu.max は QUOTA PERIOD 形式のハードクォータで、競合の有無に関わらず周期あたりの実行時間を絶対的に頭打ちします。weight は実体的な配分をCFS の vruntime 管理へ写像し、重みの大きいノードほど vruntime がゆっくり進んで長くCPUを得ます。pids は最も単純で、fork 爆弾のような暴走をプロセス数という直交した軸で止める安全装置です。

no internal process 制約

v2 を運用すると必ず突き当たるのが no internal process 制約です。あるノードで subtree_control を通じてコントローラを有効化している間は、そのノードに直接プロセスを置けない（cgroup.procs が空でなければならない）というルールです。プロセスを持てるのは、子へコントローラを配っていない葉ノードだけになります。例外は root だけです。

なぜこの制約が要るのか。理由は資源の競合相手を揃えるためです。もし内部ノード N が直接プロセス P を抱えつつ、子ノード C へもコントローラを配っていたら、N の資源を「P という個別プロセス」と「C というサブツリー」が奪い合うことになります。プロセスとサブツリーは粒度が違い、cpu.weight のような比例配分の比較対象として等価に扱えません。「P の重み10」と「サブツリー C の重みは内部でどう積み上がるのか」を整合的に比べる定義が存在しないのです。

この制約により、各ノードでの競合は**常に同種の単位どうし（子ノードの集合）**に限られ、weight による比例配分や max による上限が曖昧さなく定義できます。柔軟性を削ってでも制御モデルを単純に保つという、v2 全体を貫く設計思想がここに凝縮されています。

まとめ

• v1 の複数階層はプロセスの所属をコントローラごとに分裂させ、メモリ回収 I/O の紐付けなどコントローラ横断の制御を不能にしていた。v2 は単一階層で所属を一意化し、この問題を根絶した。
• 委譲は subtree_control によるトップダウンの伝播で決まり、子は親が許したコントローラしか有効化できない。所有権の移譲で非特権ユーザーへサブツリーを安全に委ねられる。
• cpu（weight/max）・io・memory・pids は単一ノードを共有して協調する。メモリの high 超過が生む writeback I/O を同ノードの io 予算へ課金できるのが象徴的な利得。
• no internal process 制約は、内部ノードでプロセスとサブツリーが資源を奪い合う曖昧さを排し、競合を同種の単位に揃える設計判断。プロセスは葉に置く。