The Kernel Build Got 36% Faster. On a Small Arm Machine It Is 1%.

Lorenzo Stoakes posted the kernel build speedup work as “kbuild: significantly speed up kernel builds” on 8 September 2026 with 23 patches; a second version of 21 followed on 14 September and a third of 20 on 17 September. Linus Torvalds replied to the first with “Well, that’s certainly very encouraging. We should do this.” It is under review by the kbuild maintainer, Kees Cook, Nathan Chancellor, Nick Desaulniers, Miguel Ojeda and Arnd Bergmann, is not in mainline or linux-next as of 18 September 2026, and 7.4 is the cycle being discussed.

Every number below is the author’s, taken from the v3 cover letter; we have not reproduced any. They are unchanged from v2, so the revisions have been about review feedback, not about the performance claims moving.

What the kernel build speedup headline is measuring

The cover letter’s summary is that the series makes allmodconfig builds up to 36% faster, incremental builds up to around 70% faster, and no-op builds up to around 90% faster. The 36% is the best case from the best machine on the largest configuration: a two-socket EPYC 9754 with 256 cores, building allmodconfig with gcc, going from 188.0s to 121.1s.

Two things about that do not transfer to embedded work. Nobody ships allmodconfig, and few teams cross-compile on a 256-core machine. The row to read instead is defconfig on the smallest machine in the author’s set, a 2022 M2 MacBook Pro with 8 cores.

A one percent improvement is within the noise of most measurement practice. A 74% improvement is not.

Why the two ends differ so much

A full build on a core-starved machine is dominated by compiling source files, and this series does not make the compiler faster. What it removes is work that is serial, repeated, or unnecessary.

The patch subjects say it plainly. kbuild: avoid re-running compiler and linker probes removes probes that ran on every invocation. kbuild: implement and use depcheck to check dependency timestamps replaces a slow dependency check. modpost: emit module descriptors as assembly replaces generated C with assembly, which the cover letter says cuts the CPU seconds for that task by a factor of ten.

On a large machine that serial work is a small fraction of an otherwise well-parallelised build. On a no-op build it is the entire build. That is why the no-op case improves most on every machine tested, and why the benefit scales with how often you rebuild rather than how big your machine is.

The author also reports that ld -r of vmlinux.o followed by modpost and objtool — which block the rest of the build — fell from 23 seconds to 7 for allmodconfig on the Threadripper. That serial section is the part no amount of -j helps with, and it is proportionally worse on machines with fewer cores.

What this means for an embedded workflow

If your build is a clean cross-compile in CI from an empty sstate or object directory, expect very little. The 1% row is your row. Independent figures agree: Nathan Chancellor measured 13.22% on an 80-core Ampere Altra and 11.7% on a 32-core AMD system, Florian Fainelli around 13% on an EPYC 9454P. Real, useful, not transformative.

If your build is an engineer changing one driver file and rebuilding, expect the 45% to 76% range, and expect to feel it, because that loop runs dozens of times a day.

The way to benefit is to stop throwing away your incremental state. A Yocto do_compile starting from a clean work directory, a CI job that does not restore its object cache, a container that rebuilds from scratch on every commit: each converts the 45% case into the 1% case. That is a pipeline decision, and it is worth more than the patch series itself.

raghu@techveda.org:~$ make ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- defconfig
raghu@techveda.org:~$ time make ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- -j"$(nproc)"
raghu@techveda.org:~$ time make ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- -j"$(nproc)"
raghu@techveda.org:~$ touch drivers/tty/serial/8250/8250_port.c
raghu@techveda.org:~$ time make ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- -j"$(nproc)"

The second run is your no-op time, the fourth your incremental time. If both are already small because you rebuild from scratch every time, the reason is your pipeline rather than the kernel.

The cross-architecture testing is the reassuring part

A build-system change touching kallsyms, modpost, objtool and mksysmap is the kind of work that breaks quietly on architectures nobody runs in CI, so the v3 testing section is the most relevant part of the cover letter for an embedded reader. Beyond x86, allmodconfig was built for arm64, arm, riscv, powerpc64, s390 and loongarch. For arm64, arm, s390 and loongarch the resulting System.map is identical to what the previous shell mksysmap produced for the same vmlinux. Kernels for nine architectures boot under qemu, with every text symbol present in /proc/kallsyms at the relocated address, and a module loading and unloading.

The identical-System.map check is the specific evidence worth having, because a silently different symbol table would ruin your next crash dump rather than your next build.

Caveats worth carrying

The figures are not from a stock tree. The cover letter states they require two other patch series applied, make KRUSTFLAGS=-Zthreads=8, and pigz installed locally. That last comes from patch 20, which compresses the kernel with a parallel gzip where available, and was the most argued-over patch in the thread.

The series is still moving, from 23 patches to 21 to 20. The v3 notes record that the rustc front-end threading patch was dropped because the parallel flag name is still uncertain upstream, and that setting KRUSTFLAGS=-Zthreads=8 gets the same behaviour without it. Several patches drew objections, including from Kees Cook on whether the added complexity is justified. Expect per-patch references to move again.

The author states that a large language model was used to find the bottlenecks and draft the changes, that it produced a lot of code he calls hideous, that he audited and rewrote much of it, and that each commit carries an Assisted-by tag. Much of the secondary coverage has focused on that. The more useful observation is that the bottlenecks were serial work nobody had measured, and were there for anyone who looked.

Key takeaways

• The 36% headline is an EPYC allmodconfig figure. On an 8-core arm64 machine, a full defconfig gcc build improves by 1%.
• The same small machine improves 45% on incremental builds and 74% on no-op builds.
• The series removes serial and repeated work, not compilation, so the benefit tracks how often you rebuild rather than how large your machine is. Pipelines that discard incremental state convert the large win into the small one.
• Cross-architecture testing is thorough: arm64, arm, riscv, powerpc64, s390 and loongarch all build, and nine architectures boot under qemu with the symbol table verified.
• Nothing is merged. The series reached v3 on 17 September 2026, is still under review as of 18 September, and 7.4 is the cycle being discussed.

Frequently asked questions

Will my Yocto build get 36% faster?
Almost certainly not. The 36% is an allmodconfig build on a 256-core server. A cross-compile from a clean work directory is closest to the full-build rows, where the small arm64 machine gained 1% with gcc and 10% with clang.

Which kernel version will include this?
None yet. As of 18 September 2026 the series is at v3 and is not in mainline or linux-next, and 7.4 is the cycle under discussion.

Do I need pigz and the Rust thread setting to see any benefit?
Those are conditions the author’s v3 measurements were taken under, along with two prerequisite series. Without them your results will differ from the published table, which is reason to measure your own build.

Why does the no-op build improve so much more than the full build?
A no-op build consists almost entirely of the dependency checks, probes and repeated state computation that this series removes. A full build is dominated by compiling source files, which the series does not change.

Further reading

• The v3 cover letter, benchmark tables and testing notes, 17 September 2026
• The original 23-patch series, 8 September 2026
• Phoronix, 14 September 2026: Linux 7.4 Could End Up Seeing Kernel Builds ~36% Faster
• LWN, 11 September 2026: Accelerating the kernel’s build process

Getting a reproducible, incremental cross-build pipeline working properly is part of our Embedded Linux and Yocto training.

— Raghu Bharadwaj