From: sashiko-bot@kernel.org
To: "SJ Park" <sj@kernel.org>
Cc: damon@lists.linux.dev
Subject: Re: [RFC PATCH 11/16] mm/damon/core: get merge threshold from probe hits when weights are set
Date: Sun, 05 Jul 2026 21:12:08 +0000 [thread overview]
Message-ID: <20260705211209.006A71F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260705205743.98656-12-sj@kernel.org>
Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
New issues:
- [High] The merge threshold limit (`max_thres`) in `kdamond_merge_regions` is not scaled for probe weights, causing premature termination of the region merging loop and failing to enforce the user-defined `max_nr_regions` limit.
Pre-existing issues:
- [High] When probe weights are configured for operations that do not implement `apply_probes` (e.g., `vaddr`), the merge threshold becomes 0 and regions are improperly and aggressively merged.
--
commit 23bf451408faae1b0a1f1eb841dc6f4b60077861
Author: SJ Park <sj@kernel.org>
Subject: mm/damon/core: get merge threshold from probe hits when weights are set
When probe weights are set, DAMON merges regions based on their probe hits
weighted sum, but the merge threshold is calculated based on access frequency.
Update it to retrieve the maximum probe hits weighted sum in the snapshot from
the apply_probes() ops callback, and generate the threshold based on it.
> diff --git a/mm/damon/core.c b/mm/damon/core.c
> index bd6d836f1db5e..7a070cfb7cd1b 100644
> --- a/mm/damon/core.c
> +++ b/mm/damon/core.c
> @@ -3683,9 +3684,18 @@ static int kdamond_fn(void *data)
>
> if (!access_check_disabled && ctx->ops.check_accesses)
> max_merge_score = ctx->ops.check_accesses(ctx);
> - if (ctx->ops.apply_probes)
> - ctx->ops.apply_probes(ctx, access_check_disabled,
> - false);
> + if (ctx->ops.apply_probes) {
> + if (time_after_eq(ctx->passed_sample_intervals,
> + next_aggregation_sis) &&
> + access_check_disabled)
> + get_max_wsum = true;
> + else
> + get_max_wsum = false;
> + max_wsum = ctx->ops.apply_probes(ctx,
> + access_check_disabled, get_max_wsum);
> + if (get_max_wsum)
> + max_merge_score = max_wsum;
> + }
[Severity: High]
This is a pre-existing issue, but what happens if a user configures probe
weights for operations that do not implement apply_probes (like vaddr)?
When damon_has_probe_weights() returns true, access checks are disabled. If
the operations lack an apply_probes callback, max_merge_score will remain 0.
Will this cause all regions to be improperly and unconditionally merged into
maximum-sized chunks, resulting in a loss of monitoring resolution?
[Severity: High]
Does kdamond_merge_regions() properly handle this new weight-based score limit?
Just after this block, max_merge_score is passed into kdamond_merge_regions():
mm/damon/core.c:kdamond_fn() {
...
if (time_after_eq(ctx->passed_sample_intervals,
next_aggregation_sis)) {
kdamond_merge_regions(ctx,
max_merge_score / 10,
sz_limit);
...
}
Because max_thres inside kdamond_merge_regions() is hardcoded to the maximum
possible frequency of unweighted accesses, rather than dynamically accounting
for probe weights, the scaling loop termination condition:
mm/damon/core.c:kdamond_merge_regions() {
...
} while (nr_regions > c->attrs.max_nr_regions &&
threshold / 2 < max_thres);
...
}
appears to instantly fail when the initial threshold is already large due to
probe weights.
Will this cause an early abort of the fallback loop, leaving regions unmerged
and failing to enforce the max_nr_regions limit?
>
> if (time_after_eq(ctx->passed_sample_intervals,
> next_aggregation_sis)) {
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260705205743.98656-1-sj@kernel.org?part=11
next prev parent reply other threads:[~2026-07-05 21:12 UTC|newest]
Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-05 20:57 [RFC PATCH 00/16] mm/damon: introduce data attributes only monitoring SJ Park
2026-07-05 20:57 ` [RFC PATCH 01/16] mm/damon/core: introduce damon_probe->weight SJ Park
2026-07-05 21:04 ` sashiko-bot
2026-07-05 21:21 ` SJ Park
2026-07-05 20:57 ` [RFC PATCH 02/16] mm/damon/core: ask apply_probes() ops callback to set sampling address SJ Park
2026-07-05 21:07 ` sashiko-bot
2026-07-05 21:25 ` SJ Park
2026-07-05 20:57 ` [RFC PATCH 03/16] mm/damon/paddr: set samples in apply_probes() if requested SJ Park
2026-07-05 21:11 ` sashiko-bot
2026-07-05 21:28 ` SJ Park
2026-07-05 20:57 ` [RFC PATCH 04/16] mm/damon/core: ask apply_probe() to return max probe hits weighted sum SJ Park
2026-07-05 20:57 ` [RFC PATCH 05/16] mm/damon/core: implement damon_probe_hits_wsum() SJ Park
2026-07-05 21:13 ` sashiko-bot
2026-07-05 21:30 ` SJ Park
2026-07-05 20:57 ` [RFC PATCH 06/16] mm/damon/paddr: respect return_max_wsum SJ Park
2026-07-05 20:57 ` [RFC PATCH 07/16] mm/damon/core: extend merge function to work with probe hits SJ Park
2026-07-05 21:11 ` sashiko-bot
2026-07-05 21:38 ` SJ Park
2026-07-05 20:57 ` [RFC PATCH 08/16] mm/damon/core: disable access monitoring when probe weights are set SJ Park
2026-07-05 21:19 ` sashiko-bot
2026-07-05 20:57 ` [RFC PATCH 09/16] mm/damon/core: set samples in apply_probes() if " SJ Park
2026-07-05 20:57 ` [RFC PATCH 10/16] mm/damon/core: s/max_nr_accesses/max_merge_score/ in kdamond_fn() SJ Park
2026-07-05 20:57 ` [RFC PATCH 11/16] mm/damon/core: get merge threshold from probe hits when weights are set SJ Park
2026-07-05 21:12 ` sashiko-bot [this message]
2026-07-05 21:41 ` SJ Park
2026-07-05 20:57 ` [RFC PATCH 12/16] mm/damon/core: implement damon_has_probe_weight() SJ Park
2026-07-05 21:15 ` sashiko-bot
2026-07-05 21:45 ` SJ Park
2026-07-05 20:57 ` [RFC PATCH 13/16] mm/damon/sysfs: implement probe/weight file SJ Park
2026-07-05 20:57 ` [RFC PATCH 14/16] Docs/mm/damon/design: document attrs-only monitoring SJ Park
2026-07-05 21:05 ` sashiko-bot
2026-07-05 21:46 ` SJ Park
2026-07-05 20:57 ` [RFC PATCH 15/16] Docs/admin-guide/mm/damon/usage: document weight sysfs file SJ Park
2026-07-05 21:07 ` sashiko-bot
2026-07-05 21:48 ` SJ Park
2026-07-05 20:57 ` [RFC PATCH 16/16] Docs/ABI/damon: document probe weight file 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=20260705211209.006A71F000E9@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=damon@lists.linux.dev \
--cc=sashiko-reviews@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 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.