Re: [RFC PATCH 0/6] mm/damon: hardware-sampled access reports

[SJ Park]

On Fri, 21 Aug 2026 09:32:02 -0700 Ravi Jonnalagadda <ravis.opensrc@xxxxxxxxx> wrote:

> On Fri, Aug 21, 2026 at 2:55 AM KunWu Chan <kunwu.chan@xxxxxxxxx> wrote:
> >
> > Hi Ravi,
> >
> > Thanks for the detailed reply.  The fan-in diagnosis makes perfect sense.
> >
> > > Your series is based on the v1 substrate, and the way an event is
> > > configured is the part that moves most.
> > >
> > > [...]
> >
> > Glad to hear v2 is on the way.  The probe-based model is actually
> > something I encountered while building the AUX backend. When multiple
> > sources can feed the same region (e.g. PTE scanning + SPE/IBS), the
> > question of how to combine their reports becomes interesting.
> >
> > For example, CXL tiering may care about physical-address locality, while
> > per-process monitoring may need virtual-address attribution.  How do you
> > see probe weights being determined — is that expected to be
> > scenario-specific, or is there a more general principle behind the
> > weighting?
> 
> Hello KunWu,
> 
> SJ can answer that authoritatively -- the probe and weight interface
> is his. Here is my understanding which SJ can confirm later:
> 
> Weights are relative, and only among probes. A context can hold up to four;
> each report carries its probe index and credits that probe's own hit count,
> so two PMU-based probes in one context are scored in proportion to their
> weights, and that is where a scenario-specific choice belongs.
> 
> What does not mix is a weighted probe with the other two sources. Any
> nonzero weight switches the whole context to probe-weighted scoring, which
> turns page-table access checking off -- so SPE cannot be blended with PTE
> scanning, it replaces it. Page-fault reports carry no probe index; they
> credit the region's access rate but have no hit count, so under weighted
> scoring they are not part of the score either. Both coexist with a probe
> only at weight zero, where everything feeds the same access rate and is
> indistinguishable afterwards.
> 
> So for your case I would read it as: PA locality and VA attribution are
> different targets and different address kinds, which points at separate
> contexts rather than one context with tuned weights.

Thank you for detailed response, Ravi.  Ravi is correct.  Physical address and
virtual addresses wouldn't be able to be monitored with a single DAMON context.
The user may need to have a DAMON context for physical address space, and
another DAMON context for virtual address spaces.


Thanks,
SJ

[...]