Re: [PATCH 00/23] kbuild: significantly speed up kernel builds

[Lorenzo Stoakes (ARM)]

On Wed, Sep 09, 2026 at 08:37:10AM -0700, Linus Torvalds wrote:
> On Tue, 8 Sept 2026 at 13:55, Lorenzo Stoakes (ARM) <ljs@xxxxxxxxxx> wrote:
> >
> > A typical kernel build consists of a frustratingly large amount of time
>
> .. you're preaching to the choir.

:) Yeah, it's something that's annoyed me for a long time too.

>
> >                 == allmodconfig FULL build ==
> >
> >                         before    after     delta
> >                       ----------------------------------
> > Threadripper, gcc       345.3s   275.2s    -70.1s (-20%)
>
> Well, that's certainly very encouraging. We should do this. I sent out
> some emails as just reactions to individual patches, but I have no
> numbers to back any of those emails up, and I never actually applied
> this series to my tree - they were all based on reading the patches
> themselves.

Thanks, will have a read through those!

I do recommend trying them locally ;)

It makes a surprising difference to defconfig even. (Though you need pigz
installed for the full effect)

>
> That said:
>
> > An LLM was used to first determine where the bottlenecks were then to
> > figure out how to improve them.
> >
> > It generated a lot of code, much of it hideous.
>
> This made me scared to look at the patches originally, and I held off
> in fear that the patches would be horrible and this build time
> improvement would be hugely controversial garbage code.
>
> But:
>
> > I extensively audited and rewrote a lot of it, and heavily edited commit
> > messages, the cover letter and comments.
>
> None of the patches look at all horrible to me. You clearly excised
> the hideous parts. All of my reactions were of the type "this could
> probably be taken _further_" rather than me throwing my hands up in
> disgust.

Thanks! :)

I made sure to audit everything it came up with patch-by-patch, got it to
rework the horrors then rewrote large chunks of what it came up with.

>
> So the Rust parallelism thing clearly isn't ready based on feedback
> from that quarter, but the rest looked safe and innocuous. I'm all for

Sure, happy to drop anything like that.

Though based on what Miguel said it _might_ be ok perhaps with a nightly
gate on it? Will see what he/Bjorn say.

> merging this, although it should obviously go in through the right
> channels. Mostly the kbuild tree, although some of it clearly would be
> other cases - the objtool change in particular is fairly substantial
> and needsobjtool people to approve. It didn't look all that
> contentious, but still..

Agreed, it definitely needs some eyes on it, especially the trickier bits.

>
> Anyway, I'd love for this all to go in. Build times are a pet peeve of mine.

Yeah, it'd be nice to see this benefit everyone!

Am happy to iterate on it as needed to get it upstream.

>
>               Linus

--
Cheers, Lorenzo