【続】 Linux Kernel: cgroup 削除後も残り続ける slab キャッシュ についての調べ物 - upsteam は修正パッチが入って解決済み

以前に下記のエントリを書きました。勉強会に登壇するネタとして調べ直したところ 新しい Linux カーネルでは問題が解決されていました。

hiboma.hatenadiary.jp

hiboma.hatenadiary.jp

hiboma.hatenadiary.jp

hiboma.hatenadiary.jp

どんな問題ですか?

「cgroup を削除した後も sysfs の slab キャッシュ が残る」「slab キャッシュ が reclaim されるタイミングで必要のない uevent が送出される」 という二つの問題でした。

問題 と書いていますが、対象の slab キャッシュは inode っキャッシュや dentry キャッシュ であり、reclaimable な slab キャッシュです。 reclaimable な slab キャッシュは、カーネルにメモリプレッシャーがかかると自然に回収されため、大抵は問題として顕在化せずに気がつかないかと思います。送出される uevent も slab キャッシュの数が多くなければシステムへの負荷として観測されるほどにはなりません。

ところが、私が仕事で扱ってるサーバでは、以下のように問題を踏みました。

そもそも、このネタを調べていたのは「とある大量のコンテナを扱う production 環境」で、sysfs ファイル削除のタイミングで uevent が大量に送出され、それを処理するカーネルスレッドが競合を起こし TASK_UNINTERRUPTIBLE でブロックされ、ロードアベレージ上昇のアラートを招いていたのが発端でした。

Linux Kernel: cgroup, sysfs, kobject, uevent についての調べ物 - (3) slub_memcg_sysfs ブートパラメータについて - hibomaの日記

問題の回避・解決方法は?

1. slub_memcg_sysfs を指定する

ワークアラウンドとして、ブートオプションに slub_memcg_sysfs=0 を指定すると、cgroup によって sysfs のファイルが作成されなくなり slab っキャッシュも溜まらなくなり、「問題」を回避することができます。

2. 新しいカーネルにする

本エントリの本題になります。上記の新しいカーネルではパッチがあたり、問題が解決されています

パッチその1

cgroup 削除後も slab キャッシュが残ってしまうコードは下記で解決されたようです。5.9-rc1 で取り込まれているパッチです。

github.com

コミットログを見るに、memcg で使う kmem_cache を一つに統一する、という内容のようですがボリュームのでかいパッチで詳細まではちょっとわかりません

本エントリに関係するのは、diff で言うと下記のあたり。

@@ -5760,16 +5628,6 @@ static int sysfs_slab_add(struct kmem_cache *s)
    if (err)
        goto out_del_kobj;
 
-#ifdef CONFIG_MEMCG
-  if (is_root_cache(s) && memcg_sysfs_enabled) {
-      s->memcg_kset = kset_create_and_add("cgroup", NULL, &s->kobj);
-      if (!s->memcg_kset) {
-          err = -ENOMEM;
-          goto out_del_kobj;
-      }
-  }
-#endif
-
    if (!unmergeable) {
        /* Setup first alias */
        sysfs_slab_alias(s, s->name);

https://github.com/torvalds/linux/commit/10befea91b61c4e2c2d1df06a2e978d182fcf792#diff-4f86c03fe66c75bd50afc8e320349281L5763-L5772

パッチその2

cgroup が作る sysfs ファイルが udev イベントを飛ばしていたコードは下記のコミットで削除されました。5.8-rc1 で取り込まれています

github.com

「必要ないから消したよ」というコミットログですね。

I came across some unnecessary uevents once again which reminded me this. The patch seems to be lost in the leaves of the original discussion [1], so resending.


kmem_cache ( slub キャッシュ ) はカーネル内部の構造体なのに、ユーザ空間に通知を出すのは変だし、使ってるのみたことないというコメント

Kmem caches are internal kernel structures so it is strange that userspace notifiers would be needed. And I am not aware of any use of these notifiers.

https://lore.kernel.org/linux-mm/20200423115721.19821-1-mkoutny@suse.com/

先のエントリを書いた時に「 cgroup の sysfs が uevent を出して何に使うんだろう?」という疑問を抱いていたのですが、カーネルコミッタも同様に思っていたようですね。よかった 😀


These notifiers may just exist because in the initial slub release the sysfs code was copied from another subsystem.

さらに、「別のサブシステムからコピペして作った」という旨も書かれています ワハハ


イベントの宣伝

第12回 コンテナ技術の情報交換会@オンライン では、これらの話をまとめ直した内容を喋るつもりでいます

ct-study.connpass.com

TenForward id:defiant さん、こんな感じです!