リーナス・トーバルズ氏が、Claude Codeを使って、Linuxカーネルの実験的な最適化を開発しました。並行読み取りを遅くするページキャッシュのボトルネックに対処するものです。
noref-filemap-read-with-llmブランチの10月10日付コミットに記録されたこの8本のパッチシリーズは、ノートPCでのベンチマークの一つでスループットをほぼ3倍に引き上げました。
トーバルズ氏は、実装、テストプログラム、レビュー用資料、初期ドキュメントの作成をアシスタントが担ったと説明しています。いずれも同氏の指示の下で行われたものです。
今回の取り組みが扱うのは、複数のスレッドが同じキャッシュ済みファイルの小さな領域を読み取る際に生じる競合です。従来の読み取りでは、そのたびにfolioの参照を取得して解放するため、共有の参照カウントメタデータが2回書き換えられます。
folioとは、まとめて管理される1つ以上のメモリページのことです。トーバルズ氏のノートPCでは、この競合がロードHITMの99.92%を占めていました。これはコア間のキャッシュコヒーレンシ通信が原因です。
提案された読み取りパスは、参照を取得する代わりにRCU（read-copy-update）を利用し、メモリの早すぎる再利用を防ぎます。
ページキャッシュから取り除かれたfolioは、RCUのグレースピリオドを経た後にはじめてアロケータへ戻ります。これにより、保護された読み取り側はキャッシュ上のデータをユーザー空間へ直接コピーできます。
実装ではPG_rcu_freeを導入し、キャッシュからの除去ではなく最終的な解放を遅延させます。RCUの読み取りセクション中は、ページフォルトが無効化されます。ページの欠落、データの不完全、ユーザーバッファでのフォルト、その他の条件に該当すると、既存の読み取りパスへフォールバックします。
この方式は、従来の参照不要な設計が抱えていた競合状態を排除することを狙っています。従来の設計はコピー後に競合を検出しようとしましたが、メモリが解放され、再利用され、同じキャッシュインデックスに再挿入されるケースを見逃す可能性がありました。再利用を遅延させれば、このライフタイムの問題に直接対処できます。
テストにはIntel Core i7-8565Uを搭載したノートPC（4コア8スレッド、ext4）を使用しました。8スレッドが1つのキャッシュ済みページに対して16バイトのpread()を繰り返し発行したところ、毎秒約990万〜1,040万回だった読み取り回数が、3,000万〜3,300万回に向上しました。
カーネルのコミットによると、1回の読み取りあたりのサイクル数は2,937〜2,975から725〜726に減少しました。ただし、これらは特定のワークロードでの結果であり、Linux上のあらゆるアプリケーションで同等の改善が得られることを示すものではありません。
ベンチマーク中は、セキュリティ緩和策とCONFIG_HARDENED_USERCOPYを無効にしていました。また、サーマルスロットリングの影響で、スループットの比較は複雑になりました。
非常駐のユーザーバッファへの読み取りも、コストが増えました。高速パスがまずコピーの失敗に遭遇し、その後フォールバック側でフォルトを処理するためです。
解放の遅延は、メモリ管理の面で大きなトレードオフを生みます。解放待ちのページはアロケータの利用可能量の計算に反映されないため、メモリ不足（OOM）の判断が早まりかねません。
追加のパッチでは、CPUごとのキューが1,024ページを超えた場合にグレースピリオドを早めます。これにより保持されるメモリは減りますが、会計上の問題は解決しません。
トーバルズ氏は、連続メモリ割り当てでの性能退行、s390のセキュアメモリの挙動が未解決であること、未テストの構成が残っていることも指摘しています。
競合状態のテストでは、破損した読み取りは報告されませんでした。一方で、遅延解放を意図的に回避すると誤ったデータが返され、ライフタイム保証が重要であることが示されました。
このパッチシリーズは、AIが支援するシステム開発の一例であり、カーネル開発の自律化を意味するものではありません。有望な性能を本番環境に導入するには、より広範なテストと独立したレビューに加え、文書化された正当性のリスクを解消する必要があります。
1万6,000以上のSOCチームがANY.RUNを活用し、脅威調査を効率化して手作業を削減しています。 チームで試してみる
翻訳元: https://cyberpress.org/linus-torvalds-claude-code-linux-kernel-file-read/
