Re: [RFC PATCH] perf/amd/ibs: Report physical address for IBS fetch samples

[Huang Shijie <huangsj@hygon.cn>]

On Tue, Aug 18, 2026 at 11:19:13AM +0200, Peter Zijlstra wrote:
> > >>
> > >> PERF_SAMPLE_PHYS_ADDR is meant to capture the _data_ physical address, which
> > >> IBS Fetch doesn't provide. So, repurposing semantics of PERF_SAMPLE_PHYS_ADDR
> > >> for IBS Fetch seems reasonable.
> > >>
> > >> Reviewed-by: Ravi Bangoria <ravi.bangoria@amd.com>
> > > 
> > > Well, why confuse things?
> > > 
> > > As you say, PHYS_ADDR is for ADDR, which is the *data* address, and
> > > FETCH is an instruction address, which we find in IP, not DATA.
> > > 
> > > What would be the purpose of confusing things and making PHYS_ADDR
> > > relate to IP?
> > 
> > Agreed, that would create confusion.
> > 
> > Do you think we should introduce a new type PERF_SAMPLE_IP_PHYS_ADDR?
> > I didn't suggest it earlier because I thought it would be overkill.
> 
> Well, that all depends on how useful this data is. As is, I see very
> little words on the benefit of having this data.

I just use this patch to track a program's memory footprint, including
the front-end(Fetch samples) and back-end(Op samples) in NUMA server.

So I also think there is no need to add a PERF_SAMPLE_IP_PHYS_ADDR for this.

Thanks
Huang Shijie


> 
> In fact, I'm not really sure what PHYS_ADDR is good for, so clearly I'm
> missing a bit to begin with.
> 
> That is; if there is a very convincing argument to actually have this
> data, that might help justifying either accepting this 'hack' or perhaps
> introducing more fields.
>