カーネルビルド最大36%高速化の23パッチ｜LLMが見つけ、人が「hideous」を書き直した

はじめに

2026年9月8日、Linux カーネルのメーリングリストに [PATCH 00/23] kbuild: significantly speed up kernel builds という23本組のパッチが投稿されました。投稿者は Lorenzo Stoakes 氏（署名は “Lorenzo Stoakes (ARM)"）。カバーレターの冒頭はこうです。

A typical kernel build consists of a frustratingly large amount of time spent stuck in single-threaded bottlenecks. （典型的なカーネルビルドは、いらだたしいほど長い時間を、単一スレッドのボトルネックに引っかかって過ごしている）

結果として投稿者が示した数字が、allmodconfig のフルビルドで最大36%減、インクリメンタルビルドで最大70%減、何も変えずに make を打つ no-op ビルドで最大94%減です。128スレッドの Threadripper、512スレッドの2ソケット EPYC、8コアの M2 MacBook Pro の3台で、gcc と clang の両方で測った表がついています。

数字だけなら「速くなった」で終わる話です。この投稿が当サイトで扱う価値を持つのは、カバーレターに 「LLM usage」という節 があるからです。

An LLM was used to first determine where the bottlenecks were then to figure out how to improve them. It generated a lot of code, much of it hideous. （LLM を使って、まずボトルネックがどこにあるかを特定し、次にどう改善するかを考えさせた。大量のコードを生成したが、その多くは醜悪だった）

そしてそのコードを 「私が徹底的に監査し、多くを書き直した」 と続け、23本すべてのコミットに Assisted-by: タグを付けています。翌9日には Linus Torvalds が返信し、「怖くて最初は見なかった」と正直に書いたうえで「どのパッチも全然ひどくない。マージに全面的に賛成だ」と述べました。

当サイトは2週間前に、Linux のネットワーク担当メンテナが AI 由来のパッチの洪水に「完全に手一杯だ」と書いた話を書きました。今回はその対になる肯定側の実例です。同じ道具を、同じコミュニティの、しかも「洪水を受ける側」のメンテナが使ったとき、何が起きたか。LLM に何をさせ、人が何を握ったかが一次資料に書いてある——ここがこの記事のいちばんの価値です。

この記事では次の6点を扱います。

1. kbuild とは何をしているのか — Kconfig からリンクまでの流れと、「no-op」「インクリメンタル」「allmodconfig」の意味
2. 何が投稿されたか — 3台×2コンパイラの元の秒数と、第三者の追試
3. 23パッチの中身 — mksysmap の C 再実装、*.mod.c の廃止、objtool の DWARF、pigz など技術的に面白いものを1つずつ
4. LLM に何をさせ、人が何を握ったか — カバーレターの原文と、投稿者自身の言葉
5. Linus の返信とスレッドの現在地 — 賛否・注文・マージ前のレビュー状況（2026年9月12日時点）
6. 手元で測ってみた — 当サイトの Ubuntu 26.04 機（Core i7-4790K・4コア8スレッド）での実測——インクリメンタル −47%、no-op −59%、フル −2.4%

🧱 1. kbuild とは — カーネルビルドで何が起きているか

Linux カーネルのビルドシステムは kbuild と呼ばれます。make defconfig && make -j$(nproc) の裏で、実際には次のような工程が走っています。

読者の PC のコア数がいくつあっても、この図の C（コンパイル）以外は、ほとんどが1本のスレッドで順番に進みます。コンパイルが終わったあとの「尾」——ld -r、objtool、modpost、kallsyms のリンク繰り返し、gzip——は直列です。コア数を増やしてもここは縮まない。投稿者が「単一スレッドのボトルネック」と呼んだのはこの部分です。

投稿者は9日のメールで、LLM に描かせたビルド中の CPU 使用率グラフを添付し、あわせて ASCII 版も載せています。文字1個が一定時間で、文字の種類が「そのとき何が走っていたか」を表します。並列に走るコンパイルは C、それ以外は1本の直列区間です（帰属：投稿者が LLM に生成させたもの。図の CPU 使用率の段は罫線文字のため省き、工程の段だけ転記しました）。

凡例: C=コンパイル L=リンク O=objtool P=modpost K=kallsyms Z=圧縮 m=make自身 .=アイドル
（x86 allmodconfig, clang, 128スレッド）

== クリーンビルド（1文字=4秒）==
before 343.6s
mCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCOOOOPPPCCCCCCCCCCCCCLL
after  265.6s
CCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCOOCCCCC

== mm/vma.c を1つ touch（1文字=0.5秒）==
before 45.7s
mCmCCmmmCLOOOOOOOOOOOOOOOOOOOOmPPPPPPPPPPPPPPPPPPPCLmKKKCCCmmKKKCCCLmmmmmmCCZZZZZZZZZZZZZZC
after  15.7s
mmCCCLOOOOOOOOOPPPPLKCKCLmmmmmCC

