A patch series that speeds up the Linux kernel build reached its third revision on September 18, 2026, and is now aimed at Linux 7.4. Arm engineer Lorenzo Stoakes wrote it after using a large language model to find where the build wastes time. The measured result is a build that spends far less time waiting on one CPU core while the rest sit idle.
The problem the series attacks is stated plainly in the patch series cover letter: a typical kernel build spends a frustrating amount of time stuck in single-threaded bottlenecks. Modern machines have many cores. The kernel build kept handing several of its steps to just one of them.
Where the time went
The work touches the parts of the build most developers never look at. Kbuild is the make-based system that drives everything. Kallsyms builds the table that maps kernel addresses to symbol names. Modpost checks module metadata, objtool validates the generated code, and mksysmap writes the symbol map. The Rust build path was changed too.
Some of the waste was simply volume. The cover letter notes a modern x86-64 kernel holds roughly 158,000 symbols, so a pass over them runs millions of iterations. It also points at 5,810 unnecessary module-info entries for an x86 defconfig build, and 15,200 for arm64. One generated assembly file reached 37 MiB and took 0.57 seconds to assemble, two or three times per build.
The numbers, and how they differ
| Measurement | Before | After |
|---|---|---|
| No-op x86 allmodconfig build | 11.6s | 2.4s |
| No-op x86 allmodconfig build, second config | 11.0s | 1.9s |
| Clean x86 allmodconfig build | 342.1s | 304.5s |
Kallsyms compression with CONFIG_KALLSYMS_ALL
|
0.59s | 0.33s |
Those figures come from the posted series, which carried 23 patches when Stoakes sent it on September 8, 2026. The third revision reported by Phoronix on September 18 carries 20 patches, rebased on current upstream code, with results gathered on AMD EPYC, Threadripper, and Apple M2 machines. Phoronix put the Apple M2 no-op gain at 74 to 76 percent and called the result "in a similar ballpark to the AMD x86_64 numbers."
The headline percentages differ between the two reports. Phoronix's earlier coverage on September 8 described full builds with all modules as about 36% faster, incremental builds up to 70% faster, and no-op builds roughly 90% faster. The series itself reports 79 to 82 percent for no-op builds and 11% for a clean allmodconfig build. The gap reflects different machines, configurations, and revisions, so treat the range as the honest answer rather than any single number. Our coverage of the 9,000-patch stable kernel batch showed the other side of the same tree: a lot of code moving, often.
An LLM found it, a human shipped it
Stoakes has been direct about how the work was produced. "An LLM was used to first determine where the bottlenecks were then to figure out how to improve them," he wrote. His assessment of the output is less flattering: "It generated a lot of code, much of it hideous." He says he audited and rewrote much of it and heavily edited the commit messages, and each commit carries an "Assisted-by" tag naming the assistance.
The series also states that generated output was verified to be byte-for-byte identical to what the old code produced. That is the check that matters for a build system, because a faster build that produces a different kernel is not a faster build.
What this means for developers
If you compile kernels regularly, the no-op case is the one to care about. That is the build you run after changing one file, or after changing nothing at all, and it is where the series claims its largest wins. Those minutes land on every iteration of a debug loop.
Watch the series land rather than applying it now. It targets Linux 7.4, and a rebase on your tree is a better use of time once it is merged. If you maintain CI that builds kernels, note the clean allmodconfig gain is the smaller one at about 11%, so budget expectations by workload.
The process story is worth its own attention. This is a case of machine-suggested optimization passing through human review, byte-for-byte verification, and an explicit tag saying so. That combination is what makes such a patch reviewable at all.
This article was first published on Tech AI Wire.
Also available in
Deutsch · 日本語 · Français · Español · Português
Top comments (0)