Re: [RFC PATCH v1.1 11/16] mm/damon/core: get merge threshold from probe hits when weights are set

[SJ Park <sj@kernel.org>]

On Mon,  6 Jul 2026 17:03:28 -0700 SJ Park <sj@kernel.org> wrote:

> On Mon, 06 Jul 2026 15:18:01 +0000 sashiko-bot@kernel.org wrote:
> 
> > Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
> > - [High] Region merge loop terminates prematurely because `max_thres` is unscaled for probe hit weighted sums, causing a failure to respect `max_nr_regions`.
> > - [High] Adding probe weights to contexts using operations without `apply_probes` (e.g., `vaddr`) silently breaks all monitoring.
> > --
> > 
> > commit f896f3e81bf75b446b16cb4f79f6673a154b512b
> > Author: SJ Park <sj@kernel.org>
> > 
> > mm/damon/core: get merge threshold from probe hits when weights are set
> >     
> > When probe weights are set, DAMON merges regions based on their probe
> > hits weighted sum.  But the merge threshold is calculated based on the
> > access frequency.  Update it to retrieve the maximum probe hits weighted
> > sum in the snapshot from apply_probes() ops callback, and generate the
> > threshold based on it.
> > 
> > > diff --git a/mm/damon/core.c b/mm/damon/core.c
> > > index be026c86384e4..fa78d8d592aa3 100644
> > > --- a/mm/damon/core.c
> > > +++ b/mm/damon/core.c
> > [ ... ]
> > > @@ -3726,9 +3727,18 @@ static int kdamond_fn(void *data)
> > >  
> > >  		if (!access_check_disabled && ctx->ops.check_accesses)
> > >  			max_merge_score = ctx->ops.check_accesses(ctx);
> > 
> > [Severity: High]
> > Does setting probe weights on a context that lacks an apply_probes callback
> > (like vaddr) silently break monitoring here?
> > 
> > If a user sets probe weights via sysfs, access_check_disabled will be true.
> > This skips check_accesses(), but since apply_probes is NULL, neither callback
> > runs. The accesses are never updated, and all memory appears completely cold.
> 
> I was initially thinking this is no blocker.  But, since the core layer params
> validation patch series is merged into mm-new, fixing this should be simple,
> and we don't really need to rush for this series.  I will fix this in the next
> spin.

I changed my mind.  There are many features that supported by only specific
DAMON ops implementations.  We allow setting such configuration, and later add
supports if needed.  It is arguable, but I think keeping the consistency is the
right thing for now.  I will keep this behavior unless someone argues
differently.


Thanks,
SJ

[...]