New Kbuild Patches Cut a Linux Kernel Build to 15 Seconds

A clean Linux kernel build has dropped to about 15 seconds on a very fast dual-socket AMD server. That is the useful headline. The equally important detail is that this was not a typical desktop build, and the result came from a minimal default configuration rather than a kernel containing every available module.

I still find the result impressive. Faster hardware usually gets the attention, but this test shows how much time can be recovered by fixing the build system itself. A 22-patch Kbuild series removes several points where hundreds of CPU threads were waiting instead of compiling code.

The measured improvement

In the original testing, a clean x86-64 defconfig build fell from roughly 22 seconds to 15–17 seconds. With the server set to a performance-focused power profile, the best run reached 15 seconds. That is a reduction of about one-third for a job that was already unusually quick.

The heavier allmodconfig test also improved. It went from 169 seconds to 134 seconds, cutting 35 seconds from a build that enables nearly every kernel option and module available for the architecture. That result matters because it is less dependent on making the source tree small enough to finish in a coffee sip.

For comparison, the basic commands behind this kind of test look familiar:

make defconfig
time make -j"$(nproc)"

defconfig creates a sensible default configuration for the target architecture. -j"$(nproc)" then lets Make schedule as many parallel jobs as the machine reports logical processors. On a modest workstation that might mean 16 or 32 jobs. On this test server, it meant hundreds.

This was a 256-thread build machine

The test system used two AMD EPYC 9575F processors. Together, they provide 128 physical cores and 256 threads. The machine also had 24 64GB DDR5-6400 modules for 1.5TB of memory, plus a 3.84TB Samsung PM1743 PCIe 5.0 NVMe SSD. Ubuntu 26.04 ran from an EXT4 filesystem.

No RAM disk or tmpfs shortcut was used. That is worth calling out because moving the kernel tree into memory can make a storage-heavy benchmark look better than a normal developer setup. The PCIe 5.0 SSD is hardly ordinary, but the files were at least compiled from a real filesystem.

Why Kbuild became the bottleneck

Adding more cores only helps when the build system can keep them fed. Once compilation becomes highly parallel, small serial steps, repeated process launches, dependency checks and synchronization points become visible. A delay that barely registers on an eight-core PC can leave most of a 256-thread server idle.

The new patch series targets those coordination costs. The work was assisted by AI tools during analysis and development, but the patches still have to stand on normal engineering ground: readable changes, reproducible measurements and maintainer review. Some pieces have reached the Kbuild development tree, while the complete series is not yet something every stable distribution ships.

Where developers would notice it

Most developers do not rebuild a clean kernel once and stop. They change a driver, adjust a configuration, run a build, boot or test it, and repeat. The reported work also improved incremental builds, which is more relevant to that daily loop. Even a 20-second saving adds up during a long regression hunt or a git bisect session with dozens of compile-and-test cycles.

It can also improve shared build servers. A continuous-integration machine may compile several architectures and configurations for each patch set. Saving 30 seconds from one job is modest; saving it across hundreds of jobs reduces queue time and power use.

Do not expect 15 seconds on a desktop

I would not use this number to predict a Ryzen desktop build. CPU count, compiler version, kernel configuration, storage, memory bandwidth, thermal limits and the state of the source tree all affect the result. A full-featured distribution kernel also compiles far more code than defconfig.

The widely repeated “10-second kernel” figure is a projection, not a demonstrated result. It assumes newer server platforms with faster memory and storage on top of the Kbuild improvements. The actual achievement today is the measured 22-to-15-second change on extreme hardware, plus the 169-to-134-second result for allmodconfig.

That is still solid work. I care less about whether a future machine crosses an arbitrary 10-second line and more about the patches making existing machines spend less time idle. If the remaining changes survive review and reach a mainline kernel, developers with ordinary PCs should benefit too—even if their stopwatch never shows 15 seconds.

Sources: Tom's Hardware and Phoronix's original benchmark.

Share: