Re: [RFC PATCH 0/7] mm/damon: hardware-sampled access reports + AMD IBS Op example

[SeongJae Park]

On Mon, 25 May 2026 17:05:06 -0700 Ravi Jonnalagadda <ravis.opensrc@xxxxxxxxx> wrote:

> On Wed, May 20, 2026 at 5:32 PM SeongJae Park <sj@xxxxxxxxxx> wrote:
> >
> > On Wed, 20 May 2026 12:01:43 -0700 Ravi Jonnalagadda <ravis.opensrc@xxxxxxxxx> wrote:
> >
> > > On Mon, May 18, 2026 at 11:19 PM SeongJae Park <sj@xxxxxxxxxx> wrote:
> > > >
> > > > + Akinobu
> > > >
> > > > Hello Ravi,
> > > >
> > > > On Sat, 16 May 2026 15:34:25 -0700 Ravi Jonnalagadda <ravis.opensrc@xxxxxxxxx> wrote:
[...]
> > To my understanding, this RFC reuses the damon_report_access() infrastructure
> > that shared with the per-CPUs/threds/writes/reads monitoring series [1].  My
> > plan at the moment is to keep using it.  So from high level view, I think the
> > final picture would be not really different from this RFC.
> >
> 
> Hi SJ,
> 
>    Sorry for the delayed reply. Was away for a couple of days.

No worry!

> This resolves the layering question for me.

Glad to hear it helps!

[...]
> > I'm still not familiar with IBS and perf events.  Please bear in mind with me.
> > My understanding is that there are vendor-specific knobs for IBS that perf
> > event is not supporting.  So far, that makes sense.  And are you saying that
> > you have to write paddr_ibs as a loadable module if you want to support the
> > vendor-specific knobs?  If I'm understanding you correctly could you further
> > share why it cannot be done as a builtin module?
> >
> 
> This RFC's IBS backend does not claim exclusive use of IBS.
> 
> The reason patch 7 ships as tristate is precedent and reuse: Bharata's
> pghot v5 posted its IBS driver as a module, and I matched that shape
> during development so the two consumers could potentially share IBS
> plumbing instead of duplicating it.  Patches 1 and 2 exist to support
> loadable ops modules generally.

Got it, thank you for clarifying!


Thanks,
SJ

[...]