Linux 7.4のkbuildパッチ、カーネルのビルド時間を短縮
Linux 7.4を狙うkbuild(ケービルド)のパッチ群が、変更なしのビルドを約80%速くし、allmodconfigの完全ビルドから37.6秒を削ります。
3 分で読めます
英語の原文から機械翻訳したものです。原文はClaire Whitmoreが事実確認と編集を行いました。内容に相違がある場合は英語版が優先されます。 編集方針

数字で見る
- cut from a clean x86 allmodconfig build
- 37.6s
- faster no-op x86 builds in the posted series
- 79-82%
- faster no-op builds measured on an Apple M2
- 74-76%
Linuxカーネルのビルドを速くするパッチ群が2026年9月18日に第3版へ達し、いまはLinux 7.4を狙っています。Armの技術者Lorenzo Stoakesが、大規模言語モデルを使ってビルドのどこで時間が失われているかを調べたうえで書きました。測定された結果は、ほかのコアが空いたまま1つのコアを待つ時間が大きく減ったビルドです。
このパッチ群が挑む問題は、パッチ群の説明文にはっきり書かれています。典型的なカーネルのビルドは、単一スレッドの詰まりに閉じ込められて、いらだたしいほどの時間を費やします。いまの計算機は多くのコアを持ちます。それでもカーネルのビルドは、いくつもの段階をそのうちの1つだけに渡し続けていました。
時間はどこへ消えていたのか
作業は、多くの開発者が普段は見ないビルドの部分に触れます。kbuildは、すべてを進めるmake中心の仕組みです。kallsymsは、カーネルのアドレスとシンボル名を対応づける表を作ります。modpostはモジュールのメタデータを検査し、objtoolは生成されたコードを検証し、mksysmapはシンボルマップを書き出します。Rust向けのビルド経路にも手が入りました。
無駄の一部は単純に量でした。説明文は、いまのx86-64カーネルがおよそ158,000個のシンボルを持つため、1回の走査で数百万回の繰り返しが起きると指摘します。またx86 defconfigのビルドで5,810件、arm64で15,200件の不要なモジュール情報の項目にも触れています。生成されたアセンブリのファイルは37 MiBに達し、アセンブルに0.57秒かかり、それが1回のビルドで2、3回起きていました。
数字と、その食い違い
| 測定 | 変更前 | 変更後 |
|---|---|---|
| x86 allmodconfigの変更なしビルド | 11.6秒 | 2.4秒 |
| x86 allmodconfigの変更なしビルド、別の設定 | 11.0秒 | 1.9秒 |
| x86 allmodconfigのクリーンビルド | 342.1秒 | 304.5秒 |
CONFIG_KALLSYMS_ALLでのkallsyms圧縮 | 0.59秒 | 0.33秒 |
これらの数値は投稿されたパッチ群のもので、Stoakesが2026年9月8日に送った時点では23件のパッチでした。Phoronixが9月18日に伝えた第3版は20件のパッチで、最新のupstreamのコードに載せ直され、AMD EPYC、Threadripper、Apple M2の各機で測定されています。PhoronixはApple M2での変更なしビルドの改善を74〜76%とし、その結果を「AMDのx86_64の数値と同じくらいの範囲」と評しました。
見出しになる割合は2つの報告で異なります。Phoronixの9月8日の記事は、全モジュール込みの完全ビルドを約36%速い、差分ビルドを最大70%速い、変更なしビルドをおよそ90%速いと説明していました。パッチ群自体は、変更なしビルドで79〜82%、allmodconfigのクリーンビルドで11%としています。この差は、機械、設定、版の違いを映しています。したがって、どれか1つの数字ではなく、幅を正直な答えとして受け取ってください。9,000件のパッチを含む安定版カーネルのまとまりについての記事は、同じ木の別の面を示していました。多くのコードが、たびたび動いているということです。
LLMが見つけ、人が仕上げた
Stoakesは作り方について率直です。「まずどこが詰まりかを判断し、次にどう改善するかを考えるためにLLMを使った」と書いています。出力への評価はもっと辛口です。「大量のコードを生成したが、その多くは見苦しかった」。彼は多くを監査して書き直し、コミットメッセージも大きく手を入れたと述べています。各コミットには、支援を明示する「Assisted-by」の記述が付きます。
パッチ群は、生成された出力が元の実装と1バイトも違わないことを確認したとも述べています。ビルドの仕組みにとって、これこそ重要な検査です。違うカーネルを作る速いビルドは、速いビルドではありません。
これが開発者にとって意味すること
日常的にカーネルをコンパイルするなら、注目すべきは変更なしの場合です。ファイルを1つ変えた後、あるいは何も変えずに走らせるビルドであり、パッチ群が最大の効果を主張する場所でもあります。その数分は、デバッグの繰り返しのたびに効いてきます。
いま適用するより、取り込まれるのを待ってください。狙いはLinux 7.4であり、自分の木への載せ直しはマージ後のほうが時間の使い方として賢明です。カーネルをビルドするCIを保守しているなら、allmodconfigのクリーンビルドの改善は約11%と小さいほうだと覚えておいてください。
作り方そのものも注目に値します。機械が提案した最適化が、人の査読、1バイト単位の検証、そしてそれを明示する記述を通りました。この組み合わせが、こうしたパッチを査読可能にしています。
出典
関連記事

Linux Foundation、メンテナーはPRの4件に1件を「AI slop」とみなす
リナックス・ファウンデーション(Linux Foundation)の報告書によると、メンテナーは届くプルリクエストの4件に1件が低品質なAI生成物だと推定しています。大規模プロジェクトでは31%です。一方、AIはコードを書く時間を推定52%短縮します。

Torvaldsのページキャッシュパッチに改良版:ext4で4.5倍高速に
MetaのKiryl Shutsemauが、Torvaldsのページキャッシュ(page cache)パッチを18本のパッチからなるRFCに仕上げました。ext4の64スレッドでは、小さな読み取りが毎秒約1,500万回から7,000万回に増えました。

BeamFSのRFC:Reed-Solomon符号を使うLinuxファイルシステム
18件のパッチからなるLinuxのRFC、BeamFSは、すべてのブロックをReed-Solomon(リード・ソロモン)符号語として保存します。これにより、1台のディスク上で反転したビットを修復できます。代わりに容量の7%を使います。