Re: [PATCH 0/2] mm/damon/core: detect internal variation above max_nr_regions/2

[SeongJae Park <sj@kernel.org>]

Hello Jiayuan,

On Thu, 21 May 2026 12:52:22 +0800 Jiayuan Chen <jiayuan.chen@linux.dev> wrote:

> kdamond_split_regions() bails out early when nr_regions is already
> above max_nr_regions / 2.  A large region that picks up new internal
> variation after that point never gets split, so we lose visibility
> into its hot/cold structure.
> 
> We hit this with damon-paddr on hugepage workloads and damon-vaddr
> on processes that mmap a large anonymous range.
> 
> On our production tree we added a current_nr_regions counter (no
> good upstream home for it yet, so it's not in this series).  We saw
> nr_regions never getting close to max_nr_regions, and the picture of
> the access pattern was too coarse.

Is 'current_nr_regions' somewhat showing the number of DAMON regions?  If so,
you could also get the information from nr_regions field of damon_aggregated
tracepoint.  I'm wondering if you considered using that but found a problem
that made you have to implement the internal change.

I will be happy to help removing such downstream changes.

> 
> Example with max_nr_regions == 1500.  A target ends up with 799
> small hot/cold regions plus one big region (an earlier merge
> collapsed a uniformly-accessed range into a single piece):
> 
> H:hot
> C:cold
> 
>       r1     r2     r3                 r800
>     HHHHHH|CCCCCC|HHHHHH|...|HHHHHH..........................|
> 
>     nr_regions = 800  >  max_nr_regions / 2 = 750
> 
> Now a cold subarea shows up inside r800:
> 
>       r1     r2     r3                 r800
>     HHHHHH|CCCCCC|HHHHHH|...|HHHHHH........CCCCCC.............|
> 
> The small regions can't merge with each other (their access counts
> differ), so budget never frees up.  r800 can't be split because
> nr_regions > max_nr_regions / 2 returns early.  The cold subarea
> stays invisible.

I agree this corner case could theoretically happen.  But, would the small
regions have the current pattern forever?  On real world systems having dynamic
access pattern, I guess those small regions may not keep the shape forever, and
give chance for the large region to be split.  Am I missing something?

My theory also implies that this kind of situation could happen at least
sometimes for temporal periods.  In other words, it could happens too
frequently and too long to be problematic.  But, in the case, maybe the user
could mitigate the issue by increasing the max_nr_regions.  I'm curious if you
considered that direction and found a problem that I don't expect for now.

> 
> Patch 1 lets this path still split regions that just changed
> (age == 0),

Why 'age == 0' means it is a good candidate to split?  Because it means its
access frequency is anyway unstable?  Or are there other reasons?  More
clarification would be helpful.

> up to whatever budget is left under max_nr_regions.
> If a split turns out useless, the next merge cycle undoes it.

I'm again curious why the user cannot just increase max_nr_regions.

> 
> Patch 2 adds a KUnit test for the case where nr_regions is already
> above max_nr_regions / 2.

Adding tests for new features is always nice, thank you!

I will review each patch in detail after the above high level questions are
answered.


Thanks,
SJ

[...]