== 何も変えずに make（1文字=0.2秒）==
before 14.4s
CCCCmmmCCCmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmm
after  2.0s
CCmmmCmm

インクリメンタルの before を見ると、O（objtool）が20文字＝10秒、P（modpost）が19文字＝9.5秒、Z（gzip 圧縮）が14文字＝7秒。1ファイル直しただけなのに、コンパイルそのものはほんの一瞬で、あとは全部「尾」です。no-op の before に至っては、ほぼ全部が m——make 自身が依存関係を読み直しているだけで14秒かかっています。この系列がやったのは、この尾を「並列にできるものは並列に、無駄な仕事はやめる」ことです。

📊 2. 何が投稿されたか — 数字と検証

まず投稿者が示した数字を、元の秒数のまま並べます。計測機は次の3台です（帰属：カバーレター）。

allmodconfig（投稿者の計測・best of several runs）

defconfig（投稿者の計測・best of several runs）

見出しの「36%／70%／94%」は、いずれも EPYC・gcc・allmodconfig の値です。8コアの M2 ではフルビルドの削減は9%にとどまる一方、インクリメンタルは半分、no-op は3分の1以下になっています。コア数が少ないほどコンパイル自体が支配的になるので、フルビルドの効きは小さい。逆に、直列の尾は機械の大小によらず存在するので、インクリメンタルと no-op はどの機械でも大きく効く——表はそう読めます。

投稿者が何を検証したか

カバーレターの「Testing」節の要旨です。速度の主張と同じくらい、ここが重要です。

• x86 以外に arm64・arm・riscv・powerpc64・s390・loongarch で allmodconfig をビルド。arm64・arm・s390・loongarch では、生成される System.map が旧 mksysmap の出力と同一
• x86・arm64・arm・riscv・loongarch・powerpc64・s390・m68k・parisc64 のカーネルが QEMU で起動し、System.map の全 text シンボルが /proc/kallsyms にリロケート後のアドレスで存在し、モジュールのロード／アンロードが通る
• CONFIG_MODVERSIONS・CONFIG_EXTENDED_MODVERSIONS・CONFIG_MODULE_SRCVERSION_ALL を有効にした x86 カーネルが起動し、モジュールを扱える。外部モジュールは in-tree と O= の両方でビルド可
• 23コミットすべてが x86 defconfig で個別にビルドできる
• 「ビルド工程の一部は変わったが、すべてのツールは以前と同一に機能するはず」

第三者の追試（発言者に帰属）

• Florian Fainelli（Broadcom）、9月9日：「AMD EPYC 9454P のサーバーで、arm64 の defconfig を make -j97 で走らせて 13% 程度の改善」
• Nathan Chancellor（kbuild 共同メンテナ）、9月12日：80コアの Ampere Altra で 6時間21分42秒 → 5時間31分15秒（−13.22%）、32コアの AMD 機で 3時間38分55秒 → 3時間13分18秒（−11.7%）。「機械ごとにビルドの組み合わせ（build matrices）は違うが、異なる環境で似た数字が出ているのはよい」

いずれも投稿者の環境より控えめな数字で、それがむしろ信頼できます。「あらゆる環境で36%」ではなく、「直列の尾が全体に占める割合ぶんだけ速くなる」というのが実態です。

🔧 3. 中身を見る — 23パッチのうち技術的に面白いもの

カバーレターは23本を「基本的には、単一スレッドの処理をできる限り並列化し、ビルドに使うコードの効率を上げる」と要約しています。以下、コミットメッセージを読んで、何がどう変わったかを1つずつ追います。数字はすべて投稿者の128スレッド Threadripper での計測です。

3-1. mksysmap を C で書き直し、nm をやめる（08）

System.map を作る scripts/mksysmap は、30個のパターンからなる sed スクリプトでした。リンクのたびに nm -n vmlinux | sed -f mksysmap を通し、その出力を kallsyms が読む。x86-64 の allmodconfig では 250 MiB のファイルに対して nm を3回走らせ、毎回50万行を書いて読む。llvm-nm で1パス0.5秒、GNU nm で0.2秒、さらに解析が乗ります。

パッチ08はこれを丸ごとやめ、kallsyms が ELF ファイルのシンボルテーブルを直接読むようにしました。新しい scripts/kallsyms-sysmap.c（269行）は、sed の30パターンを C のテーブル（除外プレフィックス・サフィックス・完全一致名）に移植し、nm が付ける型文字（T、t、d、b など）を ELF のセクションフラグから再現し、nm -n と同じ「アドレス順、同じなら名前順」で並べ替えます。scripts/mksysmap（94行）は削除。

肝心なのは互換性で、コミットメッセージには「System.map は GNU nm でも llvm-nm でも nm | mksysmap とバイト単位で同一（x86 の2構成、arm64・arm・s390・loongarch の defconfig）」とあります。出力を変えずに工程を減らした、という種類の改善です。

3-2. kallsyms の出力をバイナリに（04）— Linus が「もっと先へ」と言った場所

