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
