10月24日、pbxscience.comが「Torvalds' AI-Assisted Page Cache Patches Show a 23x Gain in a Synthetic Test, but Review Found a Race Condition」と題した記事を公開した。Linus TorvaldsがAIコーディングツールの支援を受けて開発したLinuxページキャッシュ改善パッチが、合成テストで23倍のスループット向上を示した一方、レビューでレースコンディションが発見された経緯を詳報している。
AIがカーネル開発の現場に入り込んだことも話題だが、それ以上に興味深いのは「なぜ64スレッドが8スレッドより遅くなるのか」という逆転現象の原因と解決策だ。ボトルネックはファイルデータそのものではなく、管理メタデータにあった。
背景：TorvaldsとClaude Code
2026年10月13日、TorvaldsはLinuxカーネルのパッチシリーズ「Improve page refcount scalability」（ブランチ名: rcu-free-v3）を公開した。開発にはAnthropicのAIコーディングツール「Claude Code」を活用している。Torvaldsはこの問題に約18ヶ月間取り組んでいたとされ、他の開発者のアプローチも壁にぶつかっていた経緯がある。そうした難問の探索フェーズにAIを活用したことが、今回の話題の発端だ。対象はread()およびpread()システムコールのページキャッシュからの読み出しパスである。
「1つのカウンタ」が64スレッドを詰まらせる
Linuxのページキャッシュは、ディスクから読んだデータをメモリに保持し、次回の読み出しをストレージアクセスなしで返す仕組みだ。問題は参照カウントにある。ページキャッシュ上の各ページには「今何スレッドが使っているか」を追跡するカウンタが存在し、読み出しのたびにインクリメント、終了時にデクリメントする。この操作はアトミック命令（他のスレッドと競合しないよう排他的に実行される命令）で行われる。
多数のコアが同じページを読み出す場合、全スレッドが同じカウンタ（同一キャッシュライン）に書き込むことになる。キャッシュコヒーレンシの仕組み上、キャッシュラインを書き換えるにはそのコアが排他的に所有権を持つ必要があるため、キャッシュラインが各コア間を絶え間なく行き来する「キャッシュラインバウンシング」が発生する。結果として、旧実装では32〜64スレッド時のスループットが8スレッド時より低くなる逆転現象が生じていた。
RCUで参照カウントを回避する
パッチシリーズの核心は**RCU（Read-Copy-Update）**の活用だ。RCUはLinuxカーネルが広く採用している同期メカニズムで、「頻繁に読まれ、めったに変更されないデータ」に適する。読み取り側はロックなしで保護領域にアクセスでき、解放処理は既存の読み取りが完了するまで安全に遅延される。
具体的には、頻繁にアクセスされるキャッシュページを「ホット」としてマークし、少なくとも1回のRCUグレースピリオド（すべてのCPUがRCU保護外のコードを一度は実行したことが保証される猶予期間）が経過するまでページアロケータへの返却を遅らせる。これにより、読み出し処理はRCU保護下でページデータをコピーでき、毎回の参照カウント操作が不要になる。ただしこのファストパスが適用されるのは、ユーザー空間へのコピーがページフォルトなしで完了した場合に限られる。
ベンチマーク結果
テスト環境は32コア・64スレッドのAMD Ryzen Threadripper 3970X。64スレッドそれぞれが独自のファイルディスクリプタを使い、同一の1ページファイルの先頭16バイトをpread()で繰り返し読み出す、競合を最大化した合成テストだ。
| 指標（64スレッド） | パッチ適用前 | パッチ適用後 |
|---|---|---|
| 1秒あたりの読み出し数 | 1,330万回 | 3億400万回 |
| 読み出し1回あたりのカーネルCPUサイクル数 | 約19,900 | 約735 |
| スループット変化 | — | 約22.9倍 |
Torvalds自身のラップトップ（4コア・8スレッド）での8スレッドテストでは、カーネルサイクル数が約2,950から約725に減少し、スループットは約3倍になった。ラップトップは熱によるスロットリングが発生するため、「1読み出しあたりのコスト」の方が信頼性の高い指標だとTorvalds自身が述べている。
23倍という数字は競合を極限まで高めた合成テストによるものであり、Torvalds自身も実際のワークロードでの改善幅はずっと小さいと明言している。それでも、全コアが触れる小さなカウンタという共有メタデータがボトルネックになっている場合、単一のアトミック操作を排除するだけで劇的な改善が得られることを示す好例だ。
AIを活用しても、並行処理の難しさは変わらない
Claude Codeの支援を受けた開発であっても、並行処理の複雑さは健在だった。パッチ公開後のレビューでレースコンディションが発見された。RCU保護とページのライフタイム管理、そしてトランケーション（ファイル切り詰め）・書き込み・キャッシュ追い出しといった並行変更操作の間には厳密な順序付けが必要であり、こうした不具合は通常の機能テストでは再現しないことが多い。
パッチは現時点でまだメインラインへのマージに至っておらず、修正とさらなるレビューが必要な状態だ。AIツールが有望な最適化アプローチの探索を加速できることは示された。しかし、カーネルが正しく動作するかどうかの検証は依然として人間のレビュアーに委ねられている——この点は今回の件が改めて示した事実だ。
詳細はTorvalds' AI-Assisted Page Cache Patches Show a 23x Gain in a Synthetic Test, but Review Found a Race Conditionを参照していただきたい。