kallsyms はシンボル名を圧縮した表をアセンブリのソース（.byte の羅列）として吐き、それをアセンブラに通してオブジェクトにします。x86-64 で15.8万シンボルなら 37 MiB の .S ファイルで、アセンブルに0.57秒。これがビルド1回につき2〜3回走る。

パッチ04は、バイト単位の表をバイナリファイルに書き出して .incbin で取り込む形にしました。.S は9.8 MiB＋2.6 MiB の .bin になり、アセンブル時間は0.16秒。オブジェクトは同一です。

Linus はここに反応しました（9月9日）。要旨は「速くはなったが、根本の馬鹿らしさは直っていない。この kallsyms が生成するファイルはすぐにアセンブルされる以外の用途がなく、人間が読むことは一度もない。libelf はもうビルドの必須要件なのだから、オブジェクトファイルを直接書けばいい」。そしてこう続けます。

But when there’s a LLM that was used to find these things and help fix them up, and it’s something this mechanical and the result really isn’t ever human-readable and never has been, I feel like the obvious step would be to just ask the little helper bot to switch the whole kallsyms to using libelf-devel and writing an object file directly. （だが、こういう箇所を見つけて直すのに LLM を使ったのなら、しかもこれほど機械的で、結果が人間可読だったことなど一度もない代物なら、当然の次の一手は、その小さな助手ボットに「kallsyms 全体を libelf を使ってオブジェクトファイルを直接書くように切り替えて」と頼むことだと思う）

「誰もこの手のごてごてした細部に付き合いたくないし、ELF ライターを書く労力もかけたくない。だが LLM がいるなら話は別だ」という言い方で、LLM を使うなら作業量の壁を理由にした妥協はしなくていい、と読める返信です。

3-3. make が依存関係を読む時間を C で削る（10・11）

no-op ビルドで14秒かかっていた m の正体がこれです。各オブジェクトの .cmd ファイルには、そのファイルが依存するヘッダの一覧が書かれていて、1オブジェクトで千個を超えることがざらにあります。ツリーにほとんど変更がないとき、make は「この千個のヘッダは更新されていないか」を1本のスレッドで延々と確かめます。

先にパッチ10が、各オブジェクトが「組み込みかモジュールか、どの複合オブジェクトに属するか」を何度も計算し直していた部分をキャッシュにします（ディレクトリ内のオブジェクト数に対して O(n²) に伸びていて、310オブジェクトの amdgpu で特に痛かった、とあります）。そのうえでパッチ11は scripts/basic/depcheck.c（442行）を新設し、この確認を C でやらせます。ディレクトリ内の各ターゲットの .cmd を読み、依存先ごとに stat() を1回だけ呼び、「依存先がすべて存在し、ターゲットより古い」ものについては保存済みコマンドラインだけの断片を生成する。make はその断片を読むだけで済みます。失敗したら従来の .cmd 方式に戻る、という逃げ道つき。amdgpu ドライバのディレクトリでは、make が読む量が5分の1、読み込みは380ms→10ms、そのディレクトリの処理が2.2秒→0.4秒です。

Linus はここに「昔の記憶」を書き添えました（9月9日）。要旨は「ずっと前にカーネルビルドのプロファイルを取ったとき、.cmd の中で設定ヘッダに $(wildcard ...) を使っているせいで make の仕事が増えていた記憶がある。あれはパターンを合わせたいからではなく、存在しない設定ヘッダで make に文句を言わせないための唯一の方法だった。四半世紀前のコードで、以来誰も手を付けようとしていない。今 fixdep.c からその生成を外してみたが、ビルドは何も気にしなかった。もう丸ごと不要なのかもしれない」。改善を歓迎するだけでなく、自分の記憶にある別の芽を差し出す返信です。

3-4. *.mod.c をやめてアセンブリで出す（15・16）— no-op を82%削った本丸

これが allmodconfig の no-op 短縮の主役です。modpost はモジュール1個につき1つの <module>.mod.c を生成します。中身は .modinfo 文字列、__this_module 記述子、エクスポートシンボル表、CONFIG_MODVERSIONS なら CRC。このファイルは「ふつうのカーネル C ファイルとして」コンパイルされます——-include の前置き、linux/module.h のインクルード、fixdep が生成する数百のヘッダ依存、objtool の実行、LTO ならリンクまで。

x86-64 allmodconfig では 11,189個の *.mod.c がそれぞれ CPU 時間0.24秒、モジュール仕上げ全体で 6,300 CPU 秒＝128スレッドで64秒。しかも *.mod.o.cmd が 1.3 GiB 生成され、以後のビルドは毎回それを読み直す。no-op が遅い理由の大半がここでした。

パッチ15は記述子をアセンブリ（*.mod.S）で出すようにしました。struct module のサイズと配置、フィールドのオフセットは新設の scripts/mod/module-offsets.h から取ります。すると linux/module.h も、数百ヘッダの依存も、objtool もいらない。結果、make modules を全 *.mod.o と *.ko を消した状態から走らせると 64.5秒（6,306 CPU 秒）→ 28.5秒（518 CPU 秒）。no-op は11.0秒→1.9秒（−82%）。

