Re: [PATCH v2 00/18] perf symbol: Reference counting, sorted arrays, and memory shrinking

[David Laight <david.laight.linux@gmail.com>]

On Fri, 30 Oct 2026 10:57:27 -0700
Ian Rogers <irogers@google.com> wrote:

> To: Alireza Haghdoost <haghdoost@uber.com>
> Cc: acme@kernel.org, namhyung@kernel.org, adrian.hunter@intel.com,   james.clark@linaro.org, jolsa@kernel.org, linux-kernel@vger.kernel.org,   linux-perf-users@vger.kernel.org, mingo@redhat.com, peterz@infradead.org
> Subject: Re: [PATCH v2 00/18] perf symbol: Reference counting, sorted arrays,  and memory shrinking
> Date: Fri, 30 Oct 2026 10:57:27 -0700
> 
> On Fri, Oct 30, 2026 at 9:10 AM Ian Rogers <irogers@google.com> wrote:
> >
> > On Fri, Oct 30, 2026 at 7:02 AM Alireza Haghdoost <haghdoost@uber.com> wrote:  
> > >
> > > Hi Ian,
> > >
> > > I applied v2 on perf-tools-next e74880764bf9 with the ELF_C_READ_MMAP
> > > fix and your three fixes, and compared it with the same tree without
> > > the 18 patches. I posted comments are on the individual patches; this is the
> > > summary.
> > >
> > > On a profile of a large C++ service, about 1M symbols, perf script and perf r
> > > eport output is byte-identical and roughly 22-32% faster:
> > >
> > > Execution time and peak RSS before and after:
> > > perf script                                3.3s 334 MiB vs 2.25s 332 MiB
> > > perf report --sort dso,sym       3.0s 389 MiB vs 2.25s 386 MiB
> > > perf report --children -g caller 4.6s 706 MiB vs 3.60s 703 MiB
> > >
> > > Peak RSS barely moves. sizeof(struct symbol) goes from 48 to 32 bytes,
> > > but the address array adds a pointer per symbol back, so the net is
> > > about 8 bytes per symbol before malloc rounding. That is under 1%
> > > here.  
> >
> > Thanks for your work and running the numbers! I think we should aim to
> > land your lazy loading patches ahead of these patches. The merge
> > conflicts don't look like they'll be too terrible, wdyt?
> >
> > Since the merge window for Linux v7.4 is currently open, I don't see
> > anything landing before November 1st. So I can do a v3 incorporating
> > your suggestions and rebase it on top of your patches when they land.
> > I'll work on pulling out the fixes (you highlighted some you thought
> > were particularly worthwhile) to mail for v7.4 for now.  
> 
> Chatting with Namhyung he mentions having the arrays in the DSOs be a
> `struct symbol[]` rather than a `struct symbol *[]`, because the
> number of symbols could be known for a DSO when we load the symbols.
> Currently this isn't possible because of things like the
> annotated_symbol that this series turns into a side table. I'm not
> sure it is possible in general to use an array of symbols, as JIT code
> may need the symbols array to be realloc-ed and the realloc would
> potentially invalidate any `symbol *` that had been given out. Maybe
> we can treat that as a special case. In this scenario, the symbol's
> lifetime would tie to the DSO's lifetime, allowing us to use the DSO
> reference count instead of needing one per symbol. It would still be
> nice to add functions like session__malloc so that we can reduce the
> memory footprint of a session when memory allocations fail. I still
> think this is work to land on top of your series.

Could you have two tables, one 'struct symbol []' containing the fixed
symbols and a second smaller 'struct symbol *[]' containing any extra
symbols?
Lookup would require checking both tables - but won't cost much more.

David

> 
> Thanks,
> Ian