AI Helped Find Kernel Build Bottlenecks. The Code It Wrote Was 'Hideous'

Finally, Someone Points AI at the Boring Part of the Kernel

Every kernel developer I know has the same complaint: `make -j$(nproc)` eats your CPU cores beautifully until it hits a handful of single-threaded chokepoints, and then your 32-core Threadripper sits there twiddling its thumbs waiting on one core to finish something it should have parallelized a decade ago. Lorenzo Stoakes at Arm decided to actually do something about it, and he used an LLM to help find where those chokepoints live. The second revision of his patch series landed on the mailing list this week, and if it lands in Linux 7.4, allmodconfig builds get up to 36% faster, incremental builds up to 70% faster, and noop builds (the ones where you've changed nothing and the build system still has to figure that out) up to 90% faster.

That last number is the one that should make every kernel hacker sit up. A noop build should be nearly instant. If yours currently takes several seconds to tell you it has nothing to do, that's dead time multiplied by every single edit-compile-test cycle you run in a day. Multiply that across the entire kernel developer community and you start to understand why Stoakes bothered.

What AI Is Actually Good At Here

Let's be precise about what happened, because the headlines are going to oversimplify it. Stoakes didn't ask an LLM to "optimize the kernel build system" and ship whatever came out. He used it as a profiling assistant, pointing it at the build pipeline to help identify which single-threaded steps were the real bottlenecks. That's the part LLMs are genuinely decent at: chewing through build logs, Makefile dependency graphs, and Kconfig processing paths faster than a human staring at a flamegraph at 2 AM. Finding the bottleneck is a search problem, and search problems are exactly where these models earn their keep.

What came out the other end, by Stoakes' own account, was not something you'd want anywhere near mainline. He said the LLM "generated a lot of code, much of it hideous," and that he "extensively audited and rewrote a lot of it," on top of rewriting the commit messages, the cover letter, and the comments by hand. In other words: the AI found the problem, and a human kernel engineer did essentially the entire job of actually fixing it properly. If you were hoping this is the story where AI starts writing production kernel code unsupervised, it isn't. It's the story where AI is a decent research assistant with terrible taste in patches.

The Fixes Themselves

The series includes rebasing against the latest upstream tree and, notably, making the Rust compiler's parallel front-end optional rather than mandatory in the build path. That detail matters more than it looks. Rust-for-Linux keeps expanding its footprint (see the inline helper work that landed for 7.1), and every new mandatory dependency in the build pipeline is another place a single slow step can stall the whole thing while sixty other cores idle. Making that front-end optional where it isn't needed is a small, sensible fix, and it's the kind of change that's easy to review precisely because it does one obvious thing instead of trying to be clever.

Stoakes describes the overall patch set as "largely uncontroversial," which in kernel mailing list terms is about as close to a guarantee of merge as you're going to get before Linus actually pulls it. Two of the original patches are already in, and he's optimistic about the rest landing in time for the 7.4 merge window.

Why This Actually Matters Outside Arm's Build Farm

If you're running a stock distro kernel and rebooting twice a year, none of this touches your life directly. But if you're the kind of person compiling your own kernel, tracking `-git` branches, or running something like CachyOS or a source-based setup where you rebuild constantly to test patches, chase a regression, or just because you like living dangerously, a 70% cut in incremental build time is not a rounding error. It's the difference between testing five patches in an afternoon and testing fifteen. I use Arch, btw, and I rebuild kernels more often than I'd like to admit when chasing a driver regression; shaving minutes off every iteration adds up to hours across a bad week.

There's a broader point here too, and it's one kernel maintainers have been circling for a while: LLMs are getting genuinely useful at bug-hunting and bottleneck identification in codebases too large for any one person to hold in their head, while remaining unreliable as unsupervised code generators. That's not a knock on the technology, it's just where it currently sits. The Stoakes patches are a decent template for how that split should work in practice: let the model point at the haystack, keep a human doing the actual needle-shaping. Anyone pitching "AI wrote our kernel patches" without that second half should be treated with the same suspicion as anyone who tells you they got 200 FPS on a stock cooler.