ここでも互換性の確認が丁寧です。「.modinfo・.gnu.linkonce.this_module・__ksymtab*・__kcrctab*・__versions 等のセクションとそのリロケーションが、clang allmodconfig（CONFIG_COMPILE_TEST 無効）の 8,135モジュールすべてでバイト単位で同一」「違うのはコンパイラが周囲に足していたもの（__UNIQUE_ID_* のローカル、KASAN のコンストラクタ、x86 の .note.gnu.property）だけで、いずれもビルドに影響しない」。

続くパッチ16は副作用への対処です。仕事が小さくなりすぎて 約22,000個の数ミリ秒ジョブを make が配り切れない。そこで modules.order を128個ずつに分割して並列に走らせる。make modules は28.9秒→15.9秒。

Linus の反応（9月9日）は3-2と同じ方向で、「linux/module.h をインクルードしないのが最大の勝ちで、あとは AS を経由してオブジェクトを作るという回り道に意味があるとは思えない。この asm ファイルを見たい人間はいない。オブジェクトを直接生成する方が自然だ」。そして本音を一行。

I’ll also be honest: part of why I do these suggestions is that I do think it would be faster to skip the intermediate assembler step, but a big part of it is that I don’t love the random turds our build creates. Getting rid of the *.mod.c files would be a cleanup of our strange build. （正直に言うと、こういう提案をする理由の一部は中間のアセンブラ工程を飛ばす方が速いと思うからだが、大部分は、うちのビルドがまき散らす雑多なゴミが好きじゃないからだ。*.mod.c を消せるなら、この奇妙なビルドの掃除になる）

3-5. modpost の srcversion 計算を並列化（13・17）— そして v2 で落ちることになった

CONFIG_MODULE_SRCVERSION_ALL が有効だと、modpost は各モジュールのソースをハッシュして srcversion を作ります。x86-64 の allmodconfig では 20万個のファイルを1つずつ開いて、直列にハッシュしていました。パッチ13でバイト単位からファイル単位のハッシュに変え、パッチ17でスレッドプールを使って並列化。「2つ合わせて allmodconfig の modpost 実行時間がほぼ半分」「Module.symvers と全 *.mod.S はバイト単位で同一」。

ところがレビューで、Petr Pavlu 氏（SUSE）から「srcversion のサポート自体が別の系列で削除される予定（ビルド ID が同じ役割を果たすので不要）。今この2本を磨くのは無駄になる」（要旨）と指摘があり、投稿者は9月11日に「了解、v2 ではこの2本を落とし、カバーレターに依存関係を明記する」と返しています。LLM が見つけて人が仕上げた最適化が、「その機能ごと消す」という上流の判断で不要になる——こういうことが普通に起きるのがレビューです。

3-6. objtool が DWARF のリロケーションで手を止めないようにする（18・19）

objtool は vmlinux.o の命令を解読し、すべてのジャンプ・コールの行き先を解決します。その過程でリロケーションを「行き先」で引くハッシュを持つのですが、パッチ18のコミットメッセージによれば、allmodconfig で 約900万個のリロケーションをハッシュに入れ、そのうち約820万個は DWARF（デバッグ情報）セクションのものでした。DWARF のリロケーションは行き先で引かれることが一度もない。ハッシュを汚し、キャッシュミスを増やしていただけです。

パッチ18は、DWARF セクションはインデックスもハッシュもしない（万一引かれたら線形探索に落とす仕組みを添えて）、セクションごとに64バイト窓のリロケーションキャッシュを持つ、「決して戻らない関数（dead end）」の判定結果を関数ごとに1回だけ記憶する、の3点。「objtool の出力は x86_64 の defconfig・allmodconfig、gcc・clang でバイト単位で同一」。続くパッチ19で命令の解読と分岐先の解決を複数スレッドに分け、allmodconfig のインクリメンタルで −17%（28.4秒→23.7秒）。

Linus はカバーレターへの返信で「objtool の変更はかなり大きく、objtool の人たちの承認が要る」と注文を付けています。マージの経路として、ここは kbuild ツリーとは別扱いになる見込みです。

3-7. pigz があれば使う（23）— いちばん小さく、いちばん効く

最後のパッチはたった3ファイル、30行です。128コアの Threadripper で 36 MiB の vmlinux.bin を gzip -9 すると1.6秒、pigz なら0.09秒。gzip は並列化できないが、pigz は同じ機能を持つ並列実装で、そのまま置き換えられる。従来も KGZIP=pigz と環境変数で指定できましたが、これを「システムに pigz があれば既定で使う」に変えました。

-KGZIP = gzip
+KGZIP := $(if $(shell command -v pigz 2>/dev/null),pigz,gzip)

