前回の続きのエントリです
カーネルのバージョンを変えつつ ソースを読み込んでみたところ理解が進んだ点が２つあったのでまとめます
この二点についてまとめます
ファイルシステムを remount する際にカーネル内で reconfigure_super() (古いカーネルでは do_remount_sb() ) を呼び出すが、その中で shrink_dcache_sb() を呼び出して dcache を破棄する処理が入っているのを確認した
/** * reconfigure_super - asks filesystem to change superblock parameters * @fc: The superblock and configuration * * Alters the configuration parameters of a live superblock. */ int reconfigure_super(struct fs_context *fc) { struct super_block *sb = fc->root->d_sb; int retval; bool remount_ro = false; bool force = fc->sb_flags & SB_FORCE; ... shrink_dcache_sb(sb); 👈
shrink_dcache_sb() の定義は下記のような感じ
/** * shrink_dcache_sb - shrink dcache for a superblock * @sb: superblock * * Shrink the dcache for the specified super block. This is used to free * the dcache before unmounting a file system. */ void shrink_dcache_sb(struct super_block *sb) { do { LIST_HEAD(dispose); list_lru_walk(&sb->s_dentry_lru, dentry_lru_isolate_shrink, &dispose, 1024); shrink_dentry_list(&dispose); } while (list_lru_count(&sb->s_dentry_lru) > 0); } EXPORT_SYMBOL(shrink_dcache_sb);
「特定のファイルシステム/マウントポイントの dentry cache を飛ばしたい + mount ポイントが remount できる」 という特殊な条件が揃うようなケースがありえるのかどうか分からないが ... そういう時には使える。
あまり有用でない感じする. 無念
evict_inodes() という関数で、対象としているファイルシステムの superblock にぶら下がる inode キャッシュを全て破棄(?)できるぽい
/** * evict_inodes - evict all evictable inodes for a superblock * @sb: superblock to operate on * * Make sure that no inodes with zero refcount are retained. This is * called by superblock shutdown after having SB_ACTIVE flag removed, * so any inode reaching zero refcount during or after that call will * be immediately evicted. */ void evict_inodes(struct super_block *sb) { struct inode *inode, *next; LIST_HEAD(dispose); again: spin_lock(&sb->s_inode_list_lock); list_for_each_entry_safe(inode, next, &sb->s_inodes, i_sb_list) { if (atomic_read(&inode->i_count)) continue; spin_lock(&inode->i_lock); if (inode->i_state & (I_NEW | I_FREEING | I_WILL_FREE)) { spin_unlock(&inode->i_lock); continue; } inode->i_state |= I_FREEING; inode_lru_list_del(inode); spin_unlock(&inode->i_lock); list_add(&inode->i_lru, &dispose); /* * We can have a ton of inodes to evict at unmount time given * enough memory, check to see if we need to go to sleep for a * bit so we don't livelock. */ if (need_resched()) { spin_unlock(&sb->s_inode_list_lock); cond_resched(); dispose_list(&dispose); goto again; } } spin_unlock(&sb->s_inode_list_lock); dispose_list(&dispose); } EXPORT_SYMBOL_GPL(evict_inodes);
4.13.3 からは EXPORT_SYMBOL_GPL が付いているので他のカーネルモジュールからも呼び出し可能な API として再定義されている.
コメントに注意書きが記してある
* Make sure that no inodes with zero refcount are retained. This is * called by superblock shutdown after having SB_ACTIVE flag removed, * so any inode reaching zero refcount during or after that call will * be immediately evicted. */
呼び出し側が上記の条件を保証する必要があるらしくて、ここの条件の成立のさせ方が正しいのかを確かめるすべがわからない.
evict_inodes() を呼び出すコードに generic_shutdown_super() があるが dirty な inode の処理などは呼び出す側の責務っぽい。書き込みが発生している場合には慎重に扱わないとファイルシステムの不整合を招く感じする
/** * generic_shutdown_super - common helper for ->kill_sb() * @sb: superblock to kill * * generic_shutdown_super() does all fs-independent work on superblock * shutdown. Typical ->kill_sb() should pick all fs-specific objects * that need destruction out of superblock, call generic_shutdown_super() * and release aforementioned objects. Note: dentries and inodes _are_ * taken care of and do not need specific handling. * * Upon calling this function, the filesystem may no longer alter or * rearrange the set of dentries belonging to this super_block, nor may it * change the attachments of dentries to inodes. */ void generic_shutdown_super(struct super_block *sb) { const struct super_operations *sop = sb->s_op; if (sb->s_root) { shrink_dcache_for_umount(sb); sync_filesystem(sb); sb->s_flags &= ~SB_ACTIVE; fsnotify_sb_delete(sb); cgroup_writeback_umount(); evict_inodes(sb); 👈 ...
今回調べているユースケースで、実は 対象のファイルシステムが実は「readonly でマウントしている」という隠れ条件 があったのでした (後出しジャンケンですいません)
おそらく、ファイルシステムが readonly でマウントされていたら dirty な inode は存在しえないだろうし、 slab キャッシュをばーんと消しても安全に扱えそうなきがする
... ということで readonly なファイルシステムを対象に evict_inodes() をカーネルモジュールから呼び出す Proofe of Conept を書いてみた
XFS で looopback のファイルシステムを作成して、ディレクトリとファイルを作成しまくる
dd if=/dev/zero of=/tmp/disk bs=1M count=1000 mkfs.ext4 /tmp/disk sudo mount -t xfs /tmp/disk /mnt for i in $(seq 1 1000); do sudo mkdir -pv /mnt/$i/{1..100}; done for i in $(seq 1 1000); do sudo touch /mnt/$i/{1..100}/test.txt; done
readonly で remount しなおす
sudo mount -o remount -r -t xfs /mnt
dentry と xfs_inode を貯めるべく find する
sudo find /mnt >/dev/null
この時点で slabtop すると、以下の slab が溜まっている
OBJS ACTIVE USE OBJ SIZE SLABS OBJ/SLAB CACHE SIZE NAME 201042 201042 100% 0.94K 11826 17 189216K xfs_inode 104192 101602 97% 0.50K 6512 16 52096K kmalloc-512 229383 224847 98% 0.19K 10923 21 43692K dentry ...
拙作のカーネルモジュールで dentry と inode (xfs_inode) を破棄する
# /mnt の superblock を対象にして dentry と xfs_inode を破棄する (はず echo /mnt | sudo tee /sys/kernel/debug/shrink_super_block_cache
slabtop しなおすと dentry と xfs_inode が消えた ( kmalloc-512 もなくなったな??? )
OBJS ACTIVE USE OBJ SIZE SLABS OBJ/SLAB CACHE SIZE NAME 16107 15673 97% 0.59K 1239 13 9912K inode_cache 8325 7409 88% 1.06K 555 15 8880K ext4_inode_cache 50430 50127 99% 0.13K 1681 30 6724K kernfs_node_cache 29883 24224 81% 0.19K 1423 21 5692K dentry ...
dentry cache と inode ( xfs_inode ) を破棄することに成功したぽい.
ext4 でも同様の結果を得ている. slab キャッシュの生成とキャッシュの破棄とを並列にするなどして kernel panic 等を起こさないかも試し中
社内の同僚がカーネル周りの問題を調べていて slab キャッシュ ( = dentry, inode ) に関する内容を追っていた。 その問題自体の内容は、アレがコレで、伏せておく。
その問題をみているうちに 「特定のディレクトリ以下の slab キャッシュ = dentry / inode キャッシュ を選択的に破棄することはできないのかな？」 という関心がわきいろいろ調べていた。
ビジネスロジックを担当するアプリケーションの実行とは関係ない箇所で大量に slab キャッシュ (dentry, inode) を蓄えてしまうプロセスがいて、そいつらが作ったキャッシュを意図して破棄したいようなユースケースを考えている (例: バックアップやウィルススキャン)
(注意: メモリプレッシャーがかかるとカーネルがよしなに扱ってくれるはずで、「通常」のサーバ用途では slab キャッシュをあれこれ触る必要は無いと思う )
slab キャッシュを破棄するには
echo {1,2,3} > /proc/sys/vm/drop_caches ( 1, 2, 3 のどれか )あるいは
sysctl -w vm.drop_caches={1,2,3} を実行すればよい。ただし、このインタフェースでは特定のキャッシュを選択的に破棄することはできず 全ての SReclaimable な slab キャッシュを破棄する
/proc/sys/vm/drop_caches 内部では shrink_slab() を読んでおり、 struct shrinker *shrinker という slab キャッシュを破棄するために登録されたコールバック関数をイテレートして slab を破棄している
(ところで、この内容も Qiita で詳しくまとめてる人がいるのでググるとよいですぞ )
static unsigned long shrink_slab(gfp_t gfp_mask, int nid, struct mem_cgroup *memcg, unsigned long nr_scanned, unsigned long nr_eligible) { struct shrinker *shrinker; unsigned long freed = 0; .... list_for_each_entry(shrinker, &shrinker_list, list) { struct shrink_control sc = { .gfp_mask = gfp_mask, .nid = nid, .memcg = memcg, }; ... freed += do_shrink_slab(&sc, shrinker, nr_scanned, nr_eligible); } ...
struct shrinker *shrinker を直接触るのはどうやら無理なようなので、別の方策を探っていた。
ソースを追っていたら shrink_dcache_parent(), dentry_unhash() という関数がそれっぽい用途に使えそうだった
/** * shrink_dcache_parent - prune dcache * @parent: parent of entries to prune * * Prune the dcache to remove unused children of the parent dentry. */ void shrink_dcache_parent(struct dentry *parent) { for (;;) { struct select_data data; INIT_LIST_HEAD(&data.dispose); data.start = parent; data.found = 0; d_walk(parent, &data, select_collect, NULL); if (!data.found) break; shrink_dentry_list(&data.dispose); cond_resched(); } } EXPORT_SYMBOL(shrink_dcache_parent);
再帰的に dentry のツリーを辿って dentry を破棄するぽい
dentry_unhash() は shrink_dcache_parent() のラッパー
/* * The dentry_unhash() helper will try to drop the dentry early: we * should have a usage count of 1 if we're the only user of this * dentry, and if that is true (possibly after pruning the dcache), * then we drop the dentry now. * * A low-level filesystem can, if it choses, legally * do a * * if (!d_unhashed(dentry)) * return -EBUSY; * * if it cannot handle the case of removing a directory * that is still in use by something else.. */ void dentry_unhash(struct dentry *dentry) { shrink_dcache_parent(dentry); spin_lock(&dentry->d_lock); if (dentry->d_lockref.count == 1) __d_drop(dentry); spin_unlock(&dentry->d_lock); } EXPORT_SYMBOL(dentry_unhash);
見た所 dentry キャッシュだけを破棄するようで inode キャッシュは扱えないが、まぁ 試してみるだけ試してみよう
で、dentry_unhash() を使って、 Proof of Concept として作ったカーネルモジュールがこれ
肝となるコードは下記の部分だけ
err = kern_path(buffer, 0, &path); if (err) return err; dentry_unhash(path.dentry); path_put(path);
モジュールをビルドしてinsmod して、下記のような debugfs のファイルにパスを write(2) すると、指定したパス = ディレクトリ以下の dentry を破棄する
echo /var/lib > /sys/kernel/debug/shrink_dcache
dentry_unhash() 自体の使い方が間違っている可能性もあるし、実用に耐えうるようなクオリィテではないので勘弁を
まずは slabtop コマンドで現在の dentry のサイズを調べます
vagrant@second:~/shrink_dcache$ sudo slabtop -o | grep dentry 17619 10532 59% 0.19K 839 21 3356K dentry
3356K ありますね
次にサブディレクトリの negative dentry を生成します ( negative dentry については過去の私の書いたブログがあるので参考にしてください。最近だと、 Qiita などにも詳しい解説がたくさんあります )
vagrant@second:~/shrink_dcache$ mkdir -p /tmp/1/2/3 vagrant@second:~/shrink_dcache$ perl -e 'stat "/tmp/1/2/3/$_" for 1..1000000'
dentry のサイズを調べ直します
vagrant@second:~/shrink_dcache$ sudo slabtop -o | grep dentry 1045380 1045380 100% 0.19K 49780 21 199120K dentry
199120K に増えましたね
ここで先ほどのカーネルモジュールを使って dentry を破棄します
# 再帰的に dentry を辿るはずなので上位のディレクトリを起点にして破棄する vagrant@second:~/shrink_dcache$ echo /tmp/1 | sudo time tee /sys/kernel/debug/shrink_dcache /tmp/1
もう一度 dentry のサイズを調べ直します
vagrant@second:~/shrink_dcache$ sudo slabtop -o | grep dentry 50358 42113 83% 0.19K 2398 21 9592K dentry
おお、9592K に減っていますね.
