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

[Alireza Haghdoost]

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@xxxxxxxxxx> 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.

> 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.

Thanks,
Alireza