Linuxのメモリ改善にClaude Codeを活用したLinus Torvalds、レビューで競合状態が判明

Linuxの開発者でありカーネル開発の主任メンテナーであるLinus Torvaldsは、ファイル読み取りパスに2年以上存在していたボトルネックへの対処を支援するため、AnthropicのClaude Codeを使用した。10個のパッチからなるシリーズは、64コアのThreadripperマシン上で行った人工的なテストにおいて、読み取り速度を最大23倍向上させた。しかしLinuxカーネルのレビュアーは後に競合状態を発見し、メモリ回収設計の安全性について疑問を呈したため、パッチはまだマージされていない。

ページメモリの参照カウンターにおける問題

この作業は、page cache内のfolioと呼ばれるオブジェクトの参照カウンターをめぐる競合に関係している。page cacheは、ファイルから読み取ったデータを保持してアクセスを高速化する層である。このボトルネックは、ある顧客のワークロードで発生した後、2024年に報告された。Torvaldsのノートパソコンで行ったテストでは、8スレッドを使用するテストにおいて、この競合がコア間のHITM操作の99.92%を占めることが示された。

Torvaldsによると、彼はこの問題に対する以前の修正の不具合を含むバージョンを18か月間実行していた一方、他の開発者たちは自身の試みで問題に直面していた。新しいパッチは、最も頻繁に使用されるキャッシュ読み取りパスからfolioの参照を増減する操作を取り除くことを目指している。ただしTorvaldsは、現実のワークロードでは人工的なテストと比べて効果がはるかに小さくなると警告した。

Claude Codeの役割と結果の限界

Torvaldsのツリーにはnoref-filemap-read-with-llmという名前の実験ブランチが登場し、その後、シリーズにはClaude Codeの役割についての説明が含まれた。Torvaldsの報告によると、このツールは実装、テスト、初期ドキュメントを作成し、彼の指示の下でコードをレビューした。一方、性能テストの実行は彼自身が担当した。

最初のシリーズでは、彼のノートパソコンにおける読み取り速度が毎秒約1,000万回から3,300万回に向上し、読み取り1回あたりのカーネルサイクル数は約2,950から725に減少した。改訂版のシリーズでは、高負荷時にThreadripperマシンの性能が毎秒1,330万回から3億400万回に向上し、読み取り1回あたりのサイクル数は約20,000から735に減少した。

なぜ性能数値だけでは不十分なのか

この改善には潜在的なコストが伴った。初期実装では、CPUが回収保留中のページを1,024ページ超処理した際に、強制的な待機期間が発生した。また、関連付けられていないユーザーページへの読み取りでは、既存のパスに戻る前に追加のフォールトが発生したため、16バイトの単一スレッド読み取りのコストは約4,150サイクルから6,550サイクルに増加した。この後退がrcu-free-v3に残るかどうかは、まだ明らかになっていない。

レビューで明らかになったより重大な危険

Matthew Wilcoxは新しいフラグPG_rcu_freeの使用に異議を唱え、ページの種類と、非アクティブなfolioを回収する別の仕組みに基づく代替案を提案した。また、Kiryl Shutsemauはこのフラグを64ビットシステムに限定することを提案し、David Hildenbrandもこの方向性を支持した。

Shutsemauはさらに、filemap_read_rcu_batch()関数における競合状態を発見した。folioの置き換え後にファイルサイズが拡張されると、実際には書き込まれていないデータが露出する可能性があるためである。Torvaldsはファイルサイズをより早い段階で読み取り、検証操作をまとめることを提案し、これは改訂版パッチに組み込まれた。

certi.newsによる編集上の見解：この事例は、AIによるプログラミングツールがカーネルのテストにおいて大幅な改善へ迅速に到達できる一方、並行性とメモリのライフサイクルを理解する専門的なレビューの必要性をなくすものではないことを示している。ここでの記録的な数値は、特定の環境における改善を証明するものであり、自動的にマージ可能であることや、実装の安全性を保証するものではない。