DAMON development mailing list
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "SeongJae Park" <sj@kernel.org>
Cc: damon@lists.linux.dev
Subject: Re: [PATCH] mm/damon/core: make charge_addr_from aware of end-address exclusivity
Date: Tue, 28 Apr 2026 05:49:03 +0000	[thread overview]
Message-ID: <20260428054903.A6110C2BCAF@smtp.kernel.org> (raw)
In-Reply-To: <20260428042942.118230-1-sj@kernel.org>

Sashiko AI review found 3 potential issue(s):
- [High] The remainder of the last region of a target is unconditionally skipped during quota resumption.
- [High] Quota state is not saved when the remaining quota is less than `min_region_sz`, breaking round-robin fairness.
- [Medium] Setting `charge_addr_from = r->ar.end` causes resumption failure when a region covers the end of the address space.
--

commit 50bbd8d578080e27beac4fe1ad0cecbb013a8fd7
Author: SeongJae Park <sj@kernel.org>

mm/damon/core: make charge_addr_from aware of end-address exclusivity

This commit updates the DAMOS quota charge assignment to use the exclusive
region end address rather than assuming it is inclusive. This addresses a
bug where the action might skip the next memory block up to min_region_sz.

Link: https://lore.kernel.org/20260428032324.115663-1-sj@kernel.org

> diff --git a/mm/damon/core.c b/mm/damon/core.c
> index 3dbbbfdeff71..901ffdaefb7f 100644
> --- a/mm/damon/core.c
> +++ b/mm/damon/core.c
> @@ -2106,7 +2106,7 @@ static void damos_apply_scheme(struct damon_ctx *c, struct damon_target *t,
>  		if (damos_quota_is_set(quota) &&
>  				quota->charged_sz >= quota->esz) {
>  			quota->charge_target_from = t;
> -			quota->charge_addr_from = r->ar.end + 1;
> +			quota->charge_addr_from = r->ar.end;

Does this cause a resumption failure if the region covers the absolute end of
the address space?

If r->ar.end wraps to 0 (e.g., ULONG_MAX + 1), charge_addr_from is assigned
0. Since DAMON uses 0 as a sentinel value for an uninitialized state, the
checks for quota->charge_addr_from in damos_skip_charged_region() will
evaluate to false.

Will this completely fail to identify the resumption point, prematurely clear
the state, and restart from the first region instead of resuming?

Additionally, this isn't a bug introduced by this patch, but does the
resuming logic unconditionally skip the remainder of the last region of
a target?

In damos_skip_charged_region(), the damon_last_region() check executes before
evaluating charge_addr_from:

mm/damon/core.c:damos_skip_charged_region() {
    ...
	if (quota->charge_target_from) {
		if (t != quota->charge_target_from)
			return true;
		if (r == damon_last_region(t)) {
			quota->charge_target_from = NULL;
			quota->charge_addr_from = 0;
			return true;
		}
        ...
}

If a target's last region is partially charged and split during a window, the
uncharged remainder becomes the new damon_last_region. In the next quota
window, when the loop reaches this remainder, will it immediately match the
last region check, clear the state, and permanently starve the end of targets
by returning true (skip)?

Finally, this isn't a bug introduced by this patch, but is the quota state
lost when the remaining quota is less than min_region_sz?

Earlier in damos_apply_scheme(), if the remaining quota is small:

mm/damon/core.c:damos_apply_scheme() {
    ...
		if (damos_quota_is_set(quota) &&
				quota->charged_sz + sz > quota->esz) {
			sz = ALIGN_DOWN(quota->esz - quota->charged_sz,
					c->min_region_sz);
			if (!sz)
				goto update_stat;
    ...
}

Does the goto update_stat bypass incrementing quota->charged_sz and saving
charge_target_from and charge_addr_from?

Because charged_sz never reaches esz, the loop will uselessly evaluate all
remaining regions. Because the resume state is never saved, will the next
interval incorrectly restart from the very first target and region, breaking
round-robin fairness and starving later regions whenever the dynamically
calculated quota is not perfectly aligned?

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

  reply	other threads:[~2026-04-28  5:49 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-04-28  4:29 [PATCH] mm/damon/core: make charge_addr_from aware of end-address exclusivity SeongJae Park
2026-04-28  5:49 ` sashiko-bot [this message]
2026-04-28  6:48   ` SeongJae 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=20260428054903.A6110C2BCAF@smtp.kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=damon@lists.linux.dev \
    --cc=sashiko@lists.linux.dev \
    --cc=sj@kernel.org \
    /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