Re: [PATCH v5 2/5] perf dso: Allow reading DSO data from an explicit file

[Namhyung Kim <namhyung@kernel.org>]

Hello Alireza,

On Sun, Oct 18, 2026 at 08:09:41AM -0700, Alireza Haghdoost wrote:
> Hi Namhyung,
> 
> Sorry for the late reply, and thank you for the clarification.
> 
> On Wed, Oct 7, 2026 at 3:09 PM Namhyung Kim <namhyung@kernel.org> wrote:
> > I'm afraid it may confuse perf annotate where it needs to read binary
> > data from a file as well as lazy-load symbols from another.  I'm working
> > on cleaning up the relevant code and I'm reluctant to add 'path' to the
> > dso.  We have too many names for a DSO already. :)
> >
> > For a short term solution, I'm afraid you need to use dso__get_filename()
> > with symtab_type and read the file without using the data cache API.
> 
> I understand the concern about storing this path in the DSO. Perf
> annotate and the lazy loader can read different files. I will drop this
> patch in the next revision (v6).
> 
> For context, the v1 lazy loader kept one file descriptor open for each
> DSO. In your v1 review, you asked me to use dso__data_read_offset().
> This let the data cache control the open descriptors and close them
> when necessary.
> 
> Using dso__data_read_offset() also showed a problem with split
> debuginfo. The symbol name offsets refer to the symbol table file.
> However, the data cache opens the runtime binary. The same offset in
> these two files can contain different data. That is why I needed to
> tell the data cache to open the symbol table file.
> 
> I put this support in a separate patch after your v2 review requested
> that I split the exact-path DSO data-cache support into an independent
> split-debuginfo fix.
> 
> For v6 revision, the lazy loader will call dso__get_filename() with the symtab
> type. It will open the returned file, read the names with pread(), and
> close the file. Thus, it will not keep one descriptor open for each
> DSO. It will also not change the existing data cache.
> 
> This short-term solution can open the same file many times. It also
> cannot use one DSO cache entry for nearby names. However, later reads
> can usually use data that is still in the kernel page cache and avoid
> storage I/O. Therefore, the main additional costs are the open, close,
> and pread system calls.
> 
> The performance cost is small in the test profile. Eager loading takes
> 3.2 seconds. v5 lazy loading takes 1.4 seconds. v6 lazy loading takes
> 1.5 seconds. All three produce identical output.

Thanks for checking this!

> 
> > In the long term, I think it needs to pass a binary type arguments to
> > read data from the dso.  It'd clarify what users want to read and
> > support different files at the same time.
> 
> Ack. Your recent cleanup keeps the binary type separate from the symtab
> type during symbol loading. The DSO also has a separate debug-info type.
> These fields identify the files that a caller wants to read. The data
> cache does not use this information yet.
> 
> Unless you are already working on this part, I can send a separate
> series to make the data cache type-aware. The series will add a type
> argument to the read API and keep separate cache state for each backing
> file. I can then change the lazy loader to use the data cache again. I
> will keep this work separate from the lazy loader patch series.

Sounds good.  Please go ahead!

Thanks,
Namhyung