From: sashiko-bot@kernel.org
To: "Liew Rui Yan" <aethernet65535@gmail.com>
Cc: damon@lists.linux.dev
Subject: Re: [PATCH] mm/damon/core: fix quota could not be set to zero
Date: Tue, 01 Sep 2026 11:14:40 +0000 [thread overview]
Message-ID: <20260901111440.A39471F00A3E@smtp.kernel.org> (raw)
In-Reply-To: <20260901105951.106246-1-aethernet65535@gmail.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] The patch places the `if (esz)` check after the throughput calculation, inadvertently reverting a previous fix (commit 8bbde987c2b8) and causing schemes with low throughput to permanently deactivate.
--
commit a1511f591a76665e55c325a03d3d47bf4ba87dc6
Author: Liew Rui Yan <aethernet65535@gmail.com>
mm/damon/core: fix quota could not be set to zero
This commit modifies the damos quota setting logic to skip clamping to
min_region_sz when the effective size quota is already zero. This is
intended to allow the temporal tuner's zero quota goal to be respected.
> diff --git a/mm/damon/core.c b/mm/damon/core.c
> index 3f89cfdf5f022..fdec7c0fe913a 100644
> --- a/mm/damon/core.c
> +++ b/mm/damon/core.c
> @@ -3122,7 +3122,8 @@ static void damos_set_effective_quota(struct damon_ctx *ctx, struct damos *s)
> else
> throughput = PAGE_SIZE * 1024;
> esz = min(throughput * quota->ms, esz);
> - esz = max(ctx->min_region_sz, esz);
> + if (esz)
> + esz = max(ctx->min_region_sz, esz);
[Severity: High]
Does placing the if (esz) check after the throughput calculation inadvertently
revert the fix from commit 8bbde987c2b8 and cause a regression where slow
schemes permanently deactivate?
If a damos scheme with a time quota processes regions slowly, integer division
can cause throughput to truncate to 0. When this happens, the calculation
esz = min(throughput * quota->ms, esz) evaluates to 0.
Because the new if (esz) check is placed after this min() calculation, the 0
value causes the check to fail, skipping the max(ctx->min_region_sz, esz)
clamp.
With esz == 0, damos_quota_is_full() always returns true, bypassing all
scheme operations. Since no regions are processed, total_charged_ns and
total_charged_sz are never updated. This leaves throughput permanently at 0,
resulting in an unrecoverable starvation loop.
> }
>
> if (quota->sz && quota->sz < esz)
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260901105951.106246-1-aethernet65535@gmail.com?part=1
next prev parent reply other threads:[~2026-09-01 11:14 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-01 10:59 [PATCH] mm/damon/core: fix quota could not be set to zero Liew Rui Yan
2026-09-01 11:14 ` sashiko-bot [this message]
2026-09-01 12:40 ` Liew Rui Yan
2026-09-02 1:04 ` SJ Park
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=20260901111440.A39471F00A3E@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=aethernet65535@gmail.com \
--cc=damon@lists.linux.dev \
--cc=sashiko-reviews@lists.linux.dev \
/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.