Lorenzo Stoakes' Kbuild patches bring a clean Linux kernel build down to 15 seconds

Larabel ran both builds on the same dual EPYC 9575F machine, so nothing changed on the hardware side ^[1]. The cut works out to about 32% of build time, a speedup of about 1.47x ^[17].

His article opens with "The coffee window is closing." ^[8] The 10-second part is a bet. "Though with next-gen processors I am betting on 10 seconds," Larabel wrote ^[5]. According to Tom's Hardware, the bet is on AMD's Zen 6 EPYC 9686F with MRDIMMs and PCIe Gen6 storage ^[6]. Larabel lists that chip as coming up, with a 5.0GHz boost clock and 384MB of L3 cache ^[10]. For a sense of how slowly hardware moved this number before, he recalled the EPYC Milan review "finally breaking the 30 second mark" ^[16]. On this evidence, Kbuild work got the build to 15 seconds. The remaining five seconds depend on a chip that has not shipped.

Stoakes went after bottlenecks in the Kbuild code "that were reducing the parallel potential of the kernel build process," Larabel wrote ^[4]. With 256 threads available ^[2], any stretch where the build has no work to hand out leaves most of the machine idle. The shorter the build, the larger the share of wall time those stretches take. The compiler sets the other limit. "At least until compilers achieve parallelizing compilation of individual source files, the very highest core counts aren't necessarily the best for build servers," Larabel wrote ^[14]. Earlier GCC work on compiling a single file in parallel has still not landed, years later ^[15].

The absolute time will not carry over to a CI runner. The test rig had 128 cores, 1,536 GB of DDR5-6400 across 24 modules and a PCIe Gen5 SSD, and it did not use a RAMdisk ^[2][19]. The percentage has a better chance of carrying over. Stoakes' cover-letter result on a dual EPYC 9754 is a cut of about 29% ^[20], close to Larabel's figure on different EPYC silicon. Larabel wrote that the changes also cut build times proportionally on processors that are not leading edge ^[21]. Every before-and-after timing in these reports, though, comes from a two-socket EPYC server.

Relative gains shrink as the build grows. The allmodconfig cut is about 21% ^[18], against about 32% for defconfig ^[17]. That pattern fits a fixed Kbuild overhead spread over far more compilation. Larabel names bisecting kernel regressions as one use for fast clean builds ^[9]. For bisects, and for CI that rebuilds after small changes, the closer match is Phoronix's figure of around 70% faster incremental builds ^[12].

Phoronix's first report on the work said the AI produced a lot of hideous code but found major bottlenecks holding back Linux compilation speed ^[7]. I think that is a sound way to divide build-system work: the model locates the stalls, and the mailing list decides which code survives. Stoakes has since taken the series through four posted versions ^[11].