TorvaldsがClaude CodeでLinuxのページキャッシュを改修

Linuxの生みの親であるLinus Torvaldsは、Anthropicが提供するAIコーディングアシスタントのClaude Codeで書いたと本人が述べるカーネルのパッチ群を公開しました。8本のパッチは、すでにメモリ上にあるファイルの小さな部分をLinuxがどう読み取るかを変えるものです。彼のノートPCでは、同じファイルを読む8スレッドの読み取りあたりのプロセッササイクルが約4分の1になりました。まだ何もマージされておらず、Torvaldsは未解決の問題を10件挙げています。

Torvaldsが公開したもの

パッチは、Torvalds自身のカーネルツリーにあるnoref-filemap-read-with-llmというブランチにあります。ブランチとは、メインのコードとは切り離して保たれた変更の流れのことです。8本のコードパッチの日付は2026年10月7日から10日で、テスト版のLinux 7.3-rc6を土台にしています。

シリーズの説明文は、AIの役割をはっきり述べています。

コード、テストプログラム、上のリストの裏付けとなったレビュー、そしてこの文章の最初の下書きは、私の指示のもとで、LLMコーディングアシスタント（Claude Code）を使って行いました。測定は私のマシンで実行しました。

各コードパッチには、彼自身の署名の横に「Assisted-by: LLM」の行が付いています。

ハードウェアニュースサイトのHardware Bustersは10月12日にこのブランチを報じ、測定は1台のノートPCだけで行われたと指摘しています。

先月、TorvaldsはLinux 7.3-rc4で修正されたバグをLLMが見つけたと評価しました。

パッチが解決する問題

Linuxは、最近使ったファイルのデータをページキャッシュと呼ばれるメモリ領域に置き、ディスクをもう一度読まずに済むようにしています。このキャッシュからの読み取りのたびに、メモリが一瞬「使用中」と印付けされ、その後で解除されます。この印は、ページと一緒に保存されたカウンターです。

多くのスレッドが同じ小さなファイルを同時に読むと、全員がその1つのカウンターを更新します。各プロセッサコアが順番に同じメモリを確保しなければならず、全員が遅くなります。Torvaldsの測定では、このコア間の通信の99.92%が、メモリ上の1本のラインに集中していました。

Hardware Bustersによると、この問題を最初に提起したのは2024年のMatthew Wilcoxです。Torvaldsによると、それ以前の対策は、データを一時バッファにコピーして後から確認するものでしたが、確認では捕まえられないまれなケースで行き詰まりました。

パッチの仕組み

ページがページキャッシュから外れるとき、Linuxはそのメモリをほかの誰かに渡す前に待つようになりました。待つのはRCUのグレースピリオドです。これは、それ以前に始まったすべての読み手が終了したとわかる短い時間の枠です。RCUはread-copy-updateの略で、読み手がロックなしで動けるようにするカーネルの手法です。

読み手がまだ見ている間はメモリを再利用できないため、読み取りにカウンターは不要になります。データはプログラムに直接コピーされます。以前の試みは、コピーの後でまれな危険なケースを捕まえようとしました。「解放を遅らせることで、これらのケースは検出するのではなく、なくなります」とTorvaldsは書いています。ページがない、ファイルの終わりに達したなど、普通でないことが起きた場合、コードは古い経路に戻ります。

数字

数値はすべて、4コア8スレッドのIntel Core i7-8565Uを積んだ1台のノートPCによるものです。各テストは、1ページのファイルから16バイトを読み取りました。Torvaldsは、ノートPCは熱くなると遅くなると注意しており、1秒あたりの読み取り回数よりも、読み取りあたりのサイクルのほうが公平に比較できるとしています。

テスト	変更前	変更後
1スレッド、読み取りあたりのカーネルサイクル	452-454	408-409
8スレッド、読み取りあたりのカーネルサイクル	2,937-2,975	725-726
8スレッド、1秒あたりの読み取り回数	990万-1,040万	3,000万-3,300万
8スレッド、コア間のメモリ競合（perf c2c）	30,538	101
1スレッド、まだメモリにないバッファへの読み取り、サイクル	4,117-4,188	6,543-6,593

最後の行がコストです。プログラムのバッファがまだメモリにない場合、新しい経路は一度失敗して元に戻ります。「CPUがもっと多いマシンや、ソケットが複数あるマシンでは、より大きな効果が見込めます。ただし、それより大きなマシンでは測定していません」とTorvaldsは書いています。

まだ解決していないこと

再利用を遅らせると、一部のメモリが遊びます。あるテストでは、4つのプロセスがメモリ上のファイルの一部を素早く解放しました。待機中のメモリの平均は、2本の追加パッチの後で565 MiBから15 MiBに減りました。これらのパッチは、1つのプロセッサで1,024ページを超えるページが待機すると、より速いグレースピリオドを強制します。「1024ページという上限は推測です」とTorvaldsは書いています。

彼が挙げる既知の問題には、次のものがあります。

• メモリアロケーターは待機中のページを認識できないため、数百MiBがまもなく空くというときに、OOMキラー（メモリ不足時のプロセス強制終了機構）が動く可能性があります。
• 大きな連続メモリブロックの要求が、「busy」エラーで失敗することがあります。
• xfstests、lockdep、KASANなどのテストスイートは実行されておらず、彼のノートPC以外のマシンでは試されていません。
• スケジューラーについては、「これが進むべき方向かどうか確信がありません」と書いています。

彼はメモリの問題を「このシリーズのなかで最も解決していない部分」と呼んでいます。

開発者にとっての意味

• 今のところ何も変わりません。 このブランチはマージされておらず、説明文には対象リリースも書かれていません。
• レビューに注目すること。 メモリ、RCU、スケジューラーのメンテナーからの返信が、取り込まれるか、変更されるか、却下されるかを決めます。
• 忙しい読み手ほど恩恵が大きいです。 測定されたのは、多くのスレッドが1つの小さなキャッシュ済みファイルを読むケースです。コア数の多いサーバーでそのワークロードを動かすチームは、試してみるべきです。
• AI支援パッチのひな型になります。 Torvaldsはツールの名前を明かし、すべてのパッチに自分で署名し、生の数値を公開し、テストしていないことを列挙しました。AIが書いたコードのルールを作るチームは、この形をまねできます。
• 監視ツールを確認すること。 高速経路の読み取りは、トレースポイントと通常の「アクセス済み」の印付けを飛ばすため、ページキャッシュのヒットを数えるツールでは件数が減って見えます。