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

[Ravi Jonnalagadda <ravis.opensrc@gmail.com>]

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.

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.

Thanks,
Ravi