Re: [RFC PATCH v0] Docs/mm/damon/design: document data attributes report infra design (beyond page table accessed-bit milestone 2)

[SJ Park <sj@kernel.org>]

On Wed, 21 Oct 2026 21:17:08 -0700 Ravi Jonnalagadda <ravis.opensrc@gmail.com> wrote:

> Hi SJ,
> 
> On Sun, 18 Oct 2026 13:08:07 -0700 SJ Park <sj@kernel.org> wrote:
> 
> > Good question.  damon_report_attr() will save the register contents and pid
> > into report, too.  And the probe in kdamond context will decode the instruction
> > and get the memory address.  For physical address, it will also do the page
> > table walk of the process of the pid.
> 
> I measured what the samples carry, to see how far decode would go.
> 
> On AMD, cpu-cycles:p is IBS Op, and its memory-op samples carry a
> hardware data address.  On Intel (Granite Rapids), cycles samples carry
> no data address at all; the PEBS memory events
> (MEM_INST_RETIRED.ALL_LOADS/ALL_STORES) do.
> 
> Share of samples with an address inside the 2 GiB test buffer (random
> loads and stores; perf record -d; one run per event):
> 
>   Xeon 6960P   cycles:p / cycles:pp / :ppp     0 %
>   Xeon 6960P   mem_inst_retired.*:pp          100 %
>   EPYC 9555P   cycles:p, cycles:pp, ibs_op//  ~21 % of all samples
>                                               (the memory-op ones)
> 
> How often the saved AX holds the target address when AX is the base
> register (perf record -d --intr-regs=AX; store to (%rax) vs
> pointer-chase load mov (%rax), %rax):
> 
>   Xeon 6960P   store loop 100 %    pointer-chase loop 0 %
>   EPYC 9555P   store loop   0 %    pointer-chase loop 0 %
> 
> PEBS saves registers just after the instruction retires, so a load that
> overwrites its base register defeats decode.  IBS saves no general
> registers (perf reports the registers at the NMI), so decode is not
> reliable on AMD.  Decode in kdamond must also survive exec, munmap, exit
> and pid reuse.  These are synthetic loops chosen to separate the cases;
> how often real code hits the failing case is not measured.
> 
> For the physical address, taking it at sample time, while the task is
> current, avoids walking a page table that may have changed by the time
> kdamond runs.  IBS supplies it when valid; on Intel the producer can
> call perf_prepare_sample() in the overflow NMI to do the walk.

Thank you for these testing, Ravi.  Unfortunately I'm still learning perf event
and therefore not yet fully understanding these tests.  I will revisit after
gaining more understanding.

> 
> So the suggestion is for the first report type to use the PMU-captured
> address and load/store flag (AMD cpu-cycles:p; on Intel, the PEBS
> memory events, which moves them into milestone 2).  Your call, of
> course.

Meanwhile, I will start with the current plan (capture register contents in NMI
and decode in kdamond) if you don't have strong concern.


Thanks,
SJ

[...]