defconfig のインクリメンタルで −27%（7.4秒→5.4秒）。x86 のビルドは必ず vmlinux.bin の圧縮で終わるので、直列の尾の最後の7秒がそのまま消えます。再現可能ビルドについては「pigz 同士、gzip 同士なら出力はバイト単位で同一だが、gzip と pigz は互いに同じストリームを作らないので、同じツールを揃えること」と Documentation/kbuild/reproducible-builds.rst に追記しています。投稿者は Linus への返信でも「手元で試すなら pigz を入れないと全部の効果は出ない」と念を押しています。

23本の全体像

合計で 47ファイル、2,884行追加、682行削除です。

🤝 4. 「LLM に何をさせ、人が何を握ったか」— カバーレターの原文

この記事の中心です。カバーレターの「LLM usage」節を、そのまま引用します。

== LLM usage ==

An LLM was used to first determine where the bottlenecks were then to figure out how to improve them.

It generated a lot of code, much of it hideous.

I extensively audited and rewrote a lot of it, and heavily edited commit messages, the cover letter and comments.x ［原文ママ］

The LLM has also orchestrated build runs, testing, debugging and analysis.

I have manually checked for correctness in both build and running kernels generated with this series applied.

Performance improvements were also verified manually.

Since an LLM was used extensively, each commit carries an Assisted-by tag.

訳すとこうなります。

LLM を使って、まずボトルネックがどこにあるかを特定し、次にそれをどう改善するかを考えさせた。 大量のコードを生成したが、その多くは醜悪（hideous）だった。 私はそれを徹底的に監査して多くを書き直し、コミットメッセージ・カバーレター・コメントを大幅に編集した。 LLM はビルドの実行、テスト、デバッグ、分析のオーケストレーションも行った。 この系列を適用して生成したカーネルについて、ビルドと実行の両方で正しさを私が手作業で確認した。 性能の改善も手作業で検証した。 LLM を広範に使ったので、各コミットに Assisted-by タグを付けている。

分担を表にすると、次のようになります。

「探索と実行は機械に、判断と保証は人に」という分け方で、これは公式ドキュメントが求める線引きそのものです。Documentation/process/generated-content.rst は、ツール生成コンテンツを含む貢献に「どのツールを使ったか」「どの部分がツールの影響を受けたか」「どうテストしたか」を明らかにするよう求めていますが、このカバーレターにはその3点に対応する記述があります。

一方で書いていないこともあります。どの LLM（モデル名・ツール名）を使ったかは、カバーレターにもコミットにも書かれていません。タグも Assisted-by: LLM のみです。これは公式の書式（Assisted-by: LLM [TOOL1] [TOOL2]）に沿った書き方で、公式ドキュメントはモデル名の明記を要求していません。プロンプトの内容も書かれていません（同ドキュメントは「短いプロンプトから大部分を生成したなら含める、長いセッションなら要約を」と推奨しています）。

投稿者自身の言葉 — 「洪水を受ける側」として

もう一つ重要なのが、なぜここまで透明に書いたか、を投稿者本人が説明していることです。Nathan Chancellor 氏が「これを全部明記してくれてありがとう」と書いたのに対する、9月11日の返信です。

Of course, I am on the receiving end of a flood of LLM patches in mm, so it’s important to me to be transparent and consistent.

I repeatedly tell people - audit what it makes with a human pass, fix up awful code/comments/commit msgs, make sure you understand it + on you to make upstreamable + obviously ack that you used it.

So what’s good for the goose is good for the gander :) （もちろん。私は mm で LLM パッチの洪水を受ける側にいるので、透明で一貫していることが自分にとって大事だ。私はいつも人にこう言っている——生成物は人間の目で監査しろ、ひどいコード・コメント・コミットメッセージは直せ、自分で理解しろ、上流に入れられる形にするのはお前の責任だ、そして当然、使ったことは明記しろ。だから、人に言うことは自分にも当てはまる）

「mm」はメモリ管理サブシステムで、2週間前の記事で扱ったネットワークと同じく、AI 由来パッチの流入先です。メンテナとして人に課している条件を、自分が投稿者に回ったときに一つ残らず守った——この投稿の透明性は、そういう位置から出ています。9月9日には別の返信で「LLM を使うのに格好の題材だった（ただし、私は今後も自分の変更を保守できなければならないし、そこには依然として基準があるので、大量の飼い慣らし・レビュー・監査・書き直しを伴って）」とも書いています。

🐧 5. Linus の返信と、スレッドの現在地（2026年9月12日時点）

カバーレターへの返信（9月9日）

Linus Torvalds の返信は、冒頭の「単一スレッドのボトルネック」への一言から始まります。

.. you’re preaching to the choir. （……釈迦に説法だ）

そして allmodconfig の表に「非常に心強い。これはやるべきだ」。ただし個々のパッチへの反応は「数字の裏づけはなく、系列を自分のツリーに当てて試してもいない。パッチを読んだだけの反応だ」と断っています。続けて、LLM usage 節についてこう書いています。

