All of lore.kernel.org
 help / color / mirror / Atom feed
From: SeongJae Park <sj@kernel.org>
To: Zheng Yejian <zhengyejian@huaweicloud.com>
Cc: SeongJae Park <sj@kernel.org>,
	akpm@linux-foundation.org, damon@lists.linux.dev,
	foersleo@amazon.de, linux-kernel@vger.kernel.org,
	linux-mm@kvack.org, shakeel.butt@linux.dev, sieberf@amazon.com,
	yeweihua4@huawei.com, brendanhiggins@google.com,
	davidgow@google.com, rmoar@google.com,
	linux-kselftest@vger.kernel.org, kunit-dev@googlegroups.com
Subject: Re: [PATCH v2 1/2] mm/damon/vaddr: Fix issue in damon_va_evenly_split_region()
Date: Tue, 22 Oct 2024 10:54:52 -0700	[thread overview]
Message-ID: <20241022175452.42218-1-sj@kernel.org> (raw)
In-Reply-To: <20241022083927.3592237-2-zhengyejian@huaweicloud.com>

Hi Zheng,


We Cc kunit folks for any DAMON kunit test changes, so I Cc-ed them.

On Tue, 22 Oct 2024 16:39:26 +0800 Zheng Yejian <zhengyejian@huaweicloud.com> wrote:

> According to the logic of damon_va_evenly_split_region(), currently
> following split case would not meet the expectation:
> 
>   Suppose DAMON_MIN_REGION=0x1000,
>   Case: Split [0x0, 0x3000) into 2 pieces, then the result would be
>         acutually 3 regions:
>           [0x0, 0x1000), [0x1000, 0x2000), [0x2000, 0x3000)
>         but NOT the expected 2 regions:
>           [0x0, 0x1000), [0x1000, 0x3000) !!!
> 
> The root cause is that when calculating size of each split piece in
> damon_va_evenly_split_region():
> 
>   `sz_piece = ALIGN_DOWN(sz_orig / nr_pieces, DAMON_MIN_REGION);`
> 
> both the dividing and the ALIGN_DOWN may cause loss of precision,
> then each time split one piece of size 'sz_piece' from origin 'start' to
> 'end' would cause more pieces are split out than expected!!!
> 
> To fix it, count for each piece split and make sure no more than
> 'nr_pieces'. In addition, add above case into damon_test_split_evenly().
> 
> After this patch, damon-operations test passed:

Just for a clarification.  damon-operations test doesn't fail without this
patch.  This patch introduces two changes.  A new kunit test, and a bug fix.
Without the bug fix, the new kunit test fails.

I usually prefer separating test changes from fixes (introduc a fix first, and
then the test for it, to avoid unnecessary test failures).  But, given the
small size and the simplicity of the kunit change for this patch, I think
introducing it together with the fix is ok.

> 
>  # ./tools/testing/kunit/kunit.py run damon-operations
>  [...]
>  ============== damon-operations (6 subtests) ===============
>  [PASSED] damon_test_three_regions_in_vmas
>  [PASSED] damon_test_apply_three_regions1
>  [PASSED] damon_test_apply_three_regions2
>  [PASSED] damon_test_apply_three_regions3
>  [PASSED] damon_test_apply_three_regions4
>  [PASSED] damon_test_split_evenly
>  ================ [PASSED] damon-operations =================
> 
> Fixes: 3f49584b262c ("mm/damon: implement primitives for the virtual memory address spaces")
> Signed-off-by: Zheng Yejian <zhengyejian@huaweicloud.com>

Reviewed-by: SeongJae Park <sj@kernel.org>


Thanks,
SJ

[...]

  reply	other threads:[~2024-10-22 17:54 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-10-18  3:53 [PATCH] mm/damon/vaddr: Fix issue in damon_va_evenly_split_region() Zheng Yejian
2024-10-18 18:33 ` SeongJae Park
2024-10-21  3:56   ` Zheng Yejian
2024-10-21 16:33     ` SeongJae Park
2024-10-22  8:39       ` [PATCH v2 0/2] " Zheng Yejian
2024-10-22  8:39         ` [PATCH v2 1/2] " Zheng Yejian
2024-10-22 17:54           ` SeongJae Park [this message]
2024-10-22 18:00           ` SeongJae Park
2024-10-22  8:39         ` [PATCH v2 2/2] mm/damon/vaddr: Add 'nr_piece == 1' check " Zheng Yejian
2024-10-22 17:57           ` SeongJae Park
2024-10-22 18:05         ` [PATCH v2 0/2] mm/damon/vaddr: Fix issue " SeongJae Park
2024-10-23  1:27           ` Zheng Yejian

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=20241022175452.42218-1-sj@kernel.org \
    --to=sj@kernel.org \
    --cc=akpm@linux-foundation.org \
    --cc=brendanhiggins@google.com \
    --cc=damon@lists.linux.dev \
    --cc=davidgow@google.com \
    --cc=foersleo@amazon.de \
    --cc=kunit-dev@googlegroups.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-kselftest@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=rmoar@google.com \
    --cc=shakeel.butt@linux.dev \
    --cc=sieberf@amazon.com \
    --cc=yeweihua4@huawei.com \
    --cc=zhengyejian@huaweicloud.com \
    /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.