All of lore.kernel.org
 help / color / mirror / Atom feed
From: SeongJae Park <sj@kernel.org>
To: Jiayuan Chen <jiayuan.chen@linux.dev>
Cc: SeongJae Park <sj@kernel.org>,
	damon@lists.linux.dev, jiayuan.chen@shopee.com,
	Andrew Morton <akpm@linux-foundation.org>,
	Shu Anzai <shu17az@gmail.com>,
	linux-mm@kvack.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2 0/2] mm/damon/core: detect internal variation above max_nr_regions/2
Date: Fri, 26 Jun 2026 07:59:09 -0700	[thread overview]
Message-ID: <20260626145910.88535-1-sj@kernel.org> (raw)
In-Reply-To: <20260626085851.70754-1-jiayuan.chen@linux.dev>

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

> Sorry for the late.

No worry!

> 
> 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.
> 
> 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.
> 
> Patch 1 keeps refining on this path: when nr_regions is above
> max_nr_regions / 2 but still under the maximum, it splits a fraction
> of the regions instead of returning.  The fraction shrinks as the
> remaining budget shrinks, so the count approaches max_nr_regions
> smoothly.  A useless split is undone by the next merge cycle.

I assume you confirmed this change is making somee progress in a test or on
your real use case?  It would be great if you can confirm that and/or even
share your measurements.

> 
> Patch 2 adds a KUnit test for the case where nr_regions is already
> above max_nr_regions / 2.
> 
> Thanks to SeongJae for the suggestion to drive the split fraction
> from the remaining budget rather than an age-based filter.

I'm glad to help this grateful improvement!

> 
> 
> v1 -> v2: Some feedback from SJ.
> v1: https://lore.kernel.org/damon/20260521045236.115749-1-jiayuan.chen@linux.dev/
> 
> Jiayuan Chen (2):
>   mm/damon/core: split a fraction of regions when nr_regions exceeds
>     max/2
>   mm/damon/tests/core-kunit: test split above max_nr_regions/2

I have trivial comments to the second patch, but all looks good enough.

I will apply this series to damon/next [1] tree.  If this patch is not added to
mm.git in short term (~1 week?), I will ask mm.git maintainer (Andrew Morton)
to pick this.  So, no action from your side is needed for now.  If it seems I
also forgot doing that or you cannot wait for my action, please feel free to
directly ask that to Andrew.

[1] https://origin.kernel.org/doc/html/latest/mm/damon/maintainer-profile.html#scm-trees


Thanks,
SJ

[...]

      parent reply	other threads:[~2026-06-26 14:59 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-06-26  8:58 [PATCH v2 0/2] mm/damon/core: detect internal variation above max_nr_regions/2 Jiayuan Chen
2026-06-26  8:58 ` [PATCH v2 1/2] mm/damon/core: split a fraction of regions when nr_regions exceeds max/2 Jiayuan Chen
2026-06-26  9:09   ` sashiko-bot
2026-06-26 14:49     ` SeongJae Park
2026-06-26 14:46   ` SeongJae Park
2026-06-26  8:58 ` [PATCH v2 2/2] mm/damon/tests/core-kunit: test split above max_nr_regions/2 Jiayuan Chen
2026-06-26 14:54   ` SeongJae Park
2026-06-26 14:59 ` SeongJae Park [this message]

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=20260626145910.88535-1-sj@kernel.org \
    --to=sj@kernel.org \
    --cc=akpm@linux-foundation.org \
    --cc=damon@lists.linux.dev \
    --cc=jiayuan.chen@linux.dev \
    --cc=jiayuan.chen@shopee.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=shu17az@gmail.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.