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

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

[SeongJae Park]

Cc-ing linux-perf-users@ for any comment from perf people, about the use of
perf event from DAMON.


Thanks,
SJ

On Fri, 23 Jan 2026 18:39:20 SeongJae Park <sj@kernel.org> wrote:

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

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

[Namhyung Kim]

Hello,

On Fri, Jan 23, 2026 at 06:48:03PM -0800, SeongJae Park wrote:
> Cc-ing linux-perf-users@ for any comment from perf people, about the use of
> perf event from DAMON.

Sorry for the long delay.

> 
> On Fri, 23 Jan 2026 18:39:20 SeongJae Park <sj@kernel.org> wrote:
> 
> > 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.

I'm afraid you need to deal with PMU hardware details.  For example
PERF_SAMPLE_ADDR may not be available depends on events or sometimes it
may not have valid values in some samples like on AMD IBS.  Also hybrid
CPUs may not have same events on both CPUs.

Maybe it's better to fix which event you want to use on each CPU
architecture.

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

KVM supports PMU virtualization.  But the existing vPMU support has a
lot of overhead.  Recently mediated vPMU patchset was added so you can
try that instead.  You'll need to pass appropriate options to qemu.

https://lore.kernel.org/lkml/20251206001720.468579-1-seanjc@google.com/

Thanks,
Namhyung

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

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

[Akinobu Mita]

2026年2月23日(月) 17:08 Namhyung Kim <namhyung@kernel.org>:
>
> Hello,
>
> On Fri, Jan 23, 2026 at 06:48:03PM -0800, SeongJae Park wrote:
> > Cc-ing linux-perf-users@ for any comment from perf people, about the use of
> > perf event from DAMON.
>
> Sorry for the long delay.
>
> >
> > On Fri, 23 Jan 2026 18:39:20 SeongJae Park <sj@kernel.org> wrote:
> >
> > > 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.
>
> I'm afraid you need to deal with PMU hardware details.  For example
> PERF_SAMPLE_ADDR may not be available depends on events or sometimes it
> may not have valid values in some samples like on AMD IBS.  Also hybrid
> CPUs may not have same events on both CPUs.
>
> Maybe it's better to fix which event you want to use on each CPU
> architecture.

Thank you for your advice.

Is it possible to get a list of PMUs that have the ability to get addresses
(PERF_SAMPLE_ADDR or PERF_SAMPLE_PHYS_ADDR) from the kernel at runtime?

Or is it possible to detect that a perf_event initialized with a certain
perf_event_attr does not have the ability to obtain the address?

> > > 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.
>
> KVM supports PMU virtualization.  But the existing vPMU support has a
> lot of overhead.  Recently mediated vPMU patchset was added so you can
> try that instead.  You'll need to pass appropriate options to qemu.
>
> https://lore.kernel.org/lkml/20251206001720.468579-1-seanjc@google.com/

Thank you for the important information.

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

[Namhyung Kim]

On Wed, Feb 25, 2026 at 03:48:29PM +0900, Akinobu Mita wrote:
> 2026年2月23日(月) 17:08 Namhyung Kim <namhyung@kernel.org>:
> >
> > Hello,
> >
> > On Fri, Jan 23, 2026 at 06:48:03PM -0800, SeongJae Park wrote:
> > > Cc-ing linux-perf-users@ for any comment from perf people, about the use of
> > > perf event from DAMON.
> >
> > Sorry for the long delay.
> >
> > >
> > > On Fri, 23 Jan 2026 18:39:20 SeongJae Park <sj@kernel.org> wrote:
> > >
> > > > 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.
> >
> > I'm afraid you need to deal with PMU hardware details.  For example
> > PERF_SAMPLE_ADDR may not be available depends on events or sometimes it
> > may not have valid values in some samples like on AMD IBS.  Also hybrid
> > CPUs may not have same events on both CPUs.
> >
> > Maybe it's better to fix which event you want to use on each CPU
> > architecture.
> 
> Thank you for your advice.
> 
> Is it possible to get a list of PMUs that have the ability to get addresses
> (PERF_SAMPLE_ADDR or PERF_SAMPLE_PHYS_ADDR) from the kernel at runtime?

You can lookup 'mem-loads' events on Intel CPUs.  It should be 'cpu',
'cpu_core' and/or 'cpu_atom'.  On AMD, you can use 'ibs_op'.

  $ grep -l . /sys/bus/event_source/devices/*/events/mem-loads
  /sys/bus/event_source/devices/cpu/events/mem-loads

> 
> Or is it possible to detect that a perf_event initialized with a certain
> perf_event_attr does not have the ability to obtain the address?

I don't think so.  IIRC it will just have address of 0 if not supported.

> 
> > > > 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.
> >
> > KVM supports PMU virtualization.  But the existing vPMU support has a
> > lot of overhead.  Recently mediated vPMU patchset was added so you can
> > try that instead.  You'll need to pass appropriate options to qemu.
> >
> > https://lore.kernel.org/lkml/20251206001720.468579-1-seanjc@google.com/
> 
> Thank you for the important information.

No problem!  You may go with the existing vPMU if you just plan to use a
couple of events only.

Thanks,
Namhyung