This made me scared to look at the patches originally, and I held off in fear that the patches would be horrible and this build time improvement would be hugely controversial garbage code.

But: […]

None of the patches look at all horrible to me. You clearly excised the hideous parts. All of my reactions were of the type “this could probably be taken further” rather than me throwing my hands up in disgust. （これを読んで、最初はパッチを見るのが怖くなった。パッチがひどくて、このビルド時間の改善が大論争を呼ぶゴミコードになるのを恐れて手を止めていた。だが［「徹底的に監査して書き直した」の引用］——どのパッチも私にはまったくひどく見えない。醜悪な部分は明らかに切除されている。私の反応はすべて「これはもっと先まで行けるのでは」という種類のもので、嫌悪で両手を上げるようなものではなかった）

結論部分はこうです。

So the Rust parallelism thing clearly isn’t ready based on feedback from that quarter, but the rest looked safe and innocuous. I’m all for merging this, although it should obviously go in through the right channels. Mostly the kbuild tree, although some of it clearly would be other cases - the objtool change in particular is fairly substantial and needsobjtool ［原文ママ］ people to approve. It didn’t look all that contentious, but still..

Anyway, I’d love for this all to go in. Build times are a pet peeve of mine. （Rust の並列化はあちら方面の反応からして明らかにまだ準備ができていないが、残りは安全で無害に見えた。マージには全面的に賛成だ。もちろん正規の経路を通すべきで、大部分は kbuild ツリー、一部は別扱い——特に objtool の変更はかなり大きく、objtool の人たちの承認が要る。それほど論争的には見えなかったが、それでも。ともかく、これが全部入ってほしい。ビルド時間は私の積年の不満だ）

要約すると、賛成（ビルド時間は個人的な不満の種）、注文は「正規の経路で」「objtool は担当者の承認を」「Rust の3本は保留」、個別パッチへの提案は「アセンブリ経由をやめてオブジェクトを直接書け」（04・15）と「$(wildcard) の古い仕掛けを見直せるかも」（11）。LLM 生成という事実に対しては「怖かったが、読んだら問題なかった」——コードで判断した、という返信です。

スレッドの現在地

投稿から4日で89通を超えています。要点を時点つきで並べます。

系列がこのまま丸ごと入るわけではなく、バグ修正は先に、明らかに安全なものは順次、大きいものは担当者の承認を経て、不要になったものは落とす——典型的なカーネルのレビュー工程が、LLM が関与したパッチに対してもいつも通りに回っています。

🖥️ 6. 手元で測ってみた — Ubuntu 26.04 の自宅サーバーで

投稿者の3台はいずれも筆者の手元にはない構成です。そこで、26.04.1 への更新を記録した自宅サーバー——2014年の Core i7-4790K、4コア8スレッド——で、同じ base commit に系列を当て、defconfig のフル／インクリメンタル／no-op を before／after それぞれ3回測りました。投稿者は「数回の最良値」ですが、ここでは3回の中央値を主に載せ、最良値も併記します。手順書は AI が書き、実行と記録は人間がやりました（2026年9月12日 19:16〜20:14、約1時間）。

環境

測り方

• 両ツリーで make mrproper → make defconfig のあと、ウォームアップとしてフルビルドを1回（結果に含めない）
• フル：make clean（.config は保持）→ make -j8。3回。熱でクロックが落ちないよう各回の間に60秒あける
• インクリメンタル：投稿者と同じ touch mm/vma.c → make -j8。3回
• no-op：何も変えずに make -j8。3回
• 時間は /usr/bin/time -v の Elapsed。user／system time・CPU 使用率・最大 RSS も同時に記録

結果（defconfig・-j8・3回の中央値、括弧内は最良値）

フルは 6分13.6秒 → 6分04.6秒、インクリメンタルは 22秒 → 12秒、no-op は 3.1秒 → 1.3秒です。3回のばらつきは全種別で1%未満（フル 373.14〜373.62s、インクリメンタル 22.12〜22.32s、no-op 3.10〜3.17s）でした。

同じ defconfig・gcc で並べると、投稿者の M2 MacBook Pro（8コア）はフル 564.0s → 512.4s（−9%）、インクリメンタル 18.6s → 9.9s（−47%）、no-op 5.59s → 1.69s（−70%）です。インクリメンタルの削減率は手元と同じ −47%、no-op は M2 のほうが大きく、フルは手元のほうが小さく出ました（allmodconfig は手元で測っていないので並べません）。

/usr/bin/time -v の内訳も載せます。次の考察は、この表を根拠にしています。

（3回の中央値。CPU 使用率は「user＋system を経過時間で割った値」で、8スレッドが常に埋まっていれば800%）

考察 — 事実と推測を分けて

