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

[Lorenzo Stoakes (ARM)]

On Tue, Sep 08, 2026 at 02:06:18PM -0700, Nick Desaulniers wrote:
> On Tue, Sep 8, 2026 at 1:55 PM Lorenzo Stoakes (ARM) <ljs at kernel.org> wrote:
> >
> > A typical kernel build consists of a frustratingly large amount of time
> > spent stuck in single-threaded bottlenecks.
> >
> > It turns out that there's a lot we can do about this and doing so
> > significantly impacts kernel build times.
>
>
> > Fundamentally the series improves build times by parallelising
> > single-threaded tasks as much as possible and improving the efficiency of
> > code used in the build process.
>
> Cool!  I have not reviewed this patch series, but am supportive of
> solving the problem, since I do recall this being an issue;

Thanks :)

>
> i.e. it always annoyed me that despite have a 128 core machine, much
> of the build is sequential!  Having all those cores and not saturating
> them during a build was always something I noticed (usually have
> system monitor always showing system load, always) but never had time
> to look into.

Yeah this was exactly the motivation.

I've seen single-threaded stalls endlessly in kernel builds, even on smaller
boxes, and thought that there must be a lot of low-hanging fruit there.

Obviously I have not enough time to do anything extra (TM) so never dug
into it.

Which made it a great candidate for LLM usage (though with a LOT of taming,
reviewing, auditing, rewriting of code because I _still_ have to be able to
maintain my changes and there's still a bar there :)

>
> It would be cool if your LLM could generate any visualizations of
> what's going on during a build? Seeing what's serial vs parallelized
> in perhaps useful. Particularly when you can compare the before vs
> after.

Great idea!

I asked it to do exactly that, attached. Came out quite nice and sums it up
nicely :)

It also provided an ASCII version:

x86 allmodconfig, clang, 128 threads. One character per interval: height = CPU utilisation,
letter beneath = what was running (C compile, L link, O objtool, P modpost, K kallsyms, Z compress, m make, . idle)

== clean build (4s per character) ==
before ▁▁▁▁▁▂█████████████████████████████████████████████████████████▃▁▁▁▁▁▁▁███████████▇▅▁▁  343.6s
       mCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCOOOOPPPCCCCCCCCCCCCCLL
after  ▁▆████████████████████████████████████████████████████████▇▁▁▁▄██▆▁  265.6s
       CCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCOOCCCCC

== touch mm/vma.c (0.5s per character) ==
before ▁▁▁█▂▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁  45.7s
       mCmCCmmmCLOOOOOOOOOOOOOOOOOOOOmPPPPPPPPPPPPPPPPPPPCLmKKKCCCmmKKKCCCLmmmmmmCCZZZZZZZZZZZZZZC
after  ▁▁▅▁▁▁▁▁▁▁▁▁▁▁▁▁▁▂▁▁▁▁▁▁▁▁▁▁▁▁▂▁  15.7s
       mmCCCLOOOOOOOOOPPPPLKCKCLmmmmmCC

== no-op make (0.2s per character) ==
before ▁▁▁▁▁▁▁███▂▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁  14.4s
       CCCCmmmCCCmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmm
after  ▁▁▁▁▄▆▄▁  2.0s
       CCmmmCmm

> --
> Thanks,
> ~Nick Desaulniers

--
Cheers, Lorenzo
-------------- next part --------------
A non-text attachment was scrubbed...
Name: build-utilisation.png
Type: image/png
Size: 153235 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-riscv/attachments/20260909/50e2351a/attachment.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: build-utilisation.svg
Type: image/svg+xml
Size: 87559 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-riscv/attachments/20260909/50e2351a/attachment.svg>