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

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.

>
> > 2. The 67.9% drop rate is fan-in, not sizing
> >
> > ---
> >
> > [...]
>
> I completely missed this.  The observability framework showed the
> symptom (67.9% drop) but got the root cause wrong — it's not a ring
> sizing issue, it's a fan-in problem.  With a single kdamond thread
> draining the per-CPU sources, the samples effectively get funneled
> into a single ring, which explains the numbers.
>
> The per-CPU drain approach using `system_percpu_wq` and `queue_work_on()`
> looks like the right fix.  Our AUX backend already carries a CPU argument
> through the ops, so adapting it should be straightforward.  I'll take a
> look at your v2 branch and re-test with the per-CPU drain.
>
> Two questions:
> 1. Is `damon/perf-rfc-v2-08-20-26` ready for me to rebase the
>    AUX backend and observability framework on top of it?  I'd like to
>    validate the per-CPU drain fix with real SPE hardware.
>

Yes:

  https://github.com/ravis-opensrc/linux.git
  branch damon/perf-rfc-v2-08-20-26, tip 9c0410564596

That is the branch I used to exercise the AUX path. It carries all five of
your AUX kernel-consumer API patches unmodified, and from the SPE series,
patch 1/4 plus the generic half of 2/4. 2/4's SPE backend and parser, and
3/4 and 4/4 which test them, are SPE-specific and I used an x86 box
with virtual PMU.

The branch is force-updated post fixing two trailers please re-fetch
if necessary.

None of it is meant for my v2 posting.
This branch is only the vehicle for testing the AUX report path.

The SHAs you will care about:

  808519650a7a  the per-CPU report side
  e3323a3bdc75  your AUX interface, ported to the probe model
  1c347519c626  parse each CPU's AUX buffer on that CPU
  9c0410564596  perf/core: balance the AUX buffer reference on kernel
                release

1c347519c626 drains with one work item per CPU in the event's cpumask, via
queue_work_on() on system_percpu_wq -- system_wq would not do, being
unbound it silently ignores the CPU targeting.

Two things came out of a quick test in a VM:

- spe_backend_init() calls perf_event_setup_aux(), but I could not find any
  path calling perf_event_release_aux() -- spe_backend_cleanup() frees only
  st->win, and your kerneldoc says the release must happen before
  perf_event_release_kernel(). Left alone on my branch.

- 9c0410564596: the explicit ring_buffer_put() in perf_event_release_aux()
  is one too many, since ring_buffer_attach(event, NULL) just above already
  drops the event's reference.

> 2. For the probe-based configuration, does the `prep_action = "perf_event"`
>    model preserve the same event lifecycle?  Our AUX path needs to create
>    and bind the event during apply, keep it disabled initially, and enable
>    it when kdamond starts.
>

Yes -- created disabled during apply, bound, then enabled. Per CPU, on the
kdamond turn-on path:

  perf_event_create_kernel_counter()   attr has .pinned = 1, .disabled = 1,
                                       so the counter is installed but not
                                       yet schedulable
  ops->init(event, cpu, perf_event)    your backend attaches the AUX buffer
                                       here, via perf_event_setup_aux()
  perf_event_enable()                  only now can the PMU be scheduled in

So the buffer is always attached before the counter starts. If ops->init()
fails the counter is released without ever being enabled.
kernel/watchdog_perf.c uses the same pinned + disabled-then-enable pairing.

Sanity-tested both report paths in a VM.

Best Regards,
Ravi.

> Thanks,
> KunWu