Re: [RFC PATCH v1 0/8] perf/core, perf/tools: Add PERF_SAMPLE_BUILD_ID_OFFSET support
From: Namhyung Kim
Date: Wed Aug 26 2026 - 19:20:12 EST
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.
Thanks,
Namhyung