All of lore.kernel.org
 help / color / mirror / Atom feed
From: SeongJae Park <sj@kernel.org>
To: SeongJae Park <sj@kernel.org>
Cc: Quanmin Yan <yanquanmin1@huawei.com>,
	akpm@linux-foundation.org, damon@lists.linux.dev,
	linux-kernel@vger.kernel.org, linux-mm@kvack.org,
	wangkefeng.wang@huawei.com, zuoze1@huawei.com
Subject: Re: [PATCH] mm/damon/stat: set last_refresh_jiffies to jiffies at startup
Date: Tue, 28 Oct 2025 18:30:36 -0700	[thread overview]
Message-ID: <20251029013038.66625-1-sj@kernel.org> (raw)
In-Reply-To: <20251028143250.50144-1-sj@kernel.org>

On Tue, 28 Oct 2025 07:32:49 -0700 SeongJae Park <sj@kernel.org> wrote:

> On Tue, 28 Oct 2025 07:19:14 -0700 SeongJae Park <sj@kernel.org> wrote:
> 
> > On Tue, 28 Oct 2025 14:19:27 +0800 Quanmin Yan <yanquanmin1@huawei.com> wrote:
> > 
> > > In DAMON_STAT's damon_stat_damon_call_fn(), time_before_eq() is used to
> > > avoid unnecessarily frequent stat update.
> > > 
> > > On 32-bit systems, the kernel initializes jiffies to "-5 minutes" to make
> > > jiffies wrap bugs appear earlier. However, this causes time_before_eq()
> > > in DAMON_STAT to unexpectedly return true during the first 5 minutes
> > > after boot on 32-bit systems (see [1] for more explanation, which fixes
> > > another jiffies-related issue in DAMON). As a result, DAMON_STAT does not
> > > update any monitoring results during that period, which can be more
> > > confusing when DAMON_STAT_ENABLED_DEFAULT is enabled.
> > > 
> > > Fix it by setting last_refresh_jiffies to jiffies at startup.
> > 
> > Nice catch, thank you for this patch!
> > 
> > > 
> > > [1] https://lkml.kernel.org/r/20250822025057.1740854-1-ekffu200098@gmail.com
> > > 
> > > Fixes: fabdd1e911da ("mm/damon/stat: calculate and expose estimated memory bandwidth")
> > > Signed-off-by: Quanmin Yan <yanquanmin1@huawei.com>
> > > ---
> > >  mm/damon/stat.c | 3 +++
> > >  1 file changed, 3 insertions(+)
> > > 
> > > diff --git a/mm/damon/stat.c b/mm/damon/stat.c
> > > index 6c4503d2aee3..6dc3e18de910 100644
> > > --- a/mm/damon/stat.c
> > > +++ b/mm/damon/stat.c
> > > @@ -132,6 +132,9 @@ static int damon_stat_damon_call_fn(void *data)
> > >  	struct damon_ctx *c = data;
> > >  	static unsigned long last_refresh_jiffies;
> > >  
> > > +	if (unlikely(!last_refresh_jiffies))
> > > +		last_refresh_jiffies = jiffies;
> > > +
> > 
> > How about doing the initialization together with the declaration?  E.g.,
> > 
> >  static int damon_stat_damon_call_fn(void *data)
> >  {
> >         struct damon_ctx *c = data;
> > -       static unsigned long last_refresh_jiffies;
> > +       static unsigned long last_refresh_jiffies = jiffies;

Please ignore the above suggestion.  It will even not build, like below...

.../mm/damon/stat.c: In function ‘damon_stat_damon_call_fn’:
.../mm/damon/stat.c:133:53: error: initializer element is not constant
  133 |         static unsigned long last_refresh_jiffies = jiffies;
      |                                                     ^~~~~~~

> 
> Actually, a similar issue can happen again if DAMON_STAT is stopped and
> restarted by user.  That is, if user stops DAMON_STAT just after
> last_refresh_jiffies is updated, and restart it after 5 seconds or more, the
> time_before_eq() on damon_call_fn() will return true, so stat updates will
> happen earlier than expected.  Shouldn't be a real problem, but better to avoid
> if possible.
> 
> How about making last_refresh_jiffies a global variable and initialize it on
> damon_stat_start()?  To avoid unnecessary name conflicts, the variable name
> would also better to be changed, e.g., damon_stat_last_refresh_jiffies.

But, please consider the above one.

And I just realized a similar issue exist for next_update_jiffies in
mm/damon/sysfs.c file.  Please feel free to send a patch for that if you
willing to.


Thanks,
SJ

[...]

  reply	other threads:[~2025-10-29  1:30 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-10-28  6:19 [PATCH] mm/damon/stat: set last_refresh_jiffies to jiffies at startup Quanmin Yan
2025-10-28 14:19 ` SeongJae Park
2025-10-28 14:32   ` SeongJae Park
2025-10-29  1:30     ` SeongJae Park [this message]
2025-10-29  2:02       ` Quanmin Yan
2025-10-29  1:32   ` Quanmin Yan

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20251029013038.66625-1-sj@kernel.org \
    --to=sj@kernel.org \
    --cc=akpm@linux-foundation.org \
    --cc=damon@lists.linux.dev \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=wangkefeng.wang@huawei.com \
    --cc=yanquanmin1@huawei.com \
    --cc=zuoze1@huawei.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.