Torvaldsのページキャッシュパッチに改良版：ext4で4.5倍高速に

Metaのエンジニア、Kiryl Shutsemauは2026年10月19日、Linus TorvaldsによるLinuxのページキャッシュのパッチを改良した版を公開しました。新しいシリーズは18本のパッチからなります。ext4ファイルシステムでの64スレッドのテストでは、1つのファイルの小さな読み取りが、毎秒約1,500万回から約7,000万回に増えました。Torvaldsが未解決のまま残したメモリの問題への修正も加わりましたが、コードはまだレビュー用の草案です。

Torvaldsの版から変わったこと

1週間前、TorvaldsはClaude Codeで書いたページキャッシュのパッチ群を公開しました。Claude Codeは、AnthropicのAIコーディングアシスタントです。Shutsemauは今回、その作業をさらに進めました。彼のシリーズの題名は「mm: read the page cache without folio references」です。

Patchewに保存されたカバーレターは、Torvaldsの以前の草案の功績を認めています。18本のパッチのうち、Shutsemauが11本、Torvaldsが7本を書きました。全体で20個のファイルに手を入れ、770行を追加し、92行を削除しています。シリーズは、テスト版のLinux 7.3-rc7を土台にしています。

このシリーズにはRFCの印が付いています。RFCは「request for comments（意見募集）」の略です。この印は、誰かがマージする前に、作者が意見を求めていることを意味します。Linuxの性能を報じるPhoronixは、この結果を「素晴らしい改善」と呼びました。

問題：1つのカウンター、多数のプロセッサ

Linuxは、最近使ったファイルのデータを、ページキャッシュと呼ばれるメモリ領域に置いています。カーネルは、このメモリをフォリオ（folio）という単位で管理します。各フォリオには参照カウントがあります。これは、何人の読み手がそのフォリオを使っているかを示すカウンターです。

読み取りのたびに、このカウンターが一瞬上がり、その後で下がります。多くのプロセッサコアが同じ小さなファイルを読むと、全員が1つのカウンターを奪い合います。「多数のCPUからの1つのファイルの小さな読み取りは、すべて同じフォリオへの参照を取得しては解放します」とShutsemauは書いています。

シリーズによる解決方法

このシリーズでは、通常のファイル読み取りが、カウンターに触れずにデータをコピーできるようになります。対象はfilemap_read()で、これは通常のファイル読み取りを担うカーネル関数です。shmemも対象です。shmemはtmpfsを支えるコードで、tmpfsは完全にメモリ上にあるファイルシステムです。

これを安全にするため、こうした読み手がコピー元にする可能性のあるフォリオは、RCUのグレースピリオドの後でのみ解放されます。RCUは、読み手がロックなしで動けるようにするカーネルの手法です。グレースピリオドとは短い待ち時間のことで、その後には、それ以前のすべての読み手が終了したとわかります。

この扱いを受けるのは、使用頻度の高いフォリオだけです。それらにはPG_rcu_freeという新しいフラグが付きます。このフラグは64ビットシステムでのみ機能します。

4本のパッチは、この遅延の間に待機するメモリを扱います。そのためのカウンターを追加し、メモリが少なくなるとグレースピリオドを速めます。さらに、OOMキラー（メモリ不足時のプロセス強制終了機構）、大きな連続メモリの割り当て、メモリの取り外しが諦める前に、待機中のページが解放されます。Torvaldsは、このうち最初の2つを未解決の問題として挙げていました。最後のパッチは、新しい高速経路を無効にするスイッチを追加します。

数字

Shutsemauは、AMD Threadripper 7975WX上で動く、64個の仮想CPUと2 GBのメモリを持つ仮想マシンでテストしました。各スレッドは、1つのファイルの先頭から16バイトを読み取りました。結果の単位は、1秒あたり100万回の読み取りです。

テスト	変更前	変更後
ext4、64スレッド	15.0-15.7	68.9-70.1
tmpfs、64スレッド	1.6-1.7	71-72
XFS、64スレッド	11.3-11.4	20.4-20.5
生のブロックデバイス、64スレッド	14.7	28.8-28.9
上記のいずれか、1スレッド	1.6-1.9	1.7-2.0

これらの実行では、CPUのセキュリティ緩和策（mitigations）が標準設定のまま使われました。これは、プロセッサ自体の欠陥から守るための対策です。Shutsemauによると、緩和策は、読み取りがカーネルに入るたびに約400ナノ秒を加えます。緩和策をオフにすると、ext4での向上は4.5倍から13倍に広がり、毎秒2億1,700万-2億2,000万回の読み取りに達します。これらの数値は、同じ小さな読み取りの経路を持つ以前の版によるものです。

コストもあります。カーネルがすでに捨てたページを何度も読み直すワークロードでは、4%から6%の損失が出ます。

まだ未解決のこと

カバーレターは、いくつかの未解決の問題を挙げています。

• あるパッチは、どのファイルもそのinodeを開いたままにしていないというチェックに依存しています。inodeは、カーネルがファイルについて持つ記録です。f2fsファイルシステムはアトミック書き込みでこのルールを破っており、修正が予定されています。
• あるパッチは、tmpfsの読み取りからロックを1つ外します。Shutsemauは安全だと考えていますが、別の開発者のHughに再確認を頼んでいます。
• グレースピリオドの間、待機中のフォリオはどのcgroupにも計上されません。cgroupは、コンテナごとにメモリを制限するLinuxの機能です。
• メモリコンパクション（空きメモリを大きなブロックにまとめる処理）への影響は、測定されていません。
• 一部のアーキテクチャでは、書き込み用にマップされたファイルは、今も遅い経路を通ります。

開発者にとっての意味

• まだ何も出荷されていません。 これはRFCで、対象リリースは示されていません。その形を決めるのは、メモリ管理のレビュアーです。
• 共有される忙しい読み取りほど恩恵が大きいです。 大きな効果が出るのは、多くのスレッドが同じ小さなキャッシュ済みファイルを読むときです。1スレッドの読み取りはほとんど変わりません。
• tmpfsの利用者は注視すべきです。 64スレッドで、毎秒約160万回から7,100万回の読み取りに増えました。表のなかで最大の伸びです。
• 実際のセキュリティ設定でベンチマークすること。 今回、緩和策は読み取りごとに約400ナノ秒かかりました。緩和策をオフにした結果は、強化された本番サーバーとは一致しません。
• AI支援の草案も、やはりレビューを通ります。 TorvaldsのClaude Codeによる草案は、1週間のうちに別のエンジニアによる改良版シリーズになりました。残りは、通常のカーネルのレビューの流れが担いました。