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

[Huang Shijie]

On Tue, Aug 18, 2026 at 01:30:48PM +0200, Peter Zijlstra wrote:
> 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
It is not trouble for us. :)

1.) We can get the physical address ranges in NUMA by parsing the "/sys/devices/system/memeory".
2.) With IBS samples, we can get the physical memory access records.

With 1 & 2, we can draw a detail picture for the memory footprint.
And we can use the result to improve the performance in NUMA.

Thanks
Huang Shijie