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

["Lorenzo Stoakes (ARM)" <ljs@kernel.org>]

On Mon, Sep 14, 2026 at 08:41:39AM -0700, Kees Cook wrote:
> On Mon, Sep 14, 2026 at 10:21:59AM +0100, Lorenzo Stoakes (ARM) wrote:
> > This series makes allmodconfig builds up to 36% faster, ...
>
> This is very nice!

Thanks :)

>
> > incremental builds
> > up to ~70% faster, and noop builds up to ~90% faster.
>
> Some of the changes for this seem to add complexity that I'm not sure
> is balanced against the gain? I am still looking through the series,
> though, maybe I'll change my opinion. ;)

Well, I aggressively stripped all the commits that had a bad RoI on that.

And a lot of these are additive over 21 commits.

So, unfortunately, hacking away at what seem like low cost commits will eat
away at the overall result.

I really did work hard to cut the fat where I could, believe me going
through what remained and a. figuring out what it did, b. rewriting a lot
of the code and c. rewriting commit messages (ahem ;) was NOT fun :)

So I was happy to swing the axe as it saved me in terms of what little
sanity remains ;)

>
> > 		== allmodconfig FULL build ==
>
> Did you try Clang CONFIG_LTO=y builds?

I tried a CONFIG_LTO_CLANG_THIN in order to check that the *.mod.S stuff
worked correctly, all working correctly.

I can try to get some profiling numbers for thin and full if you want?

>
> > 			== LLM usage ==
> > [...]
> > I extensively audited and rewrote a lot of it, and heavily edited commit
> > messages, the cover letter and comments.
>
> I feel like the commit logs still need a lot of work. The LLM verbosity
> problem appears in many of them, for example spending 80% of the commit

Well I rewrote the majority of them, so this is a stinging critique of my
commit message writing I guess :)

> log describing every step of some process as background before getting
> to the actual change. I think a human writing this would be much more
> terse about the background. I have, however, been known to be too terse
> in my own commit logs. :P

I mean no, I did write nearly all of them. So I guess err... yeah :)

The testing results and perf numbers are generated and maybe I missed some
bits but generally this is so.

Anyway, I am known to be critical on-list on occasion, so if you dish it
out you have to take it - if you point out specific commit messages that
need work then I can try to put commit msgs on a diet :)

(N.B. I have had feedback like that on a fair few human-written commit
messages of mine lately so there might be some validity to that ;)

>
> > [...]
> > Nothing too controversial was included. There are further improvements that
> > could be made, but they would either by very invasive (large scale C header
> > changes) or generate diminishing returns.
>
> One area I think might solved via an LLM is the 3-pass kallsyms stuff.
> If we could get a deterministic kallsyms build in 1 pass, that would be
> very nice. A lot of people have tried, but it has eluded upstreaming.

"going from three passes to one would save around 8s on an allmodconfig
build and 2 to 3s on defconfig, out of tails that are currently roughly 25s
and 8s." says the LLM :) so that actually does seem worthwhile.

But I think best as a follow up?

I'd like to land the really low-hanging fruit before maybe digging in to
what else we can cut out :)

>
> -Kees
>
> --
> Kees Cook

--
Cheers, Lorenzo