Lorenzo Stoakesが2026年9月14日、Linuxカーネルのビルドを高速化する21本のv2パッチをメーリングリストへ投稿した。最大値は、デュアルEPYCサーバーでフルビルド時間を188.0秒から121.1秒へ縮めた36%である。だが、速くしたのはコンパイラではない。数百スレッドを使っても最後に残る依存解析、巨大な中間ファイル、細かすぎる仕事の配布、圧縮といった「直列の尾」を一つずつ削った。LLMが探索を助けたこの系列から見えるのは、AIの速さよりも、生成支援を上流へ通せる変更へ変える人間の仕事である。
21本のv2が狙う「コンパイル後の待ち時間」
v2のカバーレターに並ぶ変更は47ファイルにまたがる。対象はKbuild、kallsyms、modpostに加え、objtoolやRustビルド、gzip圧縮にも及ぶ。変更量は2,982行追加、865行削除である。一見すると別々の小細工だが、狙いは共通している。大量のCファイルを並列にコンパイルした前後で、1本の処理や少数の仕事だけが残り、全CPUがその終了を待つ時間を減らす。
フルビルドでは、コンパイルが依然として時間の大部分を占める。ところが1ファイルだけを変える増分ビルドや、変更の有無だけを調べる変更なしビルド（no-op build）になると、コンパイル量は急減する。依存関係の読み込み、再リンク、シンボル生成、圧縮などの固定費はあまり減らないため、その比率が跳ね上がる。v2で全モジュール有効構成のフルビルドが19〜36%短くなる一方、増分ビルドは61〜66%、変更なしビルドは89〜95%短くなったのは、この構造を反映している。
つまり、21本を一本の高速化アルゴリズムとして読むと実態を見失う。不要なソートを消す。大きなテキストを生成しない。同じ検査を繰り返さない。数ミリ秒の仕事をまとめて渡す。直列だった解析や圧縮を安全な範囲で並列化する。個々の利益は小さくても、最後に残る待ち時間を別々の場所から削れば、並列コンパイル後の待ち時間が全体に占める割合が大きい環境ほど効きやすい。
36%は上限値であり、誰にでも同じではない
36%は、2基のEPYC 9754を積む256コア512スレッド機で、全モジュール有効構成（allmodconfig）をGCCでフルビルドした値である。188.0秒から121.1秒へ66.9秒短縮し、その短縮分を188.0秒で割って四捨五入すると36%となる。Clangでは259.5秒から184.6秒への29%減だった。64コア128スレッドのThreadripper 9980XではGCCが19%、Clangが22%減である。
対照的に、8コアの2022年型M2 MacBook Proで既定構成（defconfig）をGCCビルドした時間は519.3秒から512.4秒へ縮んだだけで、改善率は1%だった。Clangの改善率は10%である。v2のフルビルド改善率は、EPYCの全モジュール有効構成・GCCで36%だった一方、M2の既定構成・GCCでは1%にとどまった。
この両端を、CPUのコア数だけを変えた比較とはみなせない。機械、アーキテクチャ、設定、ツールチェーンが同時に異なるからだ。EPYC側は広大なx86のモジュール群を構築するため、生成物と後処理も膨らむ。M2側の既定構成は仕事量が小さく、x86向け最適化の一部も効かない。差が示すのは因果効果ではなく、同じ系列でも削れる待ち時間の量が環境によって大きく変わることである。
測定条件にも注意が要る。投稿者は、srcversion生成を改善する別系列と、Josh Poimboeufによるnoreturn関連の系列を追加し、KBUILD_RUST_THREADS=8、-j $(nproc)、pigz導入済みで計測した。数字は複数回の中央値や平均ではなく、最良値である。しかも21本ごとのアブレーション表はない。36%は再現を待つ上限値であり、一般的な開発機で約束される速度ではない。
巨大な生成物と細粒度ジョブを消す
GNU makeが読む.cmdファイルは、変更がなくても重い。amdgpuのような大きな対象では、各オブジェクトが千件を超える依存関係を持ち、それをmakeの構文として直列に解析する。depcheckパッチはC製の小さな補助プログラムで依存ファイルを一度ずつ検査し、再構築が必要な対象だけを小さな断片としてmakeへ返す。補助プログラムが失敗すれば従来経路へ戻る。v1の個別実測では、amdgpuのmake解析が380ミリ秒から10ミリ秒に、対象ディレクトリ全体が2.2秒から0.4秒になった。
仕事を細かく分けすぎた費用も大きい。x86-64の全モジュール有効構成では、モジュール最終化が約2万2,000件の数ミリ秒ジョブになりうる。最終化パッチは、これを128件単位にまとめて処理する。CPUが実作業をする時間より、シェルを起動し、環境を渡し、ジョブを回収する時間が支配するなら、並列数をさらに増やすより荷物をまとめた方が速い。
modpostが作る1万1,189個の*.mod.cも同じ問題を抱えていた。小さなCファイルを一つずつコンパイルすると、ヘッダー依存の生成とobjtoolの検査まで付いてくる。v1の測定では合計6,300 CPU秒を使い、128スレッドでも64秒を要した。後から読み直す.cmdだけで約1.3GiBに達する。提案パッチは必要な記述子をアセンブリで直接生成し、Cコンパイラを通る迂回をなくす。
kallsymsは約15万8,000シンボルを37MiBのアセンブリへ書き出していた。バイナリ化パッチでは、生データを2.6MiBのファイルに出し、9.8MiBの小さなアセンブリから.incbinで取り込む。生成されるオブジェクトは同一だという。ここでも計算式を賢くしたのではなく、コンパイラに巨大な文字列表現を読ませる理由そのものを消している。
最後の圧縮も直列区間になる。pigz対応のv1実測では、36MiBのvmlinux.binをgzipで圧縮する時間が1.6秒から0.09秒へ縮んだ。ただしgzipとpigzは同じ内容を展開できても、圧縮後のバイト列は一致しない。再現可能ビルドでは、別のビルダーが同じ圧縮器を使うよう固定しなければならない。速さは無料ではない。
v2は高速化を保ちながら安全側へ寄った
v2は23本から21本になり、2本はすでに上流へ入り、別の2本は同等の作業を担う別系列があるため削除された。上流へ入ったのはmksysmap関連の修正で、コミット281b61d408d4と59351365ac27になった。一方、srcversion関連の2本は重複作業を避けるため系列から外れた。新しいパッチの追加や分割、並べ替えもあるため、23から4を引いた単純な対応ではない。それでも、v2がレビューで範囲を整理した事実は明確である。
安全側への変更は性能値より重要だ。Rustコンパイラの並列フロントエンドは出力が再現可能でないため、自動的には有効にせず、KBUILD_RUST_THREADSを設定した場合だけ使う形になった。objtoolの命令デコード並列化では、目的地を解決する処理の一部を直列へ戻し、共有するpv_ops状態をロックした。Sashikoの自動検査は多数の誤警告を出したが、有効な指摘もあった。さらにThreadSanitizerが、Sashikoの報告にない競合を見つけた。
投稿者はarm64、arm、RISC-V、powerpc64、s390、LoongArchの広い構成をビルドし、9アーキテクチャをQEMUで起動した。複数アーキテクチャでSystem.mapの一致も調べ、kallsymsの自己テスト、モジュールの着脱、外部モジュールを確認したと報告している。これは有力な検証だが、全構成や全ツールチェーンの正しさを保証するものではない。だからこそ、各変更を担当サブシステムへ分け、メンテナーの判断を通す必要がある。
第三者追試が確認した二桁改善
投稿者以外の測定は、最大36%より控えめだった。LKMLへ集約されたv1の追試では、EPYC 9454Pが約13%短縮した。80コアのAmpere Altraでは6時間21分42秒から5時間31分15秒となり、差は3,027秒、13.22%である。32コアAMD機では3時間38分55秒から3時間13分18秒へ縮み、11.7%だった。
三つの追試は、系列が投稿者の2台だけで効く偶然ではなさそうだと示す。一方で、機械ごとに構成とビルド行列が異なり、対象はv2ではなくv1である。追加系列の有無もそろっていない。したがって、第三者が確かめたのは異なる環境でも二桁の短縮が出る方向性までで、512スレッド機における36%の独立再現ではない。
v1の見出しで使われた「増分最大70%」にも更新が必要だ。v2の再測定では全モジュール有効構成の増分ビルドは最大66%で、EPYC/GCCが70.9秒から24.3秒へ縮んだ。変更なしビルドの最大は同じ条件の30.6秒から1.5秒、95%減である。v2を語るなら、古い最大値をそのまま持ち越すべきではない。
AIが見つけ、人間と検査ツールが採用可能性を作った
Stoakesは、LLMをボトルネックの発見、改善案の作成、ビルドとテストの実行、デバッグ、結果分析に使ったと説明する。利用したモデル名、投入量、費用、試行回数は公表していない。全コミットにはAssisted-by: LLMを付けたが、生成コードの多くは「醜悪」だったため、自ら監査して書き直し、性能と正しさを手作業で確認したという。
Linus Torvaldsの返信は、この責任分界を端的に表す。LLM利用の開示を見て当初は身構えたものの、整理後のパッチは恐れていたほどひどくなく、小さく安全な変更に見えると評価した。適切なツリーを通じた採用にも前向きだった。ただし、自身で適用して計測したわけではない。Rustはまだ準備不足で、objtoolは担当メンテナーの承認が必要だとも留保した。
StoakesがLLMを候補探索に使ったことは確認できる。しかし、パッチ系列だけではAIを使わない場合より開発が何時間短くなったか、どの変更がLLMなしでは見つからなかったかを測れない。探索速度や開発時間への効果は評価不能である。確認できるのは別のことだ。人間が変更内容を読み、自動検査の誤警告を選別し、動的検査で見落としを補い、保守担当者が採否を判断する工程があって初めて、候補はLinuxへ入れられる形になる。
Linux 7.4の採用手続きと、性能評価に残る課題
2026年9月14日時点で、v2は提案・レビュー中であり、Linux 7.4への採用は決まっていない。Phoronixが伝えたのも「入りうる」という期待である。21本が一括で入るとも限らず、すでに上流化したmksysmap修正のように、Kbuild、objtool、Rustなどの担当ツリーを通って別々に進む可能性がある。
上流採用で確認できる手続きは、objtoolを含む各担当メンテナーの判断である。一方、性能の一般性を読者が見極めるには、別の検証が要る。追加系列を含めた測定から各パッチの寄与を分け、最良値だけでなく中央値と分散を示すことだ。v2を一般的な開発機や各ディストリビューションの構成で追試し、pigzとRust並列化が再現可能ビルドへ与える影響を確かめる必要もある。これらは未解消の評価課題であり、メンテナーが示した正式な採用条件ではない。
数百スレッド機で36%を再現できるかだけが試験ではない。小さな開発機でも退行せず、複数のアーキテクチャで正常にビルドできる必要がある。同一条件では成果物を再現でき、保守担当者が長期に読める変更であることまでそろって初めて、この高速化はLinuxの標準工程になれる。
