本文へスキップ

Linux 7.4のkbuildパッチ、カーネルのビルド時間を短縮

Linux 7.4を狙うkbuild(ケービルド)のパッチ群が、変更なしのビルドを約80%速くし、allmodconfigの完全ビルドから37.6秒を削ります。

著者

3 分で読めます

英語の原文から機械翻訳したものです。原文はClaire Whitmoreが事実確認と編集を行いました。内容に相違がある場合は英語版が優先されます。 編集方針

kbuildのパッチ群のGitHubミラーで、件名とLorenzo Stoakesが投稿した23件のコミットが並んでいる画面。

数字で見る

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バイト単位の検証、そしてそれを明示する記述を通りました。この組み合わせが、こうしたパッチを査読可能にしています。

出典

  1. Linux Kernel Build Times Ready To Be Significantly Reduced With Latest Patches - Phoronix
  2. [PATCH 00/23] kbuild: significantly speed up kernel builds - GitHub
  3. AI Made A Lot Of "Hideous" Code But Found Major Bottlenecks For Faster Linux Compilation - Phoronix

関連記事

夜の薄暗い木製デスクに置かれたノートパソコン。画面には赤と緑の行が並ぶぼやけたコードレビューが映り、隣には小さなTuxのペンギン人形、コーヒーカップ、眼鏡があります。
プログラミング

Linux Foundation、メンテナーはPRの4件に1件を「AI slop」とみなす

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

電子工作ラボの灰色の静電気防止マットに置かれた、ブランド表示のない小型シングルボードコンピューター。USBフラッシュドライブが差し込まれ、隣には頑丈なアルミ製ケースがあります。
プログラミング

BeamFSのRFC:Reed-Solomon符号を使うLinuxファイルシステム

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