Re: [RFC PATCH v1.1 11/13] mm/damon/core: remove nr_accesses_bp setups and updates

[SeongJae Park <sj@kernel.org>]

On Sat, 20 Jun 2026 10:45:52 -0700 SeongJae Park <sj@kernel.org> wrote:

> On Sat, 20 Jun 2026 17:34:30 +0000 sashiko-bot@kernel.org wrote:
> 
> > Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
> > - [Low] The `attrs` parameter in `damon_update_region_access_rate()` is completely unused after this patch.
> > --
> > 
> > commit ecb338097e9822ecdcbfa5f88676102211ac76ca
> > Author: SeongJae Park <sj@kernel.org>
> > 
> > mm/damon/core: remove nr_accesses_bp setups and updates
> > 
> > This commit removes the setups and updates of the nr_accesses_bp field
> > in the DAMON core. The field is no longer used for any real purpose and
> > has been replaced by a simpler function.
> > 
> > > diff --git a/mm/damon/core.c b/mm/damon/core.c
> > > index 53568a3c3ad9b..a41b66b26a472 100644
> > > --- a/mm/damon/core.c
> > > +++ b/mm/damon/core.c
> > 
> > [ ... ]
> > 
> > > @@ -3779,18 +3774,6 @@ static unsigned int damon_moving_sum(unsigned int mvsum, unsigned int nomvsum,
> > >  void damon_update_region_access_rate(struct damon_region *r, bool accessed,
> > >  		struct damon_attrs *attrs)
> > >  {
> > > -	unsigned int len_window = 1;
> > > -
> > > -	/*
> > > -	 * sample_interval can be zero, but cannot be larger than
> > > -	 * aggr_interval, owing to validation of damon_set_attrs().
> > > -	 */
> > > -	if (attrs->sample_interval)
> > > -		len_window = damon_max_nr_accesses(attrs);
> > > -	r->nr_accesses_bp = damon_moving_sum(r->nr_accesses_bp,
> > > -			r->last_nr_accesses * 10000, len_window,
> > > -			accessed ? 10000 : 0);
> > > -
> > >  	if (accessed)
> > >  		r->nr_accesses++;
> > >  }
> > 
> > [Severity: Low]
> > Does this leave the attrs parameter completely unused in
> > damon_update_region_access_rate()? 
> > 
> > Since the removal of the damon_moving_sum() logic removes the only use of
> > attrs inside this function, could we also drop the struct damon_attrs *attrs
> > parameter from the signature and its callers to fully clean up the API?
> 
> Good finding.  But not necessarily as a part of this series.  I will add this
> as a todo.

I changed my mind.  I will do this as part of this series in the next revision.


Thanks,
SJ

[...]