Re: [PATCH v3 0/2] perf unwind: Don't load symbols when the caller doesn't need them

[Namhyung Kim <namhyung@kernel.org>]

On Fri, Nov 06, 2026 at 04:26:54PM -0800, Matthew Wood wrote:
> On Thu, Nov 5, 2026 at 11:04 PM Namhyung Kim <namhyung@kernel.org> wrote:
> >
> > Hello,
> >
> > On Fri, Oct 30, 2026 at 12:32:32PM -0700, Matthew Wood wrote:
> > > When perf only needs to know which DSOs a callchain passes through (as
> > > build-id marking does at the end of 'perf record' and in 'perf inject
> > > -b') it resolves the callchain without symbols. The DWARF unwinders
> > > ignore that and look up the symbol of every frame anyway, which loads
> > > and demangles the whole symbol table of each DSO they visit.
> > >
> > > On arm64 every frame pointer sample also gets a short DWARF
> > > unwind to find the leaf function's caller; since v6.17 (commit
> > > 29be60c93d2d, "perf build-id: Mark DSO in sample callchains") the end of
> > > 'perf record -a --call-graph fp' loads the symbols of every user binary
> > > it sampled. On a 128-CPU arm64 host,
> > >
> > >   perf record -a -e cycles:u --call-graph fp -- sleep 2
> > >
> > > never finishes writing perf.data, with over 1GB of heap growth in 5
> > > seconds.
> > >
> > > Skipping the symbol lookup isn't enough because loading the
> > > symbols also finds two things the unwinders depend on: the DSO's
> > > build-id, which libdw needs to fall back to the build-id cache, and any
> > > separate debuginfo file, through dso__symsrc_filename(), which is how
> > > both unwinders find a .debug_frame there.
> > >
> > >   1: add dso__load_symsrc(), which does the same search for debuginfo
> > >      and the build-id as symbol loading, but doesn't read any symbols
> > >   2: pass the symbols flag down to the unwinders and honour it, using
> > >      dso__load_symsrc() when symbols aren't wanted, which also makes
> > >      the arm64 leaf frame caller unwind skip symbols
> >
> > Please don't.  I've added dso__dbginfo_type() to handle debug files and
> > that's the correct way to get the file.  Probably dso__debuginfo() would
> > work for you.
> >
> > I was working on cleaning up this area, but sidetracked by other things.
> > I hope to find time for it soon but you can go with the above helpers.
> >
> > Thanks,
> > Namhyung
> >
> 
> Hi Namhyung, thanks for the feedback. I'll look into those helpers and see about
> using them instead.

Great.

> 
> Can you confirm if the premise of the issue I'm reporting and trying
> to fix seems
> valid? Would saving this unnecessary work of symbol lookup when they're
> unused be part of your cleanup?

Basically there are 3 main use cases for DSO.

 1. symbol table - most analysis need symbol names
 2. binary contents - for perf annotate or instruction analysis
 3. debug information - srcline, inlined symbols, stack unwinding, ...

Due to split files, those information can be found in different files.
So we now have 3 types of binary type info to handle the cases
independently.  New helpers will give you a write path name for your use
case already.

Thanks,
Namhyung