DAMON development mailing list
 help / color / mirror / Atom feed
From: Jiayuan Chen <jiayuan.chen@linux.dev>
To: sashiko-reviews@lists.linux.dev
Cc: damon@lists.linux.dev
Subject: Re: [PATCH 2/2] mm/damon/tests/core-kunit: test split above max_nr_regions/2
Date: Thu, 21 May 2026 14:44:24 +0800	[thread overview]
Message-ID: <45d1800d-11ef-45bd-b1b8-5fe47dd43ee9@linux.dev> (raw)
In-Reply-To: <20260521054113.AFDC61F000E9@smtp.kernel.org>


On 5/21/26 1:41 PM, sashiko-bot@kernel.org wrote:
> Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
> - [Medium] The new unit test `damon_test_split_above_half_progresses` fails to effectively test its target logic and introduces architecture-dependent flakiness due to relying on default page sizes.
> --
>
> commit 41d857e275ff50ce39c3b59f85362709927d922a
> Author: Jiayuan Chen <jiayuan.chen@shopee.com>
>
> mm/damon/tests/core-kunit: test split above max_nr_regions/2
>
> This commit adds a kunit test to exercise kdamond_split_regions() when the
> total region count is already above max_nr_regions / 2. It asserts that the
> function can still produce new regions without overshooting the maximum
> region limit.
>
>> diff --git a/mm/damon/tests/core-kunit.h b/mm/damon/tests/core-kunit.h
>> index 866f716e5760d..c87933c58785b 100644
>> --- a/mm/damon/tests/core-kunit.h
>> +++ b/mm/damon/tests/core-kunit.h
> [ ... ]
>> +static void damon_test_split_above_half_progresses(struct kunit *test)
>> +{
>> +	struct damon_ctx *c;
>> +	struct damon_target *t;
>> +	struct damon_region *r, *big;
>> +	unsigned long start;
>> +	unsigned int nr_before, nr_after, i;
>> +	const unsigned int nr_small = 799;
>> +	const unsigned long small_sz = 10;
>> +	const unsigned long big_sz = 1000000;
>> +
>> +	c = damon_new_ctx();
> [Severity: Medium]
> Does this introduce a test regression on architectures with large page sizes?
>
> Because damon_new_ctx() sets c->min_region_sz to the default PAGE_SIZE,
> this test might become flaky or fail on architectures with larger pages.
>
> For example, on architectures with a 256KB page size, the random split math
> could calculate a sub-region size that aligns down to 0, which would skip
> the split. On architectures with 1MB pages, the test would deterministically
> fail because the big region size (1,000,000) is smaller than
> 2 * min_region_sz.
>
> Will this cause the KUNIT_EXPECT_GT(test, nr_after, nr_before) assertion
> below to randomly or deterministically fail since no regions will be split?
>
> [ ... ]
>> +	nr_after = damon_nr_regions(t);
>> +	KUNIT_EXPECT_GT(test, nr_after, nr_before);
>> +	KUNIT_EXPECT_LE(test, (unsigned long)nr_after,
>> +			c->attrs.max_nr_regions);
> [Severity: Medium]
> Does this test actually exercise the budget constraint logic to ensure the
> region limit isn't overshot?
>
> Since the setup only provides a single splittable "big" region, and
> damon_split_zero_age_regions() skips newly inserted regions during its
> traversal, wouldn't this only ever produce at most 1 new region before
> terminating?
>
> If it can only split once, it seems structurally impossible for the test to
> reach or exceed the remaining budget of 700 regions, which might defeat the
> stated purpose of checking if the function overshoots the limit.
>
>> +
>> +	damon_destroy_ctx(c);
>> +}


Both are valid, thanks.  I'll fold them into the respin once the series 
has been reviewed by the maintainer.


  reply	other threads:[~2026-05-21  6:44 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-05-21  4:52 [PATCH 0/2] mm/damon/core: detect internal variation above max_nr_regions/2 Jiayuan Chen
2026-05-21  4:52 ` [PATCH 1/2] mm/damon/core: split age==0 regions when nr_regions exceeds max/2 Jiayuan Chen
2026-05-21  5:22   ` sashiko-bot
2026-05-21  6:34     ` Jiayuan Chen
2026-05-21  4:52 ` [PATCH 2/2] mm/damon/tests/core-kunit: test split above max_nr_regions/2 Jiayuan Chen
2026-05-21  5:41   ` sashiko-bot
2026-05-21  6:44     ` Jiayuan Chen [this message]
2026-05-21 14:30 ` [PATCH 0/2] mm/damon/core: detect internal variation " SeongJae Park
2026-05-21 15:07   ` Jiayuan Chen
2026-05-22  2:42     ` SeongJae Park
2026-05-22 15:11       ` Jiayuan Chen
2026-05-23  1:43         ` SeongJae Park
2026-05-25  8:09           ` Jiayuan Chen
2026-05-25 16:38             ` 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=45d1800d-11ef-45bd-b1b8-5fe47dd43ee9@linux.dev \
    --to=jiayuan.chen@linux.dev \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox