Re: [PATCH] mm/damon/core: recalculate intervals tuning deadline on attrs update

[聂诚 <niecheng1@uniontech.com>]

[-- Attachment #1: Type: text/plain, Size: 2953 bytes --]

Hi SJ,


You are right.


I rechecked kdamond_fn(), and what I observed is a one-shot earlier
intervals tuning after the online update, rather than a persistent
stale-deadline bug.


So I will drop my previous patch and send a small follow-up comment
patch for this subtle behavior.


Thanks,
Niecheng




------------------ Original ------------------
From: &nbsp;"SeongJae&nbsp;Park"<sj@kernel.org&gt;;
Date: &nbsp;Thu, May 14, 2026 10:41 PM
To: &nbsp;"niecheng"<niecheng1@uniontech.com&gt;; 
Cc: &nbsp;"SeongJae Park"<sj@kernel.org&gt;; "akpm"<akpm@linux-foundation.org&gt;; "damon"<damon@lists.linux.dev&gt;; "linux-mm"<linux-mm@kvack.org&gt;; "linux-kernel"<linux-kernel@vger.kernel.org&gt;; "kernel"<kernel@uniontech.com&gt;; 
Subject: &nbsp;Re: [PATCH] mm/damon/core: recalculate intervals tuning deadline on attrs update

&nbsp;

Hello Nicheng,

On Thu, 14 May 2026 15:48:46 +0800 niecheng <niecheng1@uniontech.com&gt; wrote:

&gt; damon_set_attrs() refreshes next_aggregation_sis and
&gt; next_ops_update_sis for online monitoring attribute updates, but it
&gt; does not refresh next_intervals_tune_sis.
&gt; 
&gt; Because of that, enabling intervals auto-tuning via an online attrs
&gt; commit can leave next_intervals_tune_sis stale.&nbsp; If a context starts
&gt; with intervals_goal.aggrs == 0 and later updates attrs online to set it
&gt; non-zero, kdamond_fn() can treat the tuning deadline as already expired
&gt; and tune the intervals earlier than intended.
&gt; 
&gt; This has been possible since the intervals auto-tuning feature was
&gt; introduced, because that commit initialized the deadline at kdamond
&gt; 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()
&nbsp; - call damon_set_attrs()
&nbsp;&nbsp;&nbsp; - update aggregation and sampling intervals
- if passed_ample_intervals &gt;= next_intervals_tune_sis:
&nbsp; - update next_intervals_tune_sis with updated aggregation and sampling
&nbsp;&nbsp;&nbsp; intervals
&nbsp; - call kdamond_tune_intervals()

So, the old next_intervals_tune_sis will be used only once.&nbsp; I agree not
everyone will think it is the best behavior.&nbsp; But seems ok to me.&nbsp; I'd like to
keep the current code in favor of less complexity.&nbsp; What do you think?

Nevertheless, apparently the code can better be documented.&nbsp; Maybe it is worthy
to add a comment about this.&nbsp; 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().&nbsp; If you'd like to, please feel free to post such a patch.


Thanks,
SJ

[...]

[-- Attachment #2: Type: text/html, Size: 3683 bytes --]