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

On Sat, Aug 22, 2026 at 8:32 AM SJ Park <[email protected]> wrote:
>
> On Fri, 21 Aug 2026 09:32:02 -0700 Ravi Jonnalagadda <[email protected]> wrote:
>
> > On Fri, Aug 21, 2026 at 2:55 AM KunWu Chan <[email protected]> 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.
>

Thanks, SJ and Ravi, for the detailed clarification.

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

This also corrects an assumption I had about how the DAMON access reporting
model currently combines different sources.

I had previously understood the new push model as something that could
be combined with the existing pull model within the same context. I now
understand that, in the current design, probe-weighted scoring switches
the context away from the existing PTE-based access checking rather than
blending the two.

My previous understanding was therefore off. Thanks for the clarification.

I'll update this point in the blog I'm currently working on, which I've
been writing on and off for almost a month. I'm using it to document the
evolution of the DAMON architecture and the transition from the
traditional pull-based access monitoring toward the new push/probe-based
reporting model.

Thanks,
KunWu

>
> Thanks,
> SJ
>
> [...]