Linux Kbuild v4 Patches Cut EPYC Kernel Builds to 15 Seconds

Lorenzo Stoakes' v4 Kbuild Series Cuts an EPYC 9575F defconfig Build From 22 to 15 Seconds​

Phoronix founder Michael Larabel ran the test on two AMD EPYC 9575F processors. Each has 64 cores and 128 threads, boosts up to 5.0GHz, reaches 4.5GHz on all cores, and carries 256MB of L3 cache. The server had 24 × 64GB of DDR5-6400 memory and a Samsung PM1743 3.84TB PCIe Gen 5.0 NVMe SSD formatted as EXT4, running an otherwise stock install of Ubuntu 26.04 LTS. Larabel says he didn't build the kernel in a RAM-backed TMPFS or use other aggressive tricks to lower the time.

He ran the CPUs at their default settings and again in AMD's power determinism mode, a firmware setting he used to squeeze out slightly more performance. The best result, 15 seconds, came with the patches applied and power determinism on. Across the patched runs, times were 15 to 17 seconds, compared with 22 seconds before the patches. That's roughly a one-third cut on hardware that was already the fastest defconfig setup Phoronix has tested. Larabel says this dual 9575F setup usually lands around 20 seconds in his kernel-build benchmarks, and he recalls AMD's EPYC Milan generation as the first to beat 30 seconds.

The bigger allmodconfig target, which builds every kernel module relevant to x86_64, also improved. Larabel says the patches cut more than 30 seconds, putting high-end server builds near the two-minute mark. He didn't publish the exact before-and-after allmodconfig times for the 9575F machine, so the cover-letter numbers below are the best detailed reference.

These are Phoronix's measurements on one machine, and WindowsForum hasn't reproduced them. They are consistent with Stoakes's own figures, though. His v4 cover letter reports a dual-socket EPYC 9754 system dropping from 28.7 to 20.6 seconds for a GCC defconfig build, a 28% reduction, close to the roughly one-third Phoronix measured on different EPYC silicon.

Why Kbuild's Serial Tail, Not the Compiler, Was the Bottleneck​

A kernel build isn't one big parallel job. Thousands of C files compile in parallel under make -j, but around that parallel phase sit steps that run on one core while the rest wait: generating symbol tables, linking vmlinux, post-processing modules, running verification tools, and compressing the final image. The cover letter opens with that diagnosis, saying a typical build spends "a frustratingly large amount of time" stuck in single-threaded bottlenecks. One summary of the series put it this way: the measured result is a build that spends far less time waiting on one CPU core while the rest sit idle.

This is why adding cores stopped helping. Larabel notes that Lorenzo with the assistance of AI/LLMs took to addressing many bottlenecks in the Kbuild code that were reducing the parallel potential of the kernel build process. He adds a hardware point: until compilers can split the compilation of a single source file across cores, the highest core counts aren't necessarily best for build servers. GCC has seen some work on that over the years, but none has shipped.

The practical result is that build time on a many-core machine depends heavily on how long the serial stretches take. A 256-core server that spends several seconds running one-threaded link-time tools is waiting on one core's clock speed. That helps explain why a frequency-optimized part like the 9575F beats higher-core-count chips on this benchmark, and why cutting serial work helps across very different machines.

Inside the 22 Patches: kallsyms, modpost, objtool and pigz​

