Thread (105 messages) 105 messages, 14 authors, 28d ago

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

flat view

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

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) [off-list ref] wrote:
quoted
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.
quoted
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

Attachments

Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help