Thread (21 messages) flat view 21 messages, 3 authors, 10d ago

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

From: SJ Park <sj@kernel.org>
Date: 2026-09-11 00:34:10
Also in: damon, linux-doc, lkml

On Thu, 10 Sep 2026 10:16:14 -0700 Ravi Jonnalagadda [off-list ref] 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

[...]
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help