[PATCH 1/2] mm/damon/core: modified and tunning damon_split_regions_of()

[PATCH 1/2] mm/damon/core: modified and tunning damon_split_regions_of()

[JaeJoon Jung]

Before modification:
                                                             sz_region
    |--------|--------|--------||--------|--------|--------|--------|
nr_subs:     1        2        3        4        5                  9
split random:    <----------- (*] randmon        LOST -------------->

When dividing sz_region at rand, the random value may be small, such as
1 or 2.  At this time, there is a problem that only the front areas
corresponding to 1 and 2 are divided, and the remaining back area
becomes too wide.  If the area is too wide, there will be many missed
address access judgments.

After modification:
                                                             sz_region
    |--------|--------|--------|--------|--------|--------|--------||
nr_subs:     1        2        3        4        5                  9
split from   <------------ (sz_region / nr_subs) ------------------>

It is recommended to divide sz_region evenly in the ratio (sz_region /
nr_subs) rather than using rand.  In this way, if you decide nr_subs well,
you can logically match the number of divisions and their sizes.

Signed-off-by: JaeJoon Jung <rgbi3307@gmail.com>
---
 mm/damon/core.c | 21 ++++++---------------
 1 file changed, 6 insertions(+), 15 deletions(-)

diff --git a/mm/damon/core.c b/mm/damon/core.c
index f9fc0375890a..ff9af9d6a788 100644
--- a/mm/damon/core.c
+++ b/mm/damon/core.c
@@ -2394,27 +2394,18 @@ static void damon_split_regions_of(struct damon_target *t, int nr_subs,
 				  unsigned long min_sz_region)
 {
 	struct damon_region *r, *next;
-	unsigned long sz_region, sz_sub = 0;
+	unsigned long sz_region, sz_sub;
 	int i;

 	damon_for_each_region_safe(r, next, t) {
 		sz_region = damon_sz_region(r);
+		sz_sub = ALIGN_DOWN(sz_region / nr_subs, min_sz_region);

-		for (i = 0; i < nr_subs - 1 &&
-				sz_region > 2 * min_sz_region; i++) {
-			/*
-			 * Randomly select size of left sub-region to be at
-			 * least 10 percent and at most 90% of original region
-			 */
-			sz_sub = ALIGN_DOWN(damon_rand(1, 10) *
-					sz_region / 10, min_sz_region);
-			/* Do not allow blank region */
-			if (sz_sub == 0 || sz_sub >= sz_region)
-				continue;
+		if (sz_sub < min_sz_region)
+			continue;

-			damon_split_region_at(t, r, sz_sub);
-			sz_region = sz_sub;
-		}
+		for (i = 1; i < nr_subs; i++)
+			damon_split_region_at(t, r, sz_region - sz_sub * i);
 	}
 }

--
2.43.0

Re: [PATCH 1/2] mm/damon/core: modified and tunning damon_split_regions_of()

[SeongJae Park]

Hello JaeJoon, thank you for continued interest in DAMON.

On Tue, 13 Jan 2026 21:16:42 +0900 JaeJoon Jung <rgbi3307@gmail.com> wrote:

> Before modification:
>                                                              sz_region
>     |--------|--------|--------||--------|--------|--------|--------|
> nr_subs:     1        2        3        4        5                  9
> split random:    <----------- (*] randmon        LOST -------------->
> 
> When dividing sz_region at rand, the random value may be small, such as
> 1 or 2.  At this time, there is a problem that only the front areas
> corresponding to 1 and 2 are divided, and the remaining back area
> becomes too wide.  If the area is too wide, there will be many missed
> address access judgments.
> 
> After modification:
>                                                              sz_region
>     |--------|--------|--------|--------|--------|--------|--------||
> nr_subs:     1        2        3        4        5                  9
> split from   <------------ (sz_region / nr_subs) ------------------>
> 
> It is recommended to divide sz_region evenly in the ratio (sz_region /
> nr_subs) rather than using rand.  In this way, if you decide nr_subs well,
> you can logically match the number of divisions and their sizes.

I was thinking about how to reply to this patch.  Since it is taking unusually
long time, let me add short comments for direct future of this patch.

The existing code uses random() for a reason.  This change might break it.  Can
you further explain what was the point of the use of random(), and why this
change is not breaking it?

> 
> Signed-off-by: JaeJoon Jung <rgbi3307@gmail.com>

Unless you can give me a convincing answer to my above question,

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

Same for your followup patch [1].  Btw, please send patches of same series as
one thread from next time.

[1] https://lore.kernel.org/20260113121731.31468-1-rgbi3307@gmail.com


Thanks,
SJ

[...]

Re: [PATCH 1/2] mm/damon/core: modified and tunning damon_split_regions_of()

[JaeJoon Jung]

On Thu, 15 Jan 2026 at 00:46, SeongJae Park <sj@kernel.org> wrote:
>
> Hello JaeJoon, thank you for continued interest in DAMON.
>
> On Tue, 13 Jan 2026 21:16:42 +0900 JaeJoon Jung <rgbi3307@gmail.com> wrote:
>
> > Before modification:
> >                                                              sz_region
> >     |--------|--------|--------||--------|--------|--------|--------|
> > nr_subs:     1        2        3        4        5                  9
> > split random:    <----------- (*] randmon        LOST -------------->
> >
> > When dividing sz_region at rand, the random value may be small, such as
> > 1 or 2.  At this time, there is a problem that only the front areas
> > corresponding to 1 and 2 are divided, and the remaining back area
> > becomes too wide.  If the area is too wide, there will be many missed
> > address access judgments.
> >
> > After modification:
> >                                                              sz_region
> >     |--------|--------|--------|--------|--------|--------|--------||
> > nr_subs:     1        2        3        4        5                  9
> > split from   <------------ (sz_region / nr_subs) ------------------>
> >
> > It is recommended to divide sz_region evenly in the ratio (sz_region /
> > nr_subs) rather than using rand.  In this way, if you decide nr_subs well,
> > you can logically match the number of divisions and their sizes.
>
> I was thinking about how to reply to this patch.  Since it is taking unusually
> long time, let me add short comments for direct future of this patch.

After much thought, you ask a simple question below.

>
> The existing code uses random() for a reason.  This change might break it.  Can
> you further explain what was the point of the use of random(), and why this
> change is not breaking it?

To find a needle in a haystack, is it right to keep poking around randomly?

>
> >
> > Signed-off-by: JaeJoon Jung <rgbi3307@gmail.com>
>
> Unless you can give me a convincing answer to my above question,
>
> Nacked-by: SeongJae Park <sj@kernel.org>
>
> Same for your followup patch [1].  Btw, please send patches of same series as
> one thread from next time.

I sent you two after much deliberation so that you can see them clearly.

Thanks,
JaeJoon

>
> [1] https://lore.kernel.org/20260113121731.31468-1-rgbi3307@gmail.com
>
>
> Thanks,
> SJ
>
> [...]