From: SeongJae Park <sj@kernel.org>
To: niecheng <niecheng1@uniontech.com>
Cc: SeongJae Park <sj@kernel.org>,
akpm@linux-foundation.org, damon@lists.linux.dev,
linux-mm@kvack.org, linux-kernel@vger.kernel.org,
kernel@uniontech.com
Subject: Re: [PATCH] mm/damon/core: recalculate intervals tuning deadline on attrs update
Date: Thu, 14 May 2026 07:41:02 -0700 [thread overview]
Message-ID: <20260514144102.120203-1-sj@kernel.org> (raw)
In-Reply-To: <7946CE4E0773AEF7+20260514074846.3258908-1-niecheng1@uniontech.com>
Hello Nicheng,
On Thu, 14 May 2026 15:48:46 +0800 niecheng <niecheng1@uniontech.com> wrote:
> damon_set_attrs() refreshes next_aggregation_sis and
> next_ops_update_sis for online monitoring attribute updates, but it
> does not refresh next_intervals_tune_sis.
>
> Because of that, enabling intervals auto-tuning via an online attrs
> commit can leave next_intervals_tune_sis stale. If a context starts
> with intervals_goal.aggrs == 0 and later updates attrs online to set it
> non-zero, kdamond_fn() can treat the tuning deadline as already expired
> and tune the intervals earlier than intended.
>
> This has been possible since the intervals auto-tuning feature was
> introduced, because that commit initialized the deadline at kdamond
> start but did not refresh it on later attrs updates.
Good finding, thank you for sharing this!
But, the next_interval_tune_sis will be updated based on the updated
aggregation and sampling intervals, just before the next intervals tuning is
made.
In detail, the code flow of the kdamond_fn() main loop is like below:
- call kdamond_call()
- call damon_set_attrs()
- update aggregation and sampling intervals
- if passed_ample_intervals >= next_intervals_tune_sis:
- update next_intervals_tune_sis with updated aggregation and sampling
intervals
- call kdamond_tune_intervals()
So, the old next_intervals_tune_sis will be used only once. I agree not
everyone will think it is the best behavior. But seems ok to me. I'd like to
keep the current code in favor of less complexity. What do you think?
Nevertheless, apparently the code can better be documented. Maybe it is worthy
to add a comment about this. For example, maybe it is better to add a comment
saying "next_intervals_tune_sis will be updated inside kdamond_fn()" on the
damon_set_attrs(). If you'd like to, please feel free to post such a patch.
Thanks,
SJ
[...]
next prev parent reply other threads:[~2026-05-14 14:41 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-05-14 7:48 [PATCH] mm/damon/core: recalculate intervals tuning deadline on attrs update niecheng
2026-05-14 14:41 ` SeongJae Park [this message]
2026-05-14 16:15 ` niecheng
2026-05-14 16:37 ` [PATCH] mm/damon/core: clarify next_intervals_tune_sis update path niecheng
2026-05-14 23:45 ` SeongJae Park
2026-05-15 1:17 ` niecheng
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=20260514144102.120203-1-sj@kernel.org \
--to=sj@kernel.org \
--cc=akpm@linux-foundation.org \
--cc=damon@lists.linux.dev \
--cc=kernel@uniontech.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=niecheng1@uniontech.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox