From: sashiko-bot@kernel.org
To: "Ravi Jonnalagadda" <ravis.opensrc@gmail.com>
Cc: damon@lists.linux.dev
Subject: Re: [RFC PATCH v4 8/9] mm/damon/core: cap the region merge threshold per target
Date: Mon, 05 Oct 2026 08:58:10 +0000 [thread overview]
Message-ID: <20261005085810.A87BE1F000FF@smtp.kernel.org> (raw)
In-Reply-To: <20261005-damon-perf-rfc-v3-send-2026-10-03-v4-8-b03452e137f3@gmail.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] mm/damon: integer truncation in max_thres bounds calculation
--
commit a10e8369d2fd5c44226b6327f0cddd983be70366
Author: Ravi Jonnalagadda <ravis.opensrc@gmail.com>
mm/damon/core: cap the region merge threshold per target
This commit modifies kdamond_merge_regions to cap the merge threshold for each
target individually during the regular merge pass. It also adjusts the
maximum threshold for probe-weighted contexts to ensure escalation passes
continue to run even when weighted hits exceed the normal maximum threshold.
[ ... ]
> diff --git a/mm/damon/core.c b/mm/damon/core.c
> index e3c29d7cff23d..7c0df07f0a908 100644
> --- a/mm/damon/core.c
> +++ b/mm/damon/core.c
> @@ -4167,12 +4167,40 @@ static noinline_for_stack void kdamond_merge_regions(struct damon_ctx *c,
> unsigned int nr_regions;
> unsigned int max_thres;
> bool count_age = true;
> + bool use_probe_hits = damon_has_probe_weights(c);
>
> max_thres = damon_nr_samples_per_aggr(&c->attrs);
> + /* weighted scores can exceed max_thres; threshold is max score / 10 */
> + if (use_probe_hits)
> + max_thres = max(threshold * 10, max_thres);
[Severity: Medium]
When the true maximum merge score is not a multiple of 10, does this
calculation cause max_nr_regions to be violated?
Because kdamond_fn() calculates the initial threshold by dividing
max_merge_score by 10, the remainder is discarded:
mm/damon/core.c:kdamond_fn() {
...
kdamond_merge_regions(ctx, max_merge_score / 10, sz_limit);
...
}
When kdamond_merge_regions() attempts to restore the max_thres ceiling
via threshold * 10, it loses the remainder (e.g., a max score of 29
yields threshold 2, restoring a ceiling of 20 instead of 29).
Will the escalation loop then terminate prematurely when it reaches 20,
leaving regions with score differences up to 29 unmerged and the total
region count above the configured limit?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20261005-damon-perf-rfc-v3-send-2026-10-03-v4-0-b03452e137f3@gmail.com?part=8
next prev parent reply other threads:[~2026-10-05 8:58 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-05 8:46 [RFC PATCH v4 0/9] mm/damon: hardware-sampled access reports Ravi Jonnalagadda
2026-10-05 8:46 ` [RFC PATCH v4 1/9] mm/damon/paddr: remove page_fault access check primitive Ravi Jonnalagadda
2026-10-05 8:53 ` sashiko-bot
2026-10-05 8:46 ` [RFC PATCH v4 2/9] mm/damon/core: replace the access report buffer with per-context rings Ravi Jonnalagadda
2026-10-05 8:54 ` sashiko-bot
2026-10-05 8:46 ` [RFC PATCH v4 3/9] mm/damon: add perf-event overflow handler feeding the report ring Ravi Jonnalagadda
2026-10-05 8:58 ` sashiko-bot
2026-10-05 8:46 ` [RFC PATCH v4 4/9] mm/damon/ops-common: use probe-weighted score when probe weights are set Ravi Jonnalagadda
2026-10-05 8:54 ` sashiko-bot
2026-10-05 8:46 ` [RFC PATCH v4 5/9] mm/damon: add perf_event prep type, core lifecycle, and PMU arm/disarm Ravi Jonnalagadda
2026-10-05 9:02 ` sashiko-bot
2026-10-05 8:46 ` [RFC PATCH v4 6/9] mm/damon/sysfs: expose perf_event prep attributes Ravi Jonnalagadda
2026-10-05 8:56 ` sashiko-bot
2026-10-05 8:46 ` [RFC PATCH v4 7/9] mm/damon/tests/drain-kunit: kunit for report rings and ring drain Ravi Jonnalagadda
2026-10-05 8:59 ` sashiko-bot
2026-10-05 8:46 ` [RFC PATCH v4 8/9] mm/damon/core: cap the region merge threshold per target Ravi Jonnalagadda
2026-10-05 8:58 ` sashiko-bot [this message]
2026-10-05 8:46 ` [RFC PATCH v4 9/9] mm/damon/core: apply probe_hits_wsum filters to node_eligible_mem_bp Ravi Jonnalagadda
2026-10-05 8:59 ` sashiko-bot
2026-10-05 9:24 ` [RFC PATCH v4 0/9] mm/damon: hardware-sampled access reports 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=20261005085810.A87BE1F000FF@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=damon@lists.linux.dev \
--cc=ravis.opensrc@gmail.com \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox