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

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

> After applying PATCH 2/3, the call to damon_va_evenly_split_region() is
> omitted, so those new processes are monitored by larger damon regions.

So I'm still not understanding why you saying this.

> 
> > > Would performing a split operation like damon_apply_min_nr_regions() within
> > > damon_set_regions() solve the problem?
> >
> > Yes, that's the plan.  The split operation should be done for online updates of
> > total size of monitoring regions and min_nr_regions.  I'm preparing a followup
> > patch series for that.  While working on it, however, I found it requires some
> > refactoring and cleanup that taking time longer than I expected.  Meanwhile I
> > was thinking your issue is only at the beginning of kdamond, and I didn't want
> > to make you wait too long.  Hence posted the series first.
> 
> I see, thank you for the work.
> 
> In another evaluation using paddr, no new damon regions are added after kdamond
> is started, so applying the current patch series enabled monitoring at page
> size granularity.

Glad to hear that it helps the case!


Thanks,
SJ