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

[Peter Zijlstra]

On Tue, Aug 18, 2026 at 07:04:31PM +0800, Huang Shijie wrote:
> 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@xxxxxxx>
> > > > 
> > > > 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.

Ah, so I think me asking about the use of PHYS_ADDR previously, resulted
in the two PAGE_SIZE numbers. I suppose what you're looking for is
PAGE_NODE.

The trouble with physical addresses is that it is very hard for
userspace to do anything useful with them. At least the node mapping is
somewhat doable I suppose.