Re: [RFC PATCH 0/4] mm/damon: introduce perf event based access check

[SeongJae Park <sj@kernel.org>]

On Tue, 27 Jan 2026 10:29:53 +0900 Akinobu Mita <akinobu.mita@gmail.com> wrote:

> 2026年1月24日(土) 11:39 SeongJae Park <sj@kernel.org>:
> >
> > 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.
> 
> Your understanding is correct.
> 
> One thing to note is that you need to specify a PMU event that can
> obtain the data address at the time of sampling.
> 
> In other words, it must be a PMU that can be used with "perf mem record".

Thank you for confirming and adding the detail.

> 
> > 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.
> 
> I haven't tried it on a virtual machine yet.
> As mentioned above, if "perf mem record" works on a virtual machine,
> you can specify its PMU, but it may not be supported at all.

Seems that's the case at least for my setup. :'(  On my QEMU-based machine,
'perf mem record' fails like below.

    $ sudo perf mem record
    failed: no PMU supports the memory events

Nevertheless, I think there should be users who want to run this on different
setups.

> 
> > > 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.
> 
> If such infrastructure code exists, I would like to use it, so I will
> consider it.

Great.  Please take a look and let me know if you have any questions about
that.  The current implementation of the infra is only for proof of the
concept, so it may lack documentations and quite suboptimal.

> 
> > >   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.
> 
> Yes, if fixed granularity monitoring is possible then that is sufficient.
> 
> I have tried setting min_nr_regions and max_nr_regions to be the same.
> I understand that the region split progresses over time and results
> in fixed-granularity monitoring at the minimum region size, but since
> my configuration has a relatively long sampling interval, it takes
> time to reach that state.

Ok, that makes sense.  Thank you for explaining the issue.

> 
> So in the patch, when adding a new region with damon_set_regions(),
> it will be split by the maximum region size.

Actually DAMON is internally setting such maximum region size based on the
min_nr_regions parameter, via damon_region_sz_limit().  Nonetheless, the limit
is applied only in regions merge time.  That's why it requires the regions
split to happen sufficiently until the real fixed granularity monitoring is
started.

And I think this behavior is just a bug, or suboptimum implementation at least.
That is, users set the minimum number of regions but it may not really be kept.
That's definitely confusing behavior.  Actually there was a similar case that
number of regions can be larger than the max_nr_regions.  We fixed it, with
commit 310d6c15e910 ("mm/damon/core: merge regions aggressively when
max_nr_regions is unmet").  I think we discussed about similar case for
min_nr_regions, but I cannot find the discussion for now.

So, I think it is better to fix this rather than introducing a new parameter.
Maybe we can split regions based on the min_nr_regions based size limit, before
starting the main loop of kdamond_fn().  Similar to the max_nr_regions
violation, there could be yet another corner case on online parameters commit
situation, so it would better to check the case, too.  You could implement such
fix on your own, or let me do that.  In the latter case, if you don't mind, I
will add your Reported-by: tag to the fix.  Please let me know your
preferrence.

> 
> > Again, great RFC patch series, thank you for sharing!  I'm looking forward to
> > your answers to above high level questions and comments.
> 
> Thank you so much for checking out the patch.

The pleasure is mine, and hope this patch series to get more forward progress!


Thanks,
SJ