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

[SJ Park <sj@kernel.org>]

On Thu, 10 Sep 2026 10:16:14 -0700 Ravi Jonnalagadda <ravis.opensrc@gmail.com> wrote:

> This series lets DAMON take its access information from a hardware sampler
> instead of from a page-table scan, and lets a scheme's score be weighted by what
> that sampler reported.
> 
> The change from v1 [1] is that it is now built on the data attribute probe
> infrastructure that has since landed in mm-new: a PMU is expressed as one more
> probe on a context, with its own weight and probe hits, rather than as a
> mechanism of its own beside the ops set.  The rest of this posting is the same
> substrate reworked onto that, plus two consumers.
> 
> This is not a merge request.  The series is based on damon/next at the
> base-commit below, which moves, so the tree it was built and tested from is also
> on
> 
>   https://github.com/ravis-opensrc/linux/tree/damon/perf-rfc-v2-09-06-26
> 
> It is posted for design feedback, on the substrate and on where it belongs in
> the roadmap for extending DAMON beyond the pte-accessed bit [2].  That roadmap's
> second milestone, now open, is a first data attribute monitored through
> `damon_report_access()`, and that is what a sampling PMU is here.  So this
> series keeps that function and its callers and replaces its body: the reporting
> path a hardware sampler needs cannot take a mutex, and the drain has to reach a
> virtual-address context as well as a physical one.  The shape of the ring, the
> drain and the sysfs surface are what is most useful to review.

Thank you for this series, Ravi!  I will take time to thoughly read and reply
this series by the end of this weekend.


Thanks,
SJ

[...]