Re: [PATCH 6.18.y v2] mm/damon/core: disallow time-quota setting zero esz

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] Incomplete fix: DAMOS scheme can still unexpectedly deactivate if using quota goals without a time quota.
--

commit ce7d104c8087fff14fb782b89848659312c204fa
Author: SeongJae Park <sj@kernel.org>
Subject: mm/damon/core: disallow time-quota setting zero esz

This commit addresses an issue where DAMOS time quota can reduce the
effective size quota below the minimum region size. This causes no actions
to be applied, unexpectedly deactivating the scheme. The fix enforces a
lower bound of min_sz_region on the effective size quota when a time quota
is used.

Link: https://lore.kernel.org/20260407003153.79589-1-sj@kernel.org
Link: https://lore.kernel.org/20260405192504.110014-1-sj@kernel.org [1]

> diff --git a/mm/damon/core.c b/mm/damon/core.c
> index 87b6c9c2d6471..feec1b0c2babe 100644
> --- a/mm/damon/core.c
> +++ b/mm/damon/core.c
[ ... ]
> @@ -2150,6 +2151,7 @@ static void damos_set_effective_quota(struct damos_quota *quota)
>  		else
>  			throughput = PAGE_SIZE * 1024;
>  		esz = min(throughput * quota->ms, esz);
> +		esz = max(ctx->min_sz_region, esz);
>  	}
>  
>  	if (quota->sz && quota->sz < esz)

Could this still leave a case where the scheme is unexpectedly deactivated
if quota goals are used without a time quota?

If a scheme is configured with quota goals (!list_empty(&quota->goals)) but
no time quota (quota->ms == 0), the bounds check added here inside the
if (quota->ms) block is bypassed.

When the system metric over-achieves, the feedback loop in
damon_feed_loop_next_input() can limit quota->esz_bp to its minimum of
10000, which evaluates to an esz of 1:

	if (!list_empty(&quota->goals)) {
		unsigned long score = damos_quota_score(quota);

		quota->esz_bp = damon_feed_loop_next_input(
				max(quota->esz_bp, 10000UL),
				score);
		esz = quota->esz_bp / 10000;
	}

During scheme application, damos_apply_scheme() calculates the size using
ALIGN_DOWN(1 - 0, ctx->min_sz_region). Since min_sz_region is typically
PAGE_SIZE, this evaluates to 0 and the action is skipped entirely.

Because the feedback loop increases esz_bp multiplicatively, it would take
multiple charge windows for esz to grow from 1 back to min_sz_region after
the score drops. During this period, the scheme applies 0 actions despite
the score indicating they are needed.

Should the max(ctx->min_sz_region, esz) bound be applied outside the
if (quota->ms) block to ensure any auto-tuned esz is properly bounded?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260506165211.10410-1-sj@kernel.org?part=1