On Mon, Sep 21, 2026 at 09:27:33PM -0700, Josh Poimboeuf wrote: > On Thu, Sep 17, 2026 at 05:06:27PM +0100, Lorenzo Stoakes (ARM) wrote: > > During a kernel build objtool is used to decode vmlinux.o's instructions > > and resolve every jump and call destination. > > > > This forms a large part of the work objtool does during the build process, > > and it is all done in serial. > > > > Decode these in parallel at a function granularity to speed things up, but > > limit this to invocations that pass --link, and only where the there is 8 > > MiB or more text to justify it. > > > > In practice this limits this to processing vmlinux.o in the kernel build > > and modules are processed as they were before. > > > > Only the instruction hash is shared between the threads and nothing is ever > > removed from it, so an insertion is a compare-and-swap on the bucket head. > > > > Threading is limited to decoding and the jump pass, so the gain flattens > > out at 16 threads and any further threads were found to only add overhead. > > > > When performing an allmodconfig build, the clang invocation of objtool when > > processing vmlinux.o took 5.93s on 1 thread, 4.56s on 8, 4.51s on > > 16 and 4.63s on 128. > > > > Therefore cap the thread count at 16 or the number of CPUs, whichever is > > fewer. > > > > The output of objtool before and after this change was confirmed to be > > byte-for-byte identical for x86_64 defconfig and allmodconfig with gcc and > > clang, and for a loongarch defconfig, where objtool runs on every object. > > > > On a 128-thread machine, objtool on the clang allmodconfig vmlinux.o goes > > from 5.2s to 4.4s (6.5s to 4.4s together with the previous two patches), > > and on defconfig from 1.99s to 1.38s. > > > > objtool on vmlinux.o is on the serial tail of every build that links > > vmlinux, no-op builds are unchanged. > > > > Whole build, 128-thread Threadripper 9980X, best of N runs: > > > > before after delta > > ------------------------------- > > x86 defconfig, touch mm/vma.c, gcc 8.2s 7.7s -0.55s (-7%) > > x86 defconfig, touch mm/vma.c, clang 7.3s 6.9s -0.44s (-6%) > > x86 defconfig, clean, gcc 28.6s 28.2s -0.47s (-2%) > > x86 defconfig, clean, clang 29.1s 28.7s -0.45s (-2%) > > x86 allmodconfig, touch mm/vma.c, gcc 25.7s 23.7s -2.0s (-8%) > > x86 allmodconfig, touch mm/vma.c, clang 24.1s 22.5s -1.6s (-7%) > > > > Assisted-by: LLM > > Signed-off-by: Lorenzo Stoakes (ARM) <[email protected]> > > --- > > tools/objtool/Makefile | 2 +- > > tools/objtool/check.c | 717 > > ++++++++++++++++++++++++++++++++++++------------ > > tools/objtool/objtool.c | 14 +- > > 3 files changed, 546 insertions(+), 187 deletions(-) > > This is an interesting patch, but I'm not really convinced it's worth > the pain.
Obviously I defer to you as the maintainer :) But I think the numbers are pretty significant, certainly for allmodconfig incremental it's a fairly significant chunk of the improvement. Yes it's a relatively large-ish change but it's sensible and straight-forward one and certainly in the direction you'd expect to see changes in (parallelise things we can do less work where possible). And note that the work is limited only to those tasks which have singificant data to process and only if --link is specified, so the scope is relatively small. We could add a flag for this also potentially? Obviously if you feel firmly that this isn't something you want I can also drop it but I think it is worth having. One thing to note is that I went through a (bloody painful :) process of dropping everything that felt like bad RoI which the LLM came up with, it started at something crazy like 30-35 patches :) (This was prior to reworking code, checking everything, etc. - gawd the schloppers have it easy not doing all that! :) Anyway let me know what makes sense. > > -- > Josh -- Cheers, Lorenzo
