Re: [PATCH 1/2] mm/damon/core: cover discrete System RAM areas with per-range regions

Hello Jiayuan,

On Mon, 27 Jul 2026 17:54:22 +0800 Jiayuan Chen <[email protected]> wrote:

> From: Jiayuan Chen <[email protected]>
> 
> damon_set_region_system_rams_default(), introduced by commit 70d8797c15d6
> ("mm/damon: introduce damon_set_region_system_rams_default()"), is used by
> DAMON_RECLAIM, DAMON_LRU_SORT and DAMON_STAT to set the default monitoring
> target address range covering all 'System RAM' when the user does not
> specify a range.  It walks the 'System RAM' resources but keeps only the
> start of the first resource and the end of the last one, and then sets a
> single monitoring region spanning that whole [first_start, last_end] range.
> 
> On systems whose RAM is split into discrete areas that are far apart in the
> physical address space, that single region also covers the holes between
> them.  For example:
> 
>   $ sudo cat /proc/iomem | grep RAM
>   00001000-0009ffff : System RAM
>   00100000-4848c017 : System RAM
>   4848c018-48550c57 : System RAM
>   48550c58-48551017 : System RAM
>   48551018-48615c57 : System RAM
>   48615c58-48616017 : System RAM
>   48616018-486dac57 : System RAM
>   486dac58-4e563017 : System RAM
>   4e563018-4e627c57 : System RAM
>   4e627c58-4ef39017 : System RAM
>   4ef39018-4ef3f057 : System RAM
>   4ef3f058-4efe6017 : System RAM
>   4efe6018-4efec057 : System RAM
>   4efec058-50247fff : System RAM
>   50317000-56720fff : System RAM
>   56722000-59c19fff : System RAM
>   6bbfe000-6bbfefff : System RAM
>   6bc00000-777fffff : System RAM
>   100000000-1007effffff : System RAM
>   67e80000000-77e7fffffff : System RAM
> 
> Here the last two areas (about 1TB starting at 4GiB, and about 1.1TB
> starting at ~6.5TB) are separated by a ~5.5TB hole, and the single-region
> setup makes DAMON treat that entire hole as if it were memory.
> 
> This is harmful in a few ways.  The monitoring target regions are limited
> by max_nr_regions, so regions that fall into the hole waste that budget and
> leave fewer regions for the real RAM, coarsening the adaptive regions and
> degrading the monitoring accuracy.

The hole would look like not accessed.  As a result, the whole region will be a
few regions that very cold.  That wouldn't waste the budget that much.  Do you
have some specific setups that this cannot help?

> In addition, DAMOS actions on the paddr
> operations set walk such a region page by page, so a region that covers the
> hole is walked for its entire (empty) span on every application.

That makes sense.

> 
> Set a separate monitoring region for each discrete System RAM area instead,
> coalescing only truly adjacent (no gap in between) resources into one
> range, so holes between the areas are excluded.  The reported *start and
> *end still carry the overall first-start and last-end, so the user-visible
> default range reported via the module parameters is unchanged.

I'm concerned if this could result in having too many regions.  The gap between
user-visible parameters and internal state is also a concern.

A quick workaround would be adjusting the memory layout in BIOS, using DAMON
sysfs interface instead, or setting the monitor_region_{start,end} to cover
only the single area.  Have you considered such workarounds?

Let's complete this high level discussion first.


Thanks,
SJ

[...]