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

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?

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

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.

Thanks,
KunWu