Re: [RFC PATCH v1 0/8] perf/core, perf/tools: Add PERF_SAMPLE_BUILD_ID_OFFSET support

[Namhyung Kim]

On Wed, Aug 26, 2026 at 04:19:57PM -0700, Namhyung Kim wrote:
> Hello,
> 
> On Fri, Aug 07, 2026 at 01:18:18PM +0200, Peter Zijlstra wrote:
> > On Fri, Aug 07, 2026 at 12:18:10AM -0700, Ian Rogers wrote:
> > > This patch series introduces PERF_SAMPLE_BUILD_ID_OFFSET to the
> > > perf_event UAPI and implements full support across both the kernel
> > > and perf tools.
> > > 
> > > Background & Motivation:
> > > 
> > > In order for perf to translate virtual addresses of samples into
> > > symbols a file and offset within the file are needed. During event
> > > synthesis perf will create mmap events to facilitate the translation
> > > of a virtual address to a file and offset by modelling the address
> > > space of a process. By directly recording in a sample the Build ID of
> > > a file and the offset within it, no synthesis is necessary. The Build
> > > ID and offset as a pair are much larger than a virtual address, so
> > > there is a trade-off between synthesis cost and extra size for
> > > samples. These changes just facilitate Build ID and offset as a choice
> > > for perf samples and the user can have the choice to use it when they
> > > believe it is advantageous.
> > > 
> > > In practice perf still needs to map a build ID to a file, so by
> > > default this change keeps synthesis to allow this. It is expected a
> > > user that knows their build IDs, say through debuginfod, will disable
> > > this option with say --synth=no.
> > > 
> > > The kernel support uses the existing build ID and offset support used
> > > by BPF stack traces.
> > 
> > That is still a giant stinking mess that needs to cleaned up.
> 
> Then we can discuss how we want to handle that as well. :)
> 
> I think this work would be useful on large systems with lots of tasks.
> I've got reports it took too long on synthesis and timed out.  Also it's
> racy and easy to miss new tasks..
> 
> So I think it's a good option to explore and maybe we can make default
> once it turns out working great.  But I'm afraid it may need some kind
> of optimization to handle multiple addresses like in callchains/LBRs.

One more thought.

Maybe it's not a good idea to traverse the VMA tree in NMI.  Can it use
the deferred unwind framework to do that later?  We could extend it for
non-callchain data like IP and BRANCH_STACKs for user space.

Thanks,
Namhyung