① フルビルドが −2.4% に留まった理由。 測れた事実は、user time が 2,522s → 2,515s とほとんど変わっていないことです。つまり、コンパイルの仕事量は before と after で同じで、縮んだ約9秒は「並列に走れなかった時間」の削減分です。概算するとこうなります。user＋system の合計は before で約2,766秒、8スレッドが常に埋まっていれば 346秒で終わる計算なのに、実測は 374秒——差の約28秒が「8本埋まっていない時間」、すなわち直列の尾です。after では同じ計算が 345秒に対して 365秒で、差は約20秒。尾が28秒から20秒に縮んだ、という読みです（尾の間もスレッドは完全に空いてはいないので、あくまで概算）。ここからは推測ですが、この機械で defconfig を -j8 で回すと6分のうち5分半以上がコンパイルで、23パッチが削る objtool・modpost・kallsyms・gzip の絶対量は最初から十数秒〜数十秒しかない。コア数が少ないほどフルビルドはコンパイル支配になり、尾を削っても全体はほとんど動かない——§2 で表から読んだとおりの結果です。

② インクリメンタルと no-op は半分前後に。 事実として、インクリメンタルは 22.27s → 11.74s（−47.3%）、no-op は 3.12s → 1.27s（−59.3%）で、投稿者の主張（直列の尾の削減）が、12年前の4コア機でもそのまま出ました。内訳を見ると、インクリメンタルは user time が 30.8s → 20.4s と CPU の仕事量そのものが3分の2に減り、同時に CPU 使用率が 165% → 213% と並列度も上がっています。「無駄な仕事をやめる」と「直列を並列に」の両方が効いた形です。no-op は user time が 11.1s → 5.1s と半分以下、最大 RSS（time -v の Maximum resident set size＝もっとも大きかった1プロセス）は約64MB → 約31MB でした。手元では工程別の時間は取っていないので、§1 の ASCII 図のように「objtool が何秒、modpost が何秒」と分解することはできません。ただ、no-op でやることはほぼ make が依存関係を読み直す処理なので（§1 の図でも before の no-op はほとんど m）、パッチ10・11（依存確認を C の depcheck に）の効果と符合する——これは推測です。

③ allmodconfig の −36% は、defconfig では出ない。 これは推測です。allmodconfig は1万個超のモジュールを作る構成で、modpost・*.mod.c のコンパイル・srcversion の計算は、モジュール数に比例して尾を長くします。投稿者の EPYC で allmodconfig の no-op が 25.92s もかかっていたのは、この尾の長さです。defconfig はモジュールにされるものが少ないので、削れる尾もそのぶん短い。手元で allmodconfig を測っていないため、§2 の表と各パッチの説明からの見立てにとどめます。

④ 常駐コンテナの影響は見えなかった。 事実として、Docker コンテナを止めずに測っても3回のばらつきは1%未満で、各回の開始時の load average（1分平均）は、直前のウォームアップの余韻が残るフル1回目（6.3・8.3）を除いて 1.7〜3.9 の範囲でした。フルの各回の間に置いた60秒の待ちで、2回目以降は 2〜3 まで落ちています。中央値と最良値の差もすべて 0.5s 以内なので、この条件では常駐サービスは結果に効いていないと見てよさそうです。

⑤ pigz は after だけで有効。 事実として、pigz 2.8 を入れた状態で測っているので、after ではパッチ23がそれを自動的に使い、before はパッチがないので gzip のままです。これは投稿者が示した条件（全効果を見るには pigz を入れておく）どおりで、after の数字には pigz の分が含まれています。pigz 単体の寄与（KGZIP=gzip で after を測り直す）は切り分けていません。

まとめ

投稿者は mm サブシステムで AI 由来パッチの流入を受ける側のメンテナで、「人に言っていること（監査しろ、直せ、理解しろ、明記しろ）を自分にも当てはめた」と書いています。前回の記事で見た「洪水」と、今回の「大物パッチ」は、道具が同じで握り方が違うだけです。そして Linus の返信が示したのは、コミュニティがそれを「AI が書いたかどうか」ではなく「読んでひどいかどうか」で判断した、ということでした。

よくある質問（FAQ）

Q. このパッチを当てれば、自分のカーネルビルドも36%速くなりますか？

36%は「2ソケット EPYC 9754（512スレッド）・gcc・allmodconfig のフルビルド」での投稿者の計測値です。効くのはコンパイル以外の直列部分なので、コア数が少ない機械ほどフルビルドの効きは小さくなります（投稿者の8コア M2 で −8〜9%、第三者の追試で −11〜13%）。一方、インクリメンタルと no-op は直列部分が大半なので、機械の大小によらず大きく縮みます（M2 で no-op −70〜74%）。当サイトの4コア8スレッド機（defconfig）でも、フルは −2.4% にとどまる一方、インクリメンタル −47%、no-op −59% でした（§6）。また、pigz を入れていないと圧縮の分は効きません。

Q. もう Linux に入っているのですか？

いいえ（2026年9月12日時点）。系列はレビュー中で、v2 が予告されています。先行して、系列の前提になるバグ修正2本（01・02）だけが kbuild ツリーの kbuild-fixes-unstable ブランチに取り込まれました。Rust 関連の3本は保留、srcversion 関連の2本は v2 で除外される見込みです。マージされればこの記事に追記します。

