DAMON traces effective size quota from the second update, only if a
change has been made by the update.  Tracing only changed updates was an
intentional decision to avoid unnecessary same value tracing.  Always
skipping the first value is just an unintended mistake.

The mistake makes the tracepoint based investigation incomplete, because
the first effective size quota is never traced.  It is not a big issue
when the 'consist' quota tuner is used, because it keeps changing the
quota in the usual setup.

However, when the 'temporal' tuner is used, the quota value is not
changed before the goal achievement status is completely changed.  For
example, if the DAMOS scheme is started with an under-achieved goal, the
quota is set to the maximum value, and kept the same value until the
goal is achieved.  Because DAMON skips the first value, the user cannot
know what effective quota the current scheme is using.  Only after the
goal is achieved, the effective quota is changed to zero, and traced.

Unconditionally trace the initial quota value to fix this problem.

Note that the 'temporal' quota tuner was introduced by commit
af738a6a00c1 ("mm/damon/core: introduce
DAMOS_QUOTA_GOAL_TUNER_TEMPORAL"), which was added to 7.1-rc1.  But even
with the 'consist' quota tuner, the tracing is unintentionally
incomplete. Hence this commit marks the introduction of the trace event
as the broken commit.

Fixes: a86d695193bf ("mm/damon: add trace event for effective size quota")
Cc: <stable@vger.kernel.org> # 6.17.x
Signed-off-by: SeongJae Park <sj@kernel.org>
---
Changes from RFC
- RFC: https://lore.kernel.org/20260520005940.92003-1-sj@kernel.org
- Drop RFC tag.

 mm/damon/core.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/mm/damon/core.c b/mm/damon/core.c
index 4e223857a0f99..0db6530825d1d 100644
--- a/mm/damon/core.c
+++ b/mm/damon/core.c
@@ -2883,6 +2883,8 @@ static void damos_adjust_quota(struct damon_ctx *c, struct damos *s)
 	if (!quota->total_charged_sz && !quota->charged_from) {
 		quota->charged_from = jiffies;
 		damos_set_effective_quota(c, s);
+		if (trace_damos_esz_enabled())
+			damos_trace_esz(c, s, quota);
 	}
 
 	/* New charge window starts */

base-commit: 796dd9092b9c9d93dd48213582d45c43e93fa187
-- 
2.47.3

On Wed, 20 May 2026 08:03:10 -0700 SeongJae Park <sj@kernel.org> wrote:

> DAMON traces effective size quota from the second update, only if a
> change has been made by the update.  Tracing only changed updates was an
> intentional decision to avoid unnecessary same value tracing.  Always
> skipping the first value is just an unintended mistake.
> 
> The mistake makes the tracepoint based investigation incomplete, because
> the first effective size quota is never traced.  It is not a big issue
> when the 'consist' quota tuner is used, because it keeps changing the
> quota in the usual setup.
> 
> However, when the 'temporal' tuner is used, the quota value is not
> changed before the goal achievement status is completely changed.  For
> example, if the DAMOS scheme is started with an under-achieved goal, the
> quota is set to the maximum value, and kept the same value until the
> goal is achieved.  Because DAMON skips the first value, the user cannot
> know what effective quota the current scheme is using.  Only after the
> goal is achieved, the effective quota is changed to zero, and traced.
> 
> Unconditionally trace the initial quota value to fix this problem.
> 
> Note that the 'temporal' quota tuner was introduced by commit
> af738a6a00c1 ("mm/damon/core: introduce
> DAMOS_QUOTA_GOAL_TUNER_TEMPORAL"), which was added to 7.1-rc1.  But even
> with the 'consist' quota tuner, the tracing is unintentionally
> incomplete. Hence this commit marks the introduction of the trace event
> as the broken commit.

OK, but...

> Fixes: a86d695193bf ("mm/damon: add trace event for effective size quota")
> Cc: <stable@vger.kernel.org> # 6.17.x
> Signed-off-by: SeongJae Park <sj@kernel.org>

The patch is marked for backporting but it assumes the presence of
"mm/damon/core: make charge_addr_from aware of end-address
exclusivity", which is queued for 7.2-rc1.

We can either redo this against current -linus and fix up mm.git's
"mm/damon/core: make charge_addr_from aware of end-address exclusivity"
or we can queue this for 7.2-rc1 and you get to deal with fallout when
-stable maintainers hit issues backporting this.

Preferences?

On Thu, 21 May 2026 16:28:34 -0700 Andrew Morton <akpm@linux-foundation.org> wrote:

> On Wed, 20 May 2026 08:03:10 -0700 SeongJae Park <sj@kernel.org> wrote:
> 
> > DAMON traces effective size quota from the second update, only if a
> > change has been made by the update.  Tracing only changed updates was an
> > intentional decision to avoid unnecessary same value tracing.  Always
> > skipping the first value is just an unintended mistake.
> > 
> > The mistake makes the tracepoint based investigation incomplete, because
> > the first effective size quota is never traced.  It is not a big issue
> > when the 'consist' quota tuner is used, because it keeps changing the
> > quota in the usual setup.
> > 
> > However, when the 'temporal' tuner is used, the quota value is not
> > changed before the goal achievement status is completely changed.  For
> > example, if the DAMOS scheme is started with an under-achieved goal, the
> > quota is set to the maximum value, and kept the same value until the
> > goal is achieved.  Because DAMON skips the first value, the user cannot
> > know what effective quota the current scheme is using.  Only after the
> > goal is achieved, the effective quota is changed to zero, and traced.
> > 
> > Unconditionally trace the initial quota value to fix this problem.
> > 
> > Note that the 'temporal' quota tuner was introduced by commit
> > af738a6a00c1 ("mm/damon/core: introduce
> > DAMOS_QUOTA_GOAL_TUNER_TEMPORAL"), which was added to 7.1-rc1.  But even
> > with the 'consist' quota tuner, the tracing is unintentionally
> > incomplete. Hence this commit marks the introduction of the trace event
> > as the broken commit.
> 
> OK, but...
> 
> > Fixes: a86d695193bf ("mm/damon: add trace event for effective size quota")
> > Cc: <stable@vger.kernel.org> # 6.17.x
> > Signed-off-by: SeongJae Park <sj@kernel.org>
> 
> The patch is marked for backporting but it assumes the presence of
> "mm/damon/core: make charge_addr_from aware of end-address
> exclusivity", which is queued for 7.2-rc1.
> 
> We can either redo this against current -linus and fix up mm.git's
> "mm/damon/core: make charge_addr_from aware of end-address exclusivity"
> or we can queue this for 7.2-rc1 and you get to deal with fallout when
> -stable maintainers hit issues backporting this.
> 
> Preferences?

Either is ok.  Because this fix is not urgent to my perspective, I'd pick the
second option.  Let me know if you need anything from my side.


Thanks,
SJ

[...]