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 Fri, 23 Oct 2026 12:48:48 -0700 Ravi Jonnalagadda <ravis.opensrc@gmail.com> wrote:

> 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.

Thank you for these useful information an tips!


Thanks,
SJ