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

[SeongJae Park <sj@kernel.org>]

On Thu, 19 Feb 2026 15:28:24 +0900 Akinobu Mita <akinobu.mita@gmail.com> wrote:

> 2026年2月19日(木) 0:40 SeongJae Park <sj@kernel.org>:
> >
> > On Wed, 18 Feb 2026 17:20:04 +0900 Akinobu Mita <akinobu.mita@gmail.com> wrote:
> >
> > > 2026年2月18日(水) 0:15 SeongJae Park <sj@kernel.org>:
> > > >
> > > > On Tue, 17 Feb 2026 22:32:43 +0900 Akinobu Mita <akinobu.mita@gmail.com> wrote:
> > > >
> > > > > 2026年2月17日(火) 9:13 SeongJae Park <sj@kernel.org>:
> > [...]
> > > > > > I just posted an RFC patch series [1] for this.  I will drop RFC tag after the
> > > > > > current merge window is finished.  Please let me know if you find something
> > > > > > wrong there!
> > > > > >
> > > > > > [1] https://lore.kernel.org/20260217000400.69056-1-sj@kernel.org
> > > > >
> > > > > Thank you for posting the patch series.
> > > > >
> > > > > I tried it and found that patch 2/3 made things worse than before in terms of
> > > > > monitoring at page size granularity.
> > > >
> > > > Thank you for sharing the test results!
> > > >
> > > > > This is because, in my evaluation, new
> > > > > target processes are added without stopping kdamond, so processes added later
> > > > > are not initially monitored at page size granularity.
> > > >
> > > > Nice catch.  But, the min_nr_regions based region split of vaddr was triggered
> > > > by damon_va_init(), which is called before the kdamond_fn()'s main loop.  How
> > > > the regions were split before the patch?  Probably I'm missing something.
> > > > Could you please clarify?
> > >
> > > Before applying PATCH 2/3 ("mm/damon/vaddr: do not split regions for
> > > min_nr_regions"), the damon regions of processes newly added to the monitoring
> > > targets after kdamond started were split by damon_va_evenly_split_region().
> >
> > Thank you for adding this explanation.  But, damon_va_evenly_split_region() is
> > called by only __damon_va_init_regions(), which is again called by only
> > damon_va_init().  And damon_va_init() is called from kdamond_fn(), only at the
> > beginning, before starting the main loop.  If you add new monitoring targets
> > after kdamond started and therefore the damon_va_init() is called,
> > damon_va_init() cannot be called again.  So damon_va_evenly_split_region() is
> > also not called.  I confirmed this using damo like below:
> >
> >     $ sudo damo start --target_pid $$ --monitoring_intervals 1s 5s 10s
> >     $ sudo damo tune --target_pid $$ --target_pid $other_process_pid \
> >             --monitoring_intervals 1s 5s 10s \
> >             --monitoring_nr_regions_range 20 1000
> >
> > While running the command, I monitor the number of regions of targets using
> > damon:damon_aggregated trace event, and confirmed the initial region is evenly
> > split, but the new monitoring target regions that added by the second command
> > is not evenly split from the beginning.
> >
> > Am I missing something?
> 
> Your explanation is correct.
> It was only my own internal changes that were affecting it (calling ops.init()
> from damon_commit_ctx()).
> 
> https://lore.kernel.org/damon/20260123021014.26915-2-akinobu.mita@gmail.com/

Makes sense, thank you for clarifying this!

> 
> So the current patch series hasn't made things worse. Sorry for the mistake.

Glad to hear that.  I will post the series without RFC after the current merge
window.  I will also try to make the planned followup for respecting the
min_nr_regions for the online-added targets and updated min_nr_regions before
the next merge window.


Thanks,
SJ

[...]