Re: [PATCH v3 0/6] perf script: Bounded and lazy symbol loading
From: Ian Rogers
Date: Wed Sep 30 2026 - 18:14:46 EST
On Wed, Sep 30, 2026 at 12:58 PM Alireza Haghdoost <haghdoost@xxxxxxxx> wrote:
>
> On Fri, Sep 25, 2026 at 2:56 PM Ian Rogers <irogers@xxxxxxxxxx> wrote:
> >
> > So, I'm pretty against the complexity of dealing with symbols that may
> > fail due to a memory pressure issue.
>
>
> Hi Ian,
>
> That was aimed at --max-symbol-bytes. I'll drop it in v4.
>
> Following the other thread [1], it looks like we agree that lazy loading is
> worth having on its own. Whether or not the reference-counting series
> lands, loading a name only when a sample needs it is a good change. As
> in the numbers I posted there, it cuts memory use substantially and
> makes perf script faster. I'll prepare v4 of this series without the
> cap:
>
> 1. the ELF_C_READ_MMAP fix
> 2. reading DSO data from the debug file the symbol table came from
> 3. the shared duplicate-symbol selection
> 4. --lazy-load-symbols
> 5. the lazy-loading tests
>
> Patches 2 and 3 stay because lazy loading needs them, and Namhyung
> asked for them.
>
> Namhyung, on that thread you suggested a limit that prints an offset
> when the name is not loaded. I said I could do that for the byte cap
> in v4. I'd rather land lazy loading first and add that limit later if
> there is a need or interest.
>
> [1] https://lore.kernel.org/all/20260928075237.3055101-1-irogers@xxxxxxxxxx/
I agree with what you are saying. Without `--max-symbol-bytes`, I
think your series is good. I'm unsure about the symbol changes if
we're not embedding the name anymore; it sounds complex and possibly
brittle, but I got distracted by the max-symbol thing and lost focus
on that part of the change. I am still working on a v2 patch series,
but I'm using a slower but hopefully better AI agent. I've been
unhappy with the shrinking then causing reloading, then causing
shrinking and so-on, when running perf top. We should be able to do
better. I've also added back into my series a patch I dropped a while
ago where missing line maps could trigger useless execution of
addr2line and a lot of wasted time:
https://lore.kernel.org/linux-perf-users/20260824062841.1529489-3-irogers@xxxxxxxxxx/
If you post a v4 I'm happy to review it. You know where I'm coming
from with reference counting and shrinking, so hopefully all the work
can complement each other and reduce memory usage. Perhaps put the
less controversial patches first so they can be merged and not get
blocked by a discussion on a later patch.
Thanks,
Ian
> Thanks,
> Alireza