#きょうのsystemd: ハイブリッドcgroupのセットアップは動くのか?
ちょっと前から気になっていたsystemd-develでのやり取りについて。
そもそも、「はいぶりっどこんとろーるぐーぷ?」なのだが、ちょっとまとめてみる。
ことの発端はUmut Tezduyar Lindskog*1の以下のメール。
[systemd-devel] How does hybrid cgroup setup work?
ハロー、
(訳注: cgroupの)CPUコントローラーをv1で、メモリコントローラーをunifiedにしようとしているんだけど、思ったとおり動かないんだ。 CONFIG_MEMCGを有効にすると、cgroupが/proc/cgroupsにポップアップしてきて、mount_cgroup_controllers()がかなり早くそれをマウントしている。 いったんこれがv1でマウントされると、v2では使えなくなってしまう。
ハイブリッドがどのように動くのか、自分が誤解しているんだろうか? Umut
v1だの、unifiedだの、v2だの、すでによくわからない。
ぐぐると、 id:defiant さんのブログがヒット記事が出た。systemdをやっている限りは足向けて眠れない気しかしない。
http://tenforward.hatenablog.com/entry/20160414/1460560309
http://gihyo.jp/admin/serial/01/linux_containers/0037 http://gihyo.jp/admin/serial/01/linux_containers/0038
v1 の問題点のひとつに、コントローラがばらばらに実装されているため、コントローラ間の連携ができないという問題がありました。
というわけで、「どうしてこうなった」という疑問は深堀しないことにして、これを解決するために、cgroupの構造を単一構成構造にしたのが、cgroup v2ととりあえず理解しておく。
なので、unifiedとv2は同じ、「ハイブリッド」はv1とv2のハイブリッドと理解してよさそうだ。そもそも、cgroup v1もろくに理解している気がしないのだが。
スレッドを読み進めよう。レナートのメール。
[systemd-devel] How does hybrid cgroup setup work?
ハイブリッドが意味するところは、v2がサービスのトラッキングにのみ使われているということ(これはいいことだ。なんせ、cgroupが存在するときに安全な通知をしてくれるからだ)で、どのコントローラーとしても使われていないということだ。 これは、ハイブリッドモードはほとんどピュアなv1と互換性があることを意味し、例外は、もう1つの階層構造(v2のそれだ)があって、systemdがそれをsystemdの目的のために使っているということだ。
レナート
端的に言うと、systemdはcgroup v2をフルには使っていません、というわけだ。
Umutが質問を続ける。
[systemd-devel] How does hybrid cgroup setup work?
v1からいくつかのコントローラーを、v2からいくつかのコントローラーを、みたいな幅広いハイブリッドにできない技術的な理由があるのか?
自分たちは、CPUに関してはv2が承認されるまではv1を使い続けて、一方で、メモリーに関してはv2のメリットを享受したいんだ。
UMUT
いいたいことはなんとなくわかる。
レナートの解説が入る。
[systemd-devel] How does hybrid cgroup setup work?
さて、現時点では、3つのタイプのセットアップがある。
1) レガシー
/sys/fs/cgroup/ → tmpfsインスタンス /sys/fs/cgroup/memory/ → メモリーコントローラーの階層構造 /sys/fs/cgroup/cpu/ → CPUコントローラーの階層構造 … /sys/fs/cgroup/systemd/ → namedの階層構造でsystemdがその管轄するものを管理する(そして、ほとんどsystemdの内部で利用される)もの
2) unified:
/sys/fs/cgroup/ → 単一階層構造(つまり、これは1つディレクトリを上がったところ、tmpfsのあったところだということに注意)
3) ハイブリッド:
/sys/fs/cgroup/ → tmpfs /sys/fs/cgroup/memory/ → メモリーコントローラーの階層構造 /sys/fs/cgroup/cpu/ → CPUコントローラーの階層構造 … /sys/fs/cgroup/systemd/ → namedの階層構造で互換性のため /sys/fs/cgroup/unified/ → 単一階層構造で、コントローラーはなく、systemdがその管轄するものを管理する(そして、ほとんどsystemdの内部で利用される)もの
さて、#1と#2をサポートするのは、なるほど納得である。1つは古いセットアップで、もう1つは将来のセットアップだ。 #3はたいていの方法で#1と互換性がある。唯一変わっていることは階層構造がもう1つ増えたということだけだ。 だが、古いコントローラーの階層構造は同じ場所に残っている。 別の言い方をすれば、systemdのプライベートな階層構造は変わっているが、その他の管轄するも*2のはまったく同じ場所に残っているということだ。
さて、君らが目指しているのは1と3とのどちらにも似ていない(3は単一階層構造からみて、動いてしまっているからだ)。 あるいは#2にも近くない(というのも、単一のディレクトリは/sys/fs/cgroupにはならない。なぜならレガシーなコントローラーをマウントさせる場所がないからだ)。
なので、君らの目指していることを加えようとすると、間に合わせにしかならないんだ。 つまり、加えたその瞬間に、すでに、終わりが見えている。 僕は、そんなに長くは生きないだろうとしているもののサポートを今から加えようとするのには消極的だな……。
そして、大きな問題がある。 cgroupのコードは難しすぎて、3つの異なるセットアップをサポートはできないんだ。 これにさらに付け加えるなんてことがないなら、本当にそれがいいと思う。 事実、僕は本当に、単一構造のcgroupを除いて、すべてのcgroupのサポートを、自分たちの(訳注: コード)ツリーからドロップできる日が待ち遠しいよ。 そのときには、めっちゃコードを消せるね! ハッカーがコードを書くよりも唯一好きなことは、コードを消すことさ…… ;-)
レナート
続くメールでUmutは「先生、先生の見込みではそれいつですか?」と聞いている。
[systemd-devel] How does hybrid cgroup setup work?
私も気になる。
レナート先生の回答*3
[systemd-devel] How does hybrid cgroup setup work?
自分がTejun*4の話を咀嚼すると、主要なコントローラーはすべて(訳注: v2に)動かすつもりなんだけど、いくつかは全体的にドロップするみたいだ。例えば、"devices"(というのも、これのやっていることは正確にはリソースの管理じゃなくて、アクセスの管理で、seccompと/devをどう一緒にするかを注意深く選び取れば、こいつはほとんど余分だからだ。)
メモリーコントローラーはもう完全に移っただろう。 systemdのMemoryMax=はすでに正しくことを運んでいる。
*1:ぐぐると名前がそこそこ出る人であった。経歴は彼のLinkedinページを参照。systemd.conf 2015でもどうやら喋っているようだ。発表のタイトルを見る限り、組み込み系の人だろうか。
*2:原語は'stuff'なのだが、訳語はいつもどうしたらいいのか悩む……。
*3:ちょっと誤字・脱字が多いみたいなので補正している
*4:cgroupsのメンテナーでsystemdのコミッター。Wikipedia - cgroups。Linkedin。
