From: SeongJae Park <sj@kernel.org>
To: Akinobu Mita <akinobu.mita@gmail.com>
Cc: SeongJae Park <sj@kernel.org>, damon@lists.linux.dev
Subject: Re: [RFC PATCH 0/4] mm/damon: introduce perf event based access check
Date: Fri, 23 Jan 2026 18:39:16 -0800 [thread overview]
Message-ID: <20260124023917.78649-1-sj@kernel.org> (raw)
In-Reply-To: <20260123021014.26915-1-akinobu.mita@gmail.com>
On Fri, 23 Jan 2026 11:10:10 +0900 Akinobu Mita <akinobu.mita@gmail.com> wrote:
> DAMON currently only provides PTE accessed-bit based access check, this
> patch series adds a new perf event based access check.
Very interesting patch series. Thank you for sharing this Akinobu!
I only took a glance on the patches, but my understanding is that this series
modifies DAMON to be able to enable perf events of PERF_SAMPLE_ADDR type, and
utilize the sampled perf events in the perf events buffer as the source of
DAMON's access checks. In more detail, I understand enabling PERF_SAMPLE_ADDR
type perf events makes the perf events buffer filled with memory access event
information with the access destination address. The event will be sampled
based on time (e.g., one access event per X milliseconds). And probably that
sample data could include more information includign the CPU and the process
that executing the sampled access? Please correct me if I'm wrong and add more
details I'm missing, as my understanding of perf event is very poor.
And one quick question. Can this work on virtual machines? I'm asking this
question the for following reason. I'm actuaally working on a similar project
that extends DAMON for page fault based access events sampling [1]. The
project aims to use page fault event rather than other h/w features such as AMD
IBS or Intel PEBS, because my understanding is that such h/w features are not
available on virtual machines.
>
> Since perf event-based access checks do not require modifying the PTE
> accessed-bit for pages representing each damon region, this patch series
> also includes a feature that allows you to set upper and lower limits on
> the damon region size to enable access checks with finer granularity.
I was also thinking about extending DAMON with AMD IBS or Intel PEBS like h/w
features for this kind of sub-page granularity access monitoring. So this
makes sense to me, and sounds useful!
>
> Using these features also requires modifications to damo, but these are
> not included in this patch series and are currently under development in
> the following branch:
>
> https://github.com/mita/damo/tree/damo-perf-for-v3.1.0
>
> Any feedback or advice on the patch set would be greatly appreciated.
>
> Akinobu Mita (4):
> mm/damon/core: add common code for perf event based access check
> mm/damon/vaddr: support perf event based access check
> mm/damon/paddr: support perf event based access check
I find your patches are introducing new infra code for this extension. It
seems bit specialized for perf event only, though. I'm concerned if future
extension for another access check primitives cannot reuse the infra.
My DAMON extension project [1] is for page fault based access monitoring, but
it also introduces a framework for general multiple access sampling primitives.
I'm wondering if perf event based extension can be implemented using the
general acces ssampling primitives infra code, and if you already considered
that but found it is not feasible.
> mm/damon: allow user to set min and max size of region
The min size setup makes sense. I understand the max size is for disabling the
regions adjustment (merge/split) mechanism. IOW, for fixed granularity
monitoring. Users can do that by setting min_nr_regions and max_nr_regions
same [2], though. So, max size setting seems not really needed.
Again, great RFC patch series, thank you for sharing! I'm looking forward to
your answers to above high level questions and comments.
>
> .../ABI/testing/sysfs-kernel-mm-damon | 11 +
> include/linux/damon.h | 42 +-
> mm/damon/core.c | 202 ++++-
> mm/damon/ops-common.h | 39 +
> mm/damon/paddr.c | 106 ++-
> mm/damon/sysfs.c | 402 +++++++++-
> mm/damon/tests/core-kunit.h | 2 +-
> mm/damon/tests/sysfs-kunit.h | 2 +
> mm/damon/tests/vaddr-kunit.h | 7 +-
> mm/damon/vaddr.c | 690 ++++++++++++++++--
> 10 files changed, 1425 insertions(+), 78 deletions(-)
>
> --
> 2.43.0
[1] https://lore.kernel.org/damon/20251208062943.68824-1-sj@kernel.org/
[2] https://origin.kernel.org/doc/html/latest/mm/damon/faq.html#can-i-simply-monitor-page-granularity
Thanks,
SJ
next prev parent reply other threads:[~2026-01-24 2:39 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-01-23 2:10 [RFC PATCH 0/4] mm/damon: introduce perf event based access check Akinobu Mita
2026-01-23 2:10 ` [RFC PATCH 1/4] mm/damon/core: add common code for " Akinobu Mita
2026-01-23 2:10 ` [RFC PATCH 2/4] mm/damon/vaddr: support " Akinobu Mita
2026-01-23 2:10 ` [RFC PATCH 3/4] mm/damon/paddr: " Akinobu Mita
2026-01-23 2:10 ` [RFC PATCH 4/4] mm/damon: allow user to set min and max size of region Akinobu Mita
2026-01-24 2:39 ` SeongJae Park [this message]
2026-01-24 2:48 ` [RFC PATCH 0/4] mm/damon: introduce perf event based access check SeongJae Park
2026-02-23 8:08 ` Namhyung Kim
2026-02-25 6:48 ` Akinobu Mita
2026-02-26 1:24 ` Namhyung Kim
2026-01-27 1:29 ` Akinobu Mita
2026-01-27 6:43 ` SeongJae Park
2026-01-27 12:56 ` Akinobu Mita
2026-01-28 1:12 ` SeongJae Park
2026-02-17 0:13 ` SeongJae Park
2026-02-17 13:32 ` Akinobu Mita
2026-02-17 15:15 ` SeongJae Park
2026-02-18 8:20 ` Akinobu Mita
2026-02-18 15:40 ` SeongJae Park
2026-02-19 6:28 ` Akinobu Mita
2026-02-19 6:49 ` SeongJae Park
2026-03-03 1:05 ` SeongJae Park
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260124023917.78649-1-sj@kernel.org \
--to=sj@kernel.org \
--cc=akinobu.mita@gmail.com \
--cc=damon@lists.linux.dev \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox