Re: [PATCH v2 1/2] mm/damon/core: split a fraction of regions when nr_regions exceeds max/2

[SeongJae Park <sj@kernel.org>]

On Fri, 26 Jun 2026 16:58:37 +0800 Jiayuan Chen <jiayuan.chen@linux.dev> wrote:

> From: Jiayuan Chen <jiayuan.chen@shopee.com>
> 
> kdamond_split_regions() returns early when nr_regions is above
> max_nr_regions / 2, leaving internal access variation inside a large
> region undetected.
> 
> Such a layout is common with damon-paddr on hugepage workloads or
> damon-vaddr on processes with a large anonymous mmap.
> 
> For example, with max_nr_regions == 1500, a target may end up with
> 799 small alternating-temperature regions plus one large region that
> absorbed a uniformly-accessed range during an earlier merge:
> 
> H:hot
> C:cold
> 
>       r1     r2     r3                 r800
>     HHHHHH|CCCCCC|HHHHHH|...|HHHHHH..........................|
> 
>     nr_regions = 800  >  max_nr_regions / 2 = 750
> 
> If a cold subarea later emerges inside r800:
> 
>       r1     r2     r3                 r800
>     HHHHHH|CCCCCC|HHHHHH|...|HHHHHH........CCCCCC.............|
> 
> The small regions cannot merge with each other (different access
> counts), so the budget stays full.  r800 cannot be split because
> nr_regions > max_nr_regions / 2 causes an early return.  The cold
> subarea is never discovered.
> 
> When nr_regions is above max_nr_regions / 2 but still under the
> maximum, split only a fraction of the regions instead of returning.
> One region in every 'max_nr_regions / budget' regions is split, where
> budget is the remaining room (max_nr_regions - nr_regions), starting
> from a rotating offset so different regions get picked over time.  The
> fraction shrinks as the budget shrinks, so the region count keeps
> refining while approaching max_nr_regions smoothly rather than
> overshooting it.  An unnecessary split is reverted by the next
> kdamond_merge_regions().

Looks good!

Thinking loud.  After this change, some users might surprise because the number
of regions became higher than before.  But it is still under the contracted
maximum number, and they will show better accuracy.  So I believe this is a
reasonable improvement rather than a breaking change.

Thank you for this patch, Jiayuan.

> 
> Cc: Jiayuan Chen <jiayuan.chen@linux.dev>
> Signed-off-by: Jiayuan Chen <jiayuan.chen@shopee.com>

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


Thanks,
SJ

[...]