lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20250915182652.110173-1-sj@kernel.org>
Date: Mon, 15 Sep 2025 11:26:51 -0700
From: SeongJae Park <sj@...nel.org>
To: Joshua Hahn <joshua.hahnjy@...il.com>
Cc: SeongJae Park <sj@...nel.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	damon@...ts.linux.dev,
	kernel-team@...a.com,
	linux-kernel@...r.kernel.org,
	linux-mm@...ck.org
Subject: Re: [PATCH 1/6] mm/damon/core: reset age if nr_accesses changes between non-zero and zero

On Mon, 15 Sep 2025 07:51:57 -0700 Joshua Hahn <joshua.hahnjy@...il.com> wrote:

> On Sun, 14 Sep 2025 18:58:02 -0700 SeongJae Park <sj@...nel.org> wrote:
> 
> > DAMON resets the age of a region if its nr_accesses value has
> > significantly changed. Specifically, the threshold is calculated as 20%
> > of largest nr_accesses of the current snapshot.  This means that regions
> > changing the nr_accesses from zero to small non-zero value or from a
> > small non-zero value to zero will keep the age.  Since many users treat
> > zero nr_accesses regions special, this can be confusing.  Kernel code
> > including DAMOS' regions priority calculation and DAMON_STAT's idle time
> > calculation also treat zero nr_accesses regions special.  Make it
> > unconfusing by resetting the age when the nr_accesses changes between
> > zero and a non-zero value.
> 
> Hi SJ,
> 
> Thank you for the patch, I think the goal of the patch makes sesne to me.
> I have a small nit / idea which I think makes the code a bit clearer, at least
> for me. It seems that we basically want to XOR the two values's zero-ness, so
> maybe something like 
> 
> (!!r->nr_accesses) ^ (!!r->last_nr_access) or
> (r->nr_accesses == 0) ^ (r->last_nr_access == 0)
> 
> Can achieve the goal?

Thank you for the idea, this makes sense!

> I know bitwise operations are sometimes harder to
> understand, so I am just throwing the idea out there : -) 

To be honest I'm one of people who are not familiar with XOR.  I had to spend a
minute to understand the above.  Maybe we can replace '^' with '!=', and it is
easier to read for me.  If you don't mind, I will use below in the next
version:

   else if ((r->nr_accesses == 0) != (r->last_nr_accesses == 0))

Please let me know if I'm missing something or you have other opinions.

> 
> 
> Anyways, the rest of it looks good to me, please feel free to add my review!
> 
> Reviewed-by: Joshua Hahn <joshua.hahnjy@...il.com>

Thank you!

> 
> > Signed-off-by: SeongJae Park <sj@...nel.org>
> > ---
> >  mm/damon/core.c | 3 +++
> >  1 file changed, 3 insertions(+)
> > 
> > diff --git a/mm/damon/core.c b/mm/damon/core.c
> > index be5942435d78..996647caca02 100644
> > --- a/mm/damon/core.c
> > +++ b/mm/damon/core.c
> > @@ -2261,6 +2261,9 @@ static void damon_merge_regions_of(struct damon_target *t, unsigned int thres,
> >  	damon_for_each_region_safe(r, next, t) {
> >  		if (abs(r->nr_accesses - r->last_nr_accesses) > thres)
> >  			r->age = 0;
> > +		else if ((!r->nr_accesses && r->last_nr_accesses) ||
> > +				(r->nr_accesses && !r->last_nr_accesses))
> > +			r->age = 0;
> >  		else
> >  			r->age++;
> >  
> > -- 
> > 2.39.5
> 
> Sent using hkml (https://github.com/sjp38/hackermail)


Thanks,
SJ

[...]

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