From: Namhyung Kim <namhyung@kernel.org>
To: Alireza Haghdoost <haghdoost@uber.com>
Cc: Peter Zijlstra <peterz@infradead.org>,
Ingo Molnar <mingo@redhat.com>,
Arnaldo Carvalho de Melo <acme@kernel.org>,
Mark Rutland <mark.rutland@arm.com>,
Alexander Shishkin <alexander.shishkin@linux.intel.com>,
Jiri Olsa <jolsa@kernel.org>, Ian Rogers <irogers@google.com>,
Adrian Hunter <adrian.hunter@intel.com>,
James Clark <james.clark@linaro.org>,
Alexei Starovoitov <ast@kernel.org>,
Andrii Nakryiko <andriin@fb.com>,
linux-perf-users@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v7 3/4] perf script: Add --lazy-load-symbols to load symbol names lazily
Date: Sat, 14 Nov 2026 19:51:04 -0800 [thread overview]
Message-ID: <avksKJdCK9C6wpRv@z2> (raw)
In-Reply-To: <20261113-perf-symbol-memory-send-v7-3-d992eced9f9c@uber.com>
On Fri, Nov 13, 2026 at 09:09:08PM -0800, Alireza Haghdoost wrote:
> This patch adds a --lazy-load-symbols option to perf script. With it,
> perf reads the name of a userspace ELF symbol only when a lookup returns
> that symbol. Eager loading stays the default.
>
> perf script loads the whole ELF symbol table of every DSO that appears
> in a sample and keeps every symbol, with its demangled name, until exit.
> Most of those symbols are never sampled, and their names take most of
> the memory. On a large profile this is the main memory cost of perf
> script, and in a memory-limited cgroup it gets perf OOM-killed.
>
> The loader still creates every symbol, so end fixup, duplicate
> selection, PLT synthesis and IFUNC marking do not change. It stores the
> file offset of each name instead of the name, in a union with the name
> pointer, and SYMBOL_FLAG_LAZY_NAME tells which one is set. Lookups load
> the name of the symbol they return, and code that walks all symbols of
> a DSO gets them from dso__named_symbols(), which loads every name. Names
> are read under the DSO lock with pread() from the symbol table file,
> which is open only while perf reads them. A name that cannot be read
> becomes "[unknown]", and address lookups do not return that symbol.
>
> A few names are still read at load time: aliases that duplicate
> selection can tell apart only by name, and IFUNC symbols, whose names
> PLT synthesis uses. A .dynsym entry that copies a lazy .symtab symbol is
> skipped, since duplicate selection would drop it anyway after reading
> both names.
>
> The offsets are only valid in the file that perf loaded. perf records
> its device, inode, size and mtime, and checks them each time it opens
> the file again. If the binary was replaced in the meantime, for example
> by a deploy, or the path now resolves to another file because a mount
> namespace went away, perf warns once and shows the remaining lazy
> symbols of that DSO as "[unknown]" rather than print wrong names.
Please separate this part into another patch. That would make my life a
bit easier. :) As I said, you can use dso_id instead.
>
> The kernel, modules, PPC64 .opd and .gnu_debugdata still load names
> eagerly.
>
> On a 45,073-sample callchain profile of a large C++ service (about 1M
> symbols), lazy loading cuts max RSS from 327 MiB to 135 MiB and run
> time from 2.9 to 1.3 seconds, with identical output.
Nice!
Thanks,
Namhyung
next prev parent reply other threads:[~2026-11-15 3:51 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-11-14 5:09 [PATCH v7 0/4] perf script: Lazy symbol loading Alireza Haghdoost
2026-11-14 5:09 ` Alireza Haghdoost via B4 Relay
2026-11-14 5:09 ` [PATCH v7 1/4] perf symbols: Split out name-independent duplicate symbol selection Alireza Haghdoost
2026-11-14 5:09 ` Alireza Haghdoost via B4 Relay
2026-11-14 5:12 ` sashiko-bot
2026-11-14 5:09 ` [PATCH v7 2/4] perf symbols: Point to the symbol name instead of embedding it Alireza Haghdoost
2026-11-14 5:09 ` Alireza Haghdoost via B4 Relay
2026-11-14 5:16 ` sashiko-bot
2026-11-14 5:09 ` [PATCH v7 3/4] perf script: Add --lazy-load-symbols to load symbol names lazily Alireza Haghdoost
2026-11-14 5:09 ` Alireza Haghdoost via B4 Relay
2026-11-14 5:31 ` sashiko-bot
2026-11-14 16:30 ` Alireza Haghdoost
2026-11-15 3:51 ` Namhyung Kim [this message]
2026-11-14 5:09 ` [PATCH v7 4/4] perf test: Test lazy symbol name loading Alireza Haghdoost
2026-11-14 5:09 ` Alireza Haghdoost via B4 Relay
2026-11-14 5:19 ` sashiko-bot
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=avksKJdCK9C6wpRv@z2 \
--to=namhyung@kernel.org \
--cc=acme@kernel.org \
--cc=adrian.hunter@intel.com \
--cc=alexander.shishkin@linux.intel.com \
--cc=andriin@fb.com \
--cc=ast@kernel.org \
--cc=haghdoost@uber.com \
--cc=irogers@google.com \
--cc=james.clark@linaro.org \
--cc=jolsa@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-perf-users@vger.kernel.org \
--cc=mark.rutland@arm.com \
--cc=mingo@redhat.com \
--cc=peterz@infradead.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.