An Arm engineer just made the Linux kernel build itself much faster

A patch series working its way through the Linux kernel mailing list promises to cut kernel build times by a margin that kernel developers have wanted for years. Posted by Arm engineer Lorenzo Stoakes, the 23-patch kbuild series makes allmodconfig builds up to 36% faster, incremental builds around 70% faster and no-op builds \u2014 where nothing has changed and the build system is simply checking \u2014 up to about 90% faster.

The series was first posted on 8 September and is now in its third revision. As Phoronix reported on 14 September, two of the original patches have already been picked up and merged, and Stoakes says the remaining changes are largely uncontroversial, which puts them in contention for the next kernel cycle, Linux 7.4.

Why building a kernel was slow in the first place

A kernel build is tens of thousands of compile and link steps, and the build system has weathered two decades of growth on top of a skeleton designed for single-threaded make. The consequence is a long tail: a machine with 256 cores spends the end of every build waiting on a handful of steps that can only run one at a time. Stoakes' cover letter puts it plainly, saying \u201ca typical kernel build consists of a frustratingly large amount of time spent stuck in single-threaded bottlenecks\u201d, and that there turns out to be a lot that can be done about it.

The measured gains are large on big hardware. On a dual-socket EPYC 9754 with 256 cores and 512 threads, an allmodconfig build with gcc fell from 188.6 seconds to 121.1 seconds, a 36% cut; an incremental rebuild fell from 82 seconds to 24.3, roughly 70% faster; and a no-op build collapsed from 25.92 seconds to 1.52. On a Threadripper 9980X with 64 cores and 128 threads the same allmodconfig build went from 345.3 to 275.2 seconds, a fifth off, and the incremental build from 46.4 to 15.3 seconds.

Modest hardware gains less. On a 2022 M2 MacBook Pro, a defconfig build with gcc dropped from 564 seconds to 512, an improvement of about 9%. That gap is worth keeping in mind, because it is a fair description of where most kernel contributors actually work.

The bottlenecks were found with AI's help

The part of this that deserves more attention than the percentages is how the work started. According to Phoronix, a number of the single-threaded bottlenecks were tracked down and fixed with the assistance of AI, and the series also cleans up code described in earlier coverage as hideous. That is an unusually tidy answer to the question of what large language models are actually good for in software: not writing a kernel, but reading an enormous, unloved build system closely enough to say where the time goes.

Why anyone outside kernel development should care

Kernel build times are a tax that gets itemised in places most people never see. Every distribution pays it at release time, every Android handset vendor pays it when it patches a board support package, and every cloud provider pays it across continuous-integration fleets where a fifty-second saving multiplied by tens of thousands of jobs a day is real money. Shaving two-thirds off an incremental rebuild also shortens the loop between making a change and knowing whether it broke something, which is the sort of thing that quietly improves how careful a project can afford to be.

Nothing here is merged except the two patches already picked up, so the numbers are a promise rather than a changelog. The next kernel cycle will settle it.

Our opinion

Build times are the cost nobody puts on a slide, and the honest answer to \u201cwhy is the kernel so slow to compile?\u201d has been \u201cbecause the long tail of the build is older than the machines running it\u201d. Stoakes has taken on the least glamorous job in open source \u2014 reading makefiles closely enough to find the serial steps \u2014 and produced gains that are larger than most CPU generations deliver on their own. Two of the patches are already in, which is the strongest signal available that the rest are not marketing.

Do keep the \u201cup to\u201d in view. The 90% headline is a no-op build, which is the least useful measurement on the page, and the biggest wins land on machines with 64 and 256 cores. On an M2 laptop the improvement is around 9%, which is real but will not change anybody's afternoon. The number that should interest a distro or a CI team is the 70% incremental cut, and even that depends on the whole series landing. The case for merging it is still overwhelming, because the code costs nothing to ship and the alternative is another decade of waiting on one core while sixty-three sit idle.