The v4 series, "kbuild: significantly speed up kernel builds," has 22 patches touching 53 files, with about 3,100 lines added and 890 removed. It changes Kbuild (the kernel's Makefile-based build system) and several helper programs that run during every build. Stoakes says the series works by parallelizing single-threaded tasks where possible and making the build tools themselves more efficient. The patches fall into these groups:

• The kallsyms changes index symbols by token to speed up table compression, write binary output, and read the ELF symbol table directly instead of parsing output from nm. The old mksysmap shell script, which produces System.map, is rewritten in C.
• Kbuild stops sorting nm output where order doesn't matter and only includes vmlinux relocations when the architecture needs them.
• A new C helper called depcheck checks dependency timestamps more efficiently. Object state is now calculated per object.
• Compiler and linker option probes run once at the top of the build instead of repeatedly, and toolchain checks move into a new scripts/Kconfig.toolchain file.
• modpost caches section relocation-mismatch state and writes module descriptors as assembly (*.mod.S) instead of C (*.mod.c). Stoakes says this cuts the CPU time for that task by a factor of ten. Module finalization is batched instead of launching tens of thousands of tiny jobs.
• objtool stops hashing DWARF relocations, replaces its relocation hash with a per-section index, sizes its instruction hash to the actual code, and decodes instructions and resolves branch targets across multiple threads.
• Rust crates build in parallel with the C code, while still requiring that the rust/ crates are built first.
• The kernel is compressed with pigz, a parallel gzip implementation, when it's installed. Starting with v3, pigz uses make's job server through a new KPGZIP build variable.

Stoakes says he deliberately left out "very invasive" changes such as large-scale C header rework, along with changes that would bring diminishing returns. So this is a cleanup of the existing pipeline, not a redesign of how the kernel is structured.

Each patch's commit message carries its own measurements. One early kallsyms patch, on a 128-thread Threadripper 9980X, cut a defconfig incremental build after touching mm/vma.c from 10.8s to 9.9s with GCC. That's a small step, and the headline numbers come from many steps like it adding up.

Incremental and No-Op Builds Are Where the Kbuild Patches Shine Brightest​

The clean-build number gets the headlines, but most kernel developers spend their day editing a file and rebuilding. An incremental build recompiles only what changed. A no-op build runs make when nothing changed at all. The serial tail makes up a much bigger share of those short runs, so removing it has a much larger relative effect. The v4 cover letter reports up to 36% faster allmodconfig builds, about 70% faster incremental builds, and about 90% faster no-op builds. Those are maximums from the tested setups, not typical results.

Stoakes tested on three machines: an AMD Threadripper 9980X (64 cores, 128 threads), a dual-socket AMD EPYC 9754 (256 cores, 512 threads), and a 2022 Apple M2 MacBook Pro with four performance and four efficiency cores. Times are best of several runs.

The M2 rows show both sides of the story. A clean defconfig build on the laptop gains only 8 to 9%, because an eight-core machine spends most of its time actually compiling, which the patches don't speed up. But an incremental rebuild on the same laptop drops by about half, and a no-op run by about three-quarters. For someone iterating on a driver on modest hardware, the edit-compile-test loop is where the time savings add up. Clang LLVM contributor Nick Desaulniers made the same point on the mailing list, saying that particularly exciting are the speed ups to the usual edit+compile+run loop. Stoakes replied that he hadn't expected that result.

The figures depend on a specific setup. They're based on commit 36d4a11b56aa in the Kbuild tree, with three prerequisite patch series applied (module-version cleanup, Josh Poimboeuf's objtool noreturn work, and Kees Cook's cc-option-str series), pigz installed, and the build run as make KRUSTFLAGS=-Zthreads=8 -j $(nproc). Stoakes says those dependencies will all be in place when the series is merged. For now, anyone reproducing the numbers needs the same stack.

The 10-Second defconfig Build Is Still a Bet on EPYC 9686F Venice​

The "approaching 10 seconds" in the headline is Larabel's prediction, and he presents it that way. On software alone, the 9575F system reached 15 seconds. Getting to 10 would take new hardware. He points to AMD's upcoming EPYC 9686F, a high-frequency part from the Zen 6 "Venice" generation that AMD lists at 96 cores, a 5.0GHz boost clock, and 384MB of L3 cache. Larabel wonders whether that chip, paired with MRDIMM-12800 memory and PCIe Gen 6 storage, can break 10 seconds for a default Linux 7.4 or later build.

None of that hardware was part of the 15-second result. The tested machine used Zen 5 EPYC 9575F chips, DDR5-6400, and a Gen 5 SSD. How much a next-generation CPU helps is unknown until someone runs it. The more useful point for buyers is Larabel's argument that per-core speed and cache matter more than raw core count for this workload. The Kbuild series makes that effect stronger, because it shortens the serial stretches where clock speed decides everything.

The kernel keeps growing too. Larabel notes the source tree is nearly 41 million lines, and build times have kept falling anyway, thanks to faster CPUs and now a build system that makes better use of them.

An LLM-Assisted Patch Series Under Kernel Review for Linux 7.4​

The series moved quickly. Stoakes posted a 23-patch v1 on September 8, 2026, v2 on September 14, v3 around September 17–18, and the 22-patch v4 on September 23. Each round incorporated review from Kbuild maintainer Nathan Chancellor, Nicolas Schier, Kees Cook, Josh Poimboeuf, Petr Pavlu, Miguel Ojeda, the kernel test robot, and others. The v4 changelog includes fixing broken M2 figures in the cover letter "as per Linus," meaning Linus Torvalds read the numbers closely. Larabel reports that some patches have already been picked up into kbuild-for-next, and the cover letter mentions a kbuild-next-speedups branch staged by Chancellor.

The Linux 7.4 target is a prospect, not a confirmed merge. Phoronix says the work "may land" in 7.4, and independent coverage describes it as now aimed at Linux 7.4. Until Linus merges the full series in a merge window, it remains pending work.

The development method got as much attention as the results. Stoakes says an LLM first found the bottlenecks and then proposed fixes. As an earlier summary of v1 put it, Stoakes used an LLM to identify bottlenecks and generate initial code, describing much of the generated code as 'hideous' and requiring extensive manual auditing and rewriting. He says he audited and rewrote much of it, checked correctness by hand in both builds and running kernels, and verified the performance numbers himself. Every commit carries an Assisted-by tag. The changelogs also show him working through reports from Sashiko, an AI code-review tool. He calls many of its findings hallucinated but fixed the real ones, including races in the multithreaded objtool code that a thread sanitizer also flagged.

Testing, as reported by Stoakes, goes beyond x86. allmodconfig built for arm64, arm, RISC-V, PowerPC64, s390, and LoongArch. On arm64, arm, s390, and LoongArch, the C mksysmap produces a System.map identical to the old shell script's. Kernels for nine architectures booted under QEMU with module load and unload working. External modules built against both in-tree and O= builds. Parisc64 and m68k build testing hit errors he attributes to unrelated mainline problems. These are the author's claims; ongoing review is the independent check.

What this means for you​

If you build kernels regularly, the decision is whether to test the v4 series now or wait for it in a mainline release. Most people should wait. Developers who spend their day in incremental rebuilds, bisecting regressions, or running kernel CI have the most to gain and are the best testers to find problems before merge.

• The Phoronix result is 15 to 17 seconds for a clean x86_64 defconfig build on dual EPYC 9575F with the v4 patches, down from 22 seconds. The 10-second figure is a forecast tied to unreleased hardware.
• The largest relative gains are in incremental builds (roughly 45–66% in the cover letter) and no-op builds (up to 95%). Clean builds on an eight-core laptop improved only 8 to 9%.
• Installing pigz now is harmless. The series uses it automatically for parallel kernel compression when available, through the new KPGZIP variable, and the published numbers assume it's installed.
• To reproduce Stoakes's numbers before merge, you need Kbuild commit 36d4a11b56aa, the three prerequisite series, and KRUSTFLAGS=-Zthreads=8. Without that stack, results will differ.
• When choosing build-server CPUs, favor high clock speeds and large caches over maximum core count, since serial steps and per-file compilation still limit scaling.
• Treat the series as pending until it shows up in a Linux 7.4 merge window pull. Distribution kernels and CI images won't include it until then.

Faster kernel builds used to come mostly from new CPUs. This round came from fixing the build tooling, and that benefits everyone from 512-thread servers to an M2 MacBook. The next milestone is the Linux 7.4 merge window. If the series lands intact, the faster incremental rebuilds will reach every kernel developer without a hardware upgrade.