Linux 7.4のパッチ、テストでファイルオープンが39%高速に

Linuxカーネルのバージョン7.4に向けて用意された小さなパッチが、作者のベンチマークでファイルオープンのスループットを39%引き上げた。Mateusz Guzik氏は2026年8月3日、2年以上にわたる改訂を経て、この変更をlinux-fsdevelメーリングリストに投稿した。ファイルを開く処理は忙しいサーバーが最も多く行う作業の1つであり、この高速化には引き換えの代償がない。そこに意味がある。

パッチの題名は「fs: avoid spurious dentry ref/unref cycle on open」だ。対象は仮想ファイルシステム、つまり個々のファイルシステムの上に位置し、openやreadといった要求を処理するカーネルの層である。

パッチが変えるもの

dentryとは、カーネルがキャッシュしているディレクトリエントリの記録だ。パス中の名前と、その名前が指すファイルとを結び付けている。カーネルは各dentryを自身のどれだけの部分が使っているかを数えており、その記録をいつ解放できるかを判断する。この数え上げが参照カウントである。

Guzik氏のコミットメッセージは、無駄をはっきり説明している。ファイルを開くと、まず__legitimize_path()で最終的なdentryの参照を取得する。次にdo_dentry_open()で2つ目の参照を取得する。そして最後にterminate_walk()で最初の参照を手放す。

この3つの操作のうち2つは何も達成していない。パッチはdo_dentry_open()に、新しい参照を取得して古いものを解放する代わりに、カーネルがすでに保持している参照をそのまま引き継がせる。

変更は小さい。バージョン5の差分は3つのファイル、fs/internal.h、fs/namei.c、fs/open.cにまたがって43行を追加し、4行を削除する。Guzik氏はこれを、このコードの長年のメンテナーであるAl Viro氏によるより大掛かりなパッチセットに対する、より単純な代案だと説明している。

参照カウントは単体で見れば安価に思える。しかし多数のCPUコアが同じカウンターに同時に触れるとき、それは安価ではない。更新のたびに他のすべてのコアから見える状態にする必要があり、コアは互いの後ろで順番待ちになる。

39%の根拠となったベンチマーク

この数値はwill-it-scaleによるものだ。これはカーネルの操作がコア数の増加にどれだけ耐えるかを測るテスト群である。Guzik氏は、同じファイルを読み取り専用で開いては閉じるループを回すopenro3.cのケースを使った。

20コアの仮想マシンでの結果は次のとおりである。

測定	1秒あたりの操作数
パッチ適用前	4,043,375
パッチ適用後	5,629,378

これが39%という数字だ。2026年9月19日にこのパッチを報じたPhoronixは、変更がVFSのgitツリーのvfs-7.4.lookupブランチに入り、Linux 7.4のマージウィンドウを目指していると伝えている。

開発者にとっての意味

このベンチマークは、そのまま受け取ってはいけない。openro3のケースは、すべてのコアが共有された1つのファイルを読み取り専用で、密なループで開き続ける。これはこのパッチが触らなくなったまさにそのカウンターへの競合を最大化する。だから伸びがこれほど大きい。これは上限であって、あなたのワークロードに対する予測ではない。

実際の伸びは、処理時間のうちどれだけをファイルオープンに使っているか、そして同時に何コアがそれを行っているかで決まる。ベンチマークに近いワークロードは3つある。ビルドシステムは何千ものヘッダーをstatし、openする。ウェブサーバーはリクエストごとに同じ静的ファイルを開く。コンテナイメージやパッケージのツールは大きなディレクトリツリーを歩く。ノートPC上のシングルスレッドのスクリプトは、ほとんど何も得られないだろう。

カーネルの到着を待たずに、自分の影響度は測れる。代表的な実行についてstrace -cかperfのプロファイルでopenとopenatのシステムコールを数え、全体の実行時間と比べればよい。プロファイル上でオープンが誤差の範囲なら、見出しが何と言おうと、このパッチはあなたのボトルネックではない。

時期を当てにした計画はまだ立てないこと。パッチはサブシステムのブランチに入った状態であり、そのメンテナーには受理されたが、メインラインのカーネルにはまだ統合されていない。Phoronixは2026年内に安定版カーネルへ届くことが期待されていると伝えている。マージウィンドウでその順序は変わりうるし、そのあとコードはディストリビューションのカーネルを経てあなたに届くため、通常はさらに数か月かかる。

より広い教訓のほうが役に立つ。これは数十年にわたり1日に何十億回も通ってきた経路への43行の変更であり、そこにはまだ冗長なアトミック操作が2つ残っていた。成熟したコードのホットパスは読み直す価値がある。カーネル自身の漸進的な改善の歴史も続いている。同じ7.4のサイクルでkbuildのパッチがカーネルのビルド時間を短縮した。