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 Wed, 21 Oct 2026 22:32:26 -0700 SJ Park <sj@kernel.org> wrote:

> On Wed, 21 Oct 2026 21:17:08 -0700 Ravi Jonnalagadda <ravis.opensrc@gmail.com> wrote:
>
[...]
> > 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.
[...]
>
> 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.

No strong concern.  Starting with decode makes sense, and VMs are a
good reason for it: in the KVM setups tried on Intel and AMD hosts, no
guest got a data address from the PMU, whereas every guest had a
software CPU clock (PERF_COUNT_SW_CPU_CLOCK) or basic hardware cycle
counter (PERF_COUNT_HW_CPU_CYCLES).

As quick background on why those earlier test tables brought up PEBS
and IBS: in perf_event, sampling CPU cycles has two modes, selected by
attr.precise_ip (the :p suffix in perf record):

  - Plain cycle or timer sampling (attr.precise_ip = 0, the default):
    a counter overflows and raises a normal interrupt/NMI.  The
    hardware does not record a data address; the handler just sees
    pt_regs where the CPU stopped between instructions.  Even though
    the interrupt lands a few instructions after the overflow ("skid"),
    regs->ip is the next instruction about to run and pt_regs holds
    its untouched input registers -- so decoding regs->ip gives the
    address it is about to access.

  - Hardware "precise" sampling (attr.precise_ip > 0, which routes to
    Intel PEBS or AMD IBS): the PMU hardware itself snapshots the
    instruction and, on supported events, the data address it touched.
    My earlier tables tested this mode.  Because PEBS records registers
    after the instruction retires (when a load into its own base
    register has already overwritten it) and IBS does not capture
    general registers, software decode breaks there -- which is fine,
    since in that mode you use the hardware-captured address instead
    (your Milestone 3).

So there is no need to revisit those earlier test tables for your
Milestone 2 prototype.

Two small tips for the prototype:

  - use PERF_COUNT_HW_CPU_CYCLES (or PERF_COUNT_SW_CPU_CLOCK in VMs
    without a virtual PMU) with the default attr.precise_ip = 0;
  - skip, and count, samples whose instruction does not access memory;
    in typical programs, only ~15-60% of cycle samples land on a load
    or store.

If you want to inspect what those samples look like from user space on
a program:

  R=AX,BX,CX,DX,SI,DI,BP,SP,IP,R8,R9,R10,R11,R12,R13,R14,R15
  perf record -c 2000003 -e cycles:u --intr-regs=$R -- <program>
  perf script -F ip,iregs,insn

(In a guest without hardware cycle counters, use -e cpu-clock:u
instead.)  Each sample shows the IP, the registers and the instruction
bytes to decode.

Thanks,
Ravi