All of lore.kernel.org
 help / color / mirror / Atom feed
From: Namhyung Kim <namhyung@kernel.org>
To: Akinobu Mita <akinobu.mita@gmail.com>
Cc: SeongJae Park <sj@kernel.org>,
	damon@lists.linux.dev, linux-perf-users@vger.kernel.org
Subject: Re: [RFC PATCH 0/4] mm/damon: introduce perf event based access check
Date: Wed, 25 Feb 2026 17:24:56 -0800	[thread overview]
Message-ID: <aZ-g6AfzY5xhtR6U@google.com> (raw)
In-Reply-To: <CAC5umygJNCxbDwbTPc3FFRAO+sfHyxx=QSXXF9g2TSiQ4Bvw=Q@mail.gmail.com>

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


  reply	other threads:[~2026-02-26  1:24 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 ` [RFC PATCH 0/4] mm/damon: introduce perf event based access check SeongJae Park
2026-01-24  2:48   ` SeongJae Park
2026-02-23  8:08     ` Namhyung Kim
2026-02-25  6:48       ` Akinobu Mita
2026-02-26  1:24         ` Namhyung Kim [this message]
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=aZ-g6AfzY5xhtR6U@google.com \
    --to=namhyung@kernel.org \
    --cc=akinobu.mita@gmail.com \
    --cc=damon@lists.linux.dev \
    --cc=linux-perf-users@vger.kernel.org \
    --cc=sj@kernel.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.