Q. どの LLM を使ったのですか？

カバーレターにもコミットメッセージにも書かれていません。タグは Assisted-by: LLM のみで、これは公式ドキュメントが定める Assisted-by: LLM [TOOL1] [TOOL2] の書式に沿ったものです。公式ドキュメントはモデル名の明記を要求していません。本記事も推測で補いません。

Q. LLM が書いたコードがそのままカーネルに入るのですか？

カバーレターによれば、そうではありません。LLM が生成したコードの「多くは hideous」で、投稿者が「徹底的に監査し、多くを書き直し」、コミットメッセージ・コメントも大幅に編集し、ビルドと実機起動で正しさを手作業で確認したと書いています。公式ポリシーでも、AI は Signed-off-by を付けられず、人間の提出者がすべてをレビューし全責任を負うと定められています。Linus の返信も「醜悪な部分は明らかに切除されている」と、人の手が入った後のコードを評価しています。

Q. 出力が変わってしまう心配はないのですか？

各パッチのコミットメッセージが「変わらないこと」を個別に示しています。mksysmap の C 再実装では System.map がバイト単位で同一、*.mod.S 化ではモジュールの各セクションとリロケーションが8,135モジュールでバイト単位で同一、objtool の変更では出力がバイト単位で同一、pigz は同じツール同士なら再現可能（gzip と pigz の混在は不可、と文書に追記）。これらは投稿者の検証であり、レビューでさらに確認が進んでいる段階です。

Q. 2週間前の「AI パッチ洪水」の記事と、どう違うのですか？

道具は同じ LLM ですが、握り方が違います。洪水側の問題は、生成コストが投稿者に、検証コストがメンテナに乗る非対称性でした。今回は投稿者自身が監査・書き直し・実機検証・帰属明記をすべて引き受け、レビュー側の Linus は「読んだらひどくなかった」とコードで判断しています。投稿者は mm サブシステムで洪水を受ける側のメンテナでもあり、「人に課している条件を自分にも当てはめた」と明言しています。

Q. 自分のマシンで試すには？

カバーレターの base-commit: 28924df2a08f440c73991b83028032c901de2ae4（メインライン 7.3-rc2 直後）にチェックアウトし、b4 am（Ubuntu 26.04 なら apt install b4）で系列を取り込んで git am します。全効果を見るには pigz を入れておくこと。手順と手元の実測結果（4コア8スレッド機・defconfig でインクリメンタル −47%、no-op −59%、フル −2.4%）は §6 に載せています。マージ前の系列なので、常用のカーネルではなく試験用のツリーで試してください。

関連記事

• Linuxカーネルの『AIパッチ洪水』｜CVE 2,000件の正体とメンテナの適応：同じ道具の「洪水」側。本記事はその対になる肯定側の実例
• Linux 7.2の誤解を解く｜RISC-V 256コアと「AI支援コミット」の現在地：Assisted-by タグと「AI は Signed-off-by を付けられない」ポリシーの成り立ち
• Ubuntu 26.04.1 更新の実録｜Docker 20コンテナを止めずに2分で完了：§6 の実測に使う自宅サーバーの環境

参考

• [PATCH 00/23] kbuild: significantly speed up kernel builds（Lorenzo Stoakes (ARM)・lore.kernel.org・2026年9月8日）
• [PATCH 08/23] kallsyms: reimplement mksysmap in C
• [PATCH 11/23] kbuild: implement and use depcheck to check dependency timestamps
• [PATCH 15/23] modpost: emit module descriptors as assembly
• [PATCH 17/23] modpost: perform srcversion hashing in parallel
• [PATCH 18/23] objtool: cache relocations and function dead end state, do less work
• [PATCH 23/23] kbuild: use pigz for gzip compression if available
• Re: [PATCH 00/23]（Linus Torvalds・2026年9月9日）
• Re: [PATCH 04/23]（Linus Torvalds・2026年9月9日）
• Re: [PATCH 15/23]（Linus Torvalds・2026年9月9日）
• Re: [PATCH 11/23]（Linus Torvalds・2026年9月9日）
• Re: [PATCH 00/23]（Lorenzo Stoakes (ARM) → Nathan Chancellor・2026年9月11日）
• Re: [PATCH 00/23]（Nathan Chancellor・2026年9月12日・追試結果）
• Re: [PATCH 01/23]（Nicolas Schier・kbuild-fixes-unstable への適用通知・2026年9月10日）
• AI Coding Assistants（The Linux Kernel documentation・公式）
• Kernel Guidelines for Tool-Generated Content（The Linux Kernel documentation・公式）
• AI Made A Lot Of “Hideous” Code But Found Major Bottlenecks For Faster Linux Compilation（Phoronix・2026年9月8日）
• Accelerating the kernel’s build process（LWN.net・2026年9月11日・購読者限定）