From: Nathan Chancellor <nathan@kernel.org>
To: Wentao Guan <guanwentao@uniontech.com>
Cc: nsc <nsc@kernel.org>, tamird <tamird@kernel.org>,
linux-kbuild <linux-kbuild@vger.kernel.org>,
linux-kernel <linux-kernel@vger.kernel.org>,
Petr Pavlu <petr.pavlu@suse.com>
Subject: Re: [PATCH] kbuild: try readelf first in gen_symversions
Date: Thu, 4 Jun 2026 23:22:06 -0700 [thread overview]
Message-ID: <20260605062206.GA661512@ax162> (raw)
In-Reply-To: <tencent_5A209D3D5BB5B16325067261@qq.com>
On Thu, Jun 04, 2026 at 11:44:29AM +0800, Wentao Guan wrote:
> Hello,
>
> > On Thu, Jun 04, 2026 at 12:17:32AM +0800, Wentao Guan wrote:
> > > Use readelf to dig out if <file>.o contain a __export_symbol_*.
> > >
> > > Instead of nm, readelf is more faster, and significantly improve speed
> > > when enable CONFIG_MODVERSIONS.
> > >
> > > Build x86_64_defconfigs in 2C4T cloud server with CONFIG_MODVERSIONS=y:
> > > With patch:
> > > real 17m21.019s
> > > user 61m48.388s
> > > sys 4m27.709s
> > > Without patch:
> > > real 17m39.435s
> > > user 62m24.686s
> > > sys 5m3.200s
> > >
> > > Link: https://lore.kernel.org/all/tencent_2FA16E0A18D6D0C0703F5D49@qq.com/
> > > Signed-off-by: Wentao Guan <guanwentao@uniontech.com>
> > > ---
> > > scripts/Makefile.build | 2 +-
> > > 1 file changed, 1 insertion(+), 1 deletion(-)
> > >
> > > diff --git a/scripts/Makefile.build b/scripts/Makefile.build
> > > index 3498d25b15e85..54a91bc144cce 100644
> > > --- a/scripts/Makefile.build
> > > +++ b/scripts/Makefile.build
> > > @@ -233,7 +233,7 @@ ifdef CONFIG_MODVERSIONS
> > > # be compiled and linked to the kernel and/or modules.
> > >
> > > gen_symversions = \
> > > - if $(NM) $@ 2>/dev/null | grep -q ' __export_symbol_'; then \
> > > + if $(READELF) -sW $@ 2>/dev/null | grep -q ' __export_symbol_'; then \
> >
> > This breaks modversioning for Clang LTO builds, as llvm-nm can read LLVM
> > bitcode but llvm-readelf cannot, it expects strictly ELF.
> Oh, is it worth to use the following logic to detect LLVM or LLVM-LTO or not ?
> +ifeq ($(LLVM),)
This should probably be CONFIG_LTO_CLANG with flipped branches but...
> + SYM_CHECK = $(READELF) -sW
> +else
> + SYM_CHECK = $(NM)
> +endif
> gen_symversions = \
> - if $(NM) $@ 2>/dev/null | grep -q ' __export_symbol_'; then \
> + if $(SYM_CHECK) $@ 2>/dev/null | grep -q ' __export_symbol_'; then \
>
> > that it stops looking for a match after the first export symbol is
> > found?
> Small, there are my test result in make x86_64_defconfig + enable CONFIG_MODVERSIONS:
> 1. readelf
> if $(READELF) $@ 2>/dev/null | grep -q ' __export_symbol_';
> real 10m44.359s
> user 37m43.596s
> sys 3m2.424s
> 2. nm
> if $(NM) $@ 2>/dev/null | grep -q ' __export_symbol_';
> real 11m8.008s
> user 38m51.644s
> sys 3m29.798s
> 3. nm + grep -m1 -q
> if $(NM) $@ 2>/dev/null | grep -m1 -q ' __export_symbol_';
> real 10m56.891s
> user 38m8.136s
> sys 3m28.096s
'-m1' appears to get us 50% (12s) of the speed up of 'readelf' (24s) in
your environment while sticking with 'nm'. I would be more inclined to
take that change since it is small and correct, rather than switching on
NM or READELF, as I don't think it is worth the additional complexity.
FWIW, on one of my test machines with 8 cores and 16 threads, the
difference is much less noticeable. I think that is going to be in line
with most developer and build farm hardware, rather than a 2C/4T machine
like you mention in the initial commit message.
GCC 16.1.0 + binutils 2.46:
Benchmark 1: $(NM)
Time (mean ± σ): 75.203 s ± 0.283 s [User: 659.465 s, System: 185.605 s]
Range (min … max): 74.898 s … 75.457 s 3 runs
Benchmark 2: $(READELF) -sW
Time (mean ± σ): 73.055 s ± 0.465 s [User: 642.365 s, System: 175.908 s]
Range (min … max): 72.523 s … 73.385 s 3 runs
Summary
$(READELF) -sW ran
1.03 ± 0.01 times faster than $(NM)
LLVM 22:
Benchmark 1: $(NM)
Time (mean ± σ): 75.030 s ± 0.736 s [User: 659.603 s, System: 185.257 s]
Range (min … max): 74.207 s … 75.623 s 3 runs
Benchmark 2: $(READELF) -sW
Time (mean ± σ): 73.405 s ± 0.457 s [User: 642.512 s, System: 176.440 s]
Range (min … max): 72.878 s … 73.679 s 3 runs
Summary
$(READELF) -sW ran
1.02 ± 0.01 times faster than $(NM)
--
Cheers,
Nathan
next prev parent reply other threads:[~2026-06-05 6:22 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-06-03 16:17 [PATCH] kbuild: try readelf first in gen_symversions Wentao Guan
2026-06-04 1:38 ` Nathan Chancellor
2026-06-04 3:44 ` Wentao Guan
2026-06-05 6:22 ` Nathan Chancellor [this message]
2026-06-05 11:03 ` Wentao Guan
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260605062206.GA661512@ax162 \
--to=nathan@kernel.org \
--cc=guanwentao@uniontech.com \
--cc=linux-kbuild@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=nsc@kernel.org \
--cc=petr.pavlu@suse.com \
--cc=tamird@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox