Thread (105 messages) flat view 105 messages, 14 authors, 6d ago

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

From: "Lorenzo Stoakes (ARM)" <ljs@kernel.org>
Date: 2026-09-09 16:30:34
Also in: linux-arch, linux-doc, linux-efi, linux-kbuild, linux-riscv, lkml, llvm

On Wed, Sep 09, 2026 at 08:37:10AM -0700, Linus Torvalds wrote:
On Tue, 8 Sept 2026 at 13:55, Lorenzo Stoakes (ARM) [off-list ref] wrote:
quoted
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.
quoted
                == 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:
quoted
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:
quoted
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
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help