[PATCH 0/7] mm/damon/reclaim,lru_sort: monitor all system rams by default

[PATCH 0/7] mm/damon/reclaim,lru_sort: monitor all system rams by default

[SeongJae Park]

DAMON_RECLAIM and DAMON_LRU_SORT set the biggest 'System RAM' resource
of the system as the default monitoring target address range.  The main
intention behind the design is to minimize the overhead coming from
monitoring of non-System RAM areas.

This could result in an odd setup when there are multiple discrete
System RAMs of considerable sizes.  For example, there are System RAMs
each having 500 GiB size.  In this case, only the first 500 GiB will be
set as the monitoring region by default.  This is particularly common on
NUMA systems.  Hence the modules allow users to set the monitoring
target address range using the module parameters if the default setup
doesn't work for them.  In other words, the current design trades ease
of setup for lower overhead.

However, because DAMON utilizes the sampling based access check and the
adaptive regions adjustment mechanisms, the overhead from the monitoring
of non-System RAM areas should be negligible in most setups.  Meanwhile,
the setup complexity is causing real headaches for users who need to run
those modules on various types of systems.  That is, the current
tradeoff is not a good deal.

Set the physical address range that can cover all System RAM areas of
the system as the default monitoring regions for DAMON_RECLAIM and
DAMON_LRU_SORT.

Technically speaking, this is changing documented behavior.  However, it
makes no sense to believe there is a real use case that really depends
on the old weird default behavior.  If the old default behavior was
working for them in the reasonable way, this change will only add a
negligible amount of monitoring overhead.  If it didn't work, the users
may already be using manual monitoring regions setup, and they will not
be affected by this change.

Patches Sequence
================

Patch 1 introduces a new core function that will be used for the new
default monitoring target region setup.  Patch 2 and 3 update
DAMON_RECLAIM and DAMON_LRU_SORT to use the new function instead of the
old one, respectively.  Patch 4 removes the old core function that was
replaced by the new one, as there is no more user of it.  Patch 5
updates DAMON_STAT to use the new one instead of its in-house
nearly-duplicate self implementation of the functionality.  Finally
patches 6 and 7 update the DAMON_RECLAIM and DAMON_LRU_SORT user
documentation for the new behaviors, respectively.

Changes from RFC
- rfc: https://lore.kernel.org/20260415012048.76508-1-sj@kernel.org
- Fix typos: s/phiscal/physical/

SeongJae Park (7):
  mm/damon: introduce damon_set_region_system_rams_default()
  mm/damon/reclaim: cover all system rams
  mm/damon/lru_sort: cover all system rams
  mm/damon/core: remove damon_set_region_biggest_system_ram_default()
  mm/damon/stat: use damon_set_region_system_rams_default()
  Docs/admin-guide/mm/damon/reclaim: update for entire memory monitoring
  Docs/admin-guide/mm/damon/lru_sort: update for entire memory
    monitoring

 .../admin-guide/mm/damon/lru_sort.rst         |  6 ++-
 .../admin-guide/mm/damon/reclaim.rst          |  6 ++-
 include/linux/damon.h                         |  2 +-
 mm/damon/core.c                               | 49 +++++++++--------
 mm/damon/lru_sort.c                           |  8 +--
 mm/damon/reclaim.c                            | 14 ++---
 mm/damon/stat.c                               | 53 ++-----------------
 7 files changed, 50 insertions(+), 88 deletions(-)


base-commit: 01b1d4a72970ced030ffe246ba99c961c746527d
-- 
2.47.3

[PATCH 1/7] mm/damon: introduce damon_set_region_system_rams_default()

[SeongJae Park]

damon_set_region_biggest_system_ram_default() sets the monitoring target
region as the caller requested.  If the caller didn't specify the
region, it finds the biggest System RAM of the system and sets it as the
target region.  When there are more than one considerable size of System
RAM resources in the system, the default target setup makes no sense.
Introduce a variant, namely damon_set_region_system_rams_default().  It
sets a physical address range that covers all System RAM resources as
the default target region.

Signed-off-by: SeongJae Park <sj@kernel.org>
---
 include/linux/damon.h |  5 +++
 mm/damon/core.c       | 77 ++++++++++++++++++++++++++++++++++++++++---
 2 files changed, 77 insertions(+), 5 deletions(-)

diff --git a/include/linux/damon.h b/include/linux/damon.h
index f2370a3a4a9a3..f656908b2d389 100644
--- a/include/linux/damon.h
+++ b/include/linux/damon.h
@@ -1010,6 +1010,11 @@ int damon_kdamond_pid(struct damon_ctx *ctx);
 int damon_call(struct damon_ctx *ctx, struct damon_call_control *control);
 int damos_walk(struct damon_ctx *ctx, struct damos_walk_control *control);
 
+int damon_set_region_system_rams_default(struct damon_target *t,
+				unsigned long *start, unsigned long *end,
+				unsigned long addr_unit,
+				unsigned long min_region_sz);
+
 int damon_set_region_biggest_system_ram_default(struct damon_target *t,
 				unsigned long *start, unsigned long *end,
 				unsigned long addr_unit,
diff --git a/mm/damon/core.c b/mm/damon/core.c
index 05e4bef367dbf..980a31cd3498e 100644
--- a/mm/damon/core.c
+++ b/mm/damon/core.c
@@ -3328,14 +3328,20 @@ static int kdamond_fn(void *data)
 	return 0;
 }
 
-static int walk_system_ram(struct resource *res, void *arg)
+struct damon_system_ram_range_walk_arg {
+	bool walked;
+	struct resource res;
+};
+
+static int damon_system_ram_walk_fn(struct resource *res, void *arg)
 {
-	struct resource *a = arg;
+	struct damon_system_ram_range_walk_arg *a = arg;
 
-	if (resource_size(a) < resource_size(res)) {
-		a->start = res->start;
-		a->end = res->end;
+	if (!a->walked) {
+		a->walked = true;
+		a->res.start = res->start;
 	}
+	a->res.end = res->end;
 	return 0;
 }
 
@@ -3352,6 +3358,67 @@ static unsigned long damon_res_to_core_addr(resource_size_t ra,
 	return ra / addr_unit;
 }
 
+static bool damon_find_system_rams_range(unsigned long *start,
+		unsigned long *end, unsigned long addr_unit)
+{
+	struct damon_system_ram_range_walk_arg arg = {};
+
+	walk_system_ram_res(0, -1, &arg, damon_system_ram_walk_fn);
+	if (!arg.walked)
+		return false;
+	*start = damon_res_to_core_addr(arg.res.start, addr_unit);
+	*end = damon_res_to_core_addr(arg.res.end + 1, addr_unit);
+	if (*end <= *start)
+		return false;
+	return true;
+}
+
+/**
+ * damon_set_region_system_rams_default() - Set the region of the given
+ * monitoring target as requested, or to cover all 'System RAM' resources.
+ * @t:		The monitoring target to set the region.
+ * @start:	The pointer to the start address of the region.
+ * @end:	The pointer to the end address of the region.
+ * @addr_unit:	The address unit for the damon_ctx of @t.
+ * @min_region_sz:	Minimum region size.
+ *
+ * This function sets the region of @t as requested by @start and @end.  If the
+ * values of @start and @end are zero, however, this function finds 'System
+ * RAM' resources and sets the region to cover all the resource.  In the latter
+ * case, this function saves the start and the end addresseses of the first and
+ * the last resources in @start and @end, respectively.
+ *
+ * Return: 0 on success, negative error code otherwise.
+ */
+int damon_set_region_system_rams_default(struct damon_target *t,
+			unsigned long *start, unsigned long *end,
+			unsigned long addr_unit, unsigned long min_region_sz)
+{
+	struct damon_addr_range addr_range;
+
+	if (*start > *end)
+		return -EINVAL;
+
+	if (!*start && !*end &&
+		!damon_find_system_rams_range(start, end, addr_unit))
+		return -EINVAL;
+
+	addr_range.start = *start;
+	addr_range.end = *end;
+	return damon_set_regions(t, &addr_range, 1, min_region_sz);
+}
+
+static int walk_system_ram(struct resource *res, void *arg)
+{
+	struct resource *a = arg;
+
+	if (resource_size(a) < resource_size(res)) {
+		a->start = res->start;
+		a->end = res->end;
+	}
+	return 0;
+}
+
 /*
  * Find biggest 'System RAM' resource and store its start and end address in
  * @start and @end, respectively.  If no System RAM is found, returns false.
-- 
2.47.3

Re: [PATCH 1/7] mm/damon: introduce damon_set_region_system_rams_default()

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [High] The default region setup creates a single contiguous bounding box encompassing all System RAM resources, incorrectly including unpopulated memory holes.
- [High] Integer overflow during physical address boundary calculation (`arg.res.end + 1`) can cause DAMON initialization to fail.
--

commit cd855b0d7d334ccf9a13e1331105a3281e5b0aeb
Author: SeongJae Park <sj@kernel.org>

mm/damon: introduce damon_set_region_system_rams_default()

Introduces a default target setup for DAMON that sets a physical address
range covering all System RAM resources when the caller doesn't specify
a region.

> diff --git a/mm/damon/core.c b/mm/damon/core.c
> index 05e4bef367db..980a31cd3498 100644
> --- a/mm/damon/core.c
> +++ b/mm/damon/core.c
[ ... ]
> +static bool damon_find_system_rams_range(unsigned long *start,
> +		unsigned long *end, unsigned long addr_unit)
> +{
> +	struct damon_system_ram_range_walk_arg arg = {};
> +
> +	walk_system_ram_res(0, -1, &arg, damon_system_ram_walk_fn);
> +	if (!arg.walked)
> +		return false;
> +	*start = damon_res_to_core_addr(arg.res.start, addr_unit);
> +	*end = damon_res_to_core_addr(arg.res.end + 1, addr_unit);

Can arg.res.end + 1 overflow here?

If a 32-bit system has physical memory extending to the end of the address
space, arg.res.end will be the maximum representable value. Adding 1 would
overflow to 0, making *end 0. The subsequent check if (*end <= *start)
would then evaluate to true, causing the function to silently return false
and abort initialization with -EINVAL.

> +	if (*end <= *start)
> +		return false;
> +	return true;
> +}
[ ... ]
> +int damon_set_region_system_rams_default(struct damon_target *t,
> +			unsigned long *start, unsigned long *end,
> +			unsigned long addr_unit, unsigned long min_region_sz)
> +{
> +	struct damon_addr_range addr_range;
> +
> +	if (*start > *end)
> +		return -EINVAL;
> +
> +	if (!*start && !*end &&
> +		!damon_find_system_rams_range(start, end, addr_unit))
> +		return -EINVAL;
> +
> +	addr_range.start = *start;
> +	addr_range.end = *end;
> +	return damon_set_regions(t, &addr_range, 1, min_region_sz);

Does this create a single bounding box encompassing all System RAM resources,
including unpopulated memory holes?

On systems with sparse physical memory layouts, this combined range will
encompass massive memory holes. Because DAMON uses uniform random sampling
within a region to estimate access frequencies, samples landing in the gaps
will inherently register as unaccessed, diluting the perceived access rates
and preventing effective adaptive region splitting and merging.

Could the implementation instead construct an array of multiple ranges,
one for each distinct System RAM resource, and pass them to
damon_set_regions()?

> +}

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260429041232.90257-1-sj@kernel.org?part=1

Re: [PATCH 1/7] mm/damon: introduce damon_set_region_system_rams_default()

[SeongJae Park]

On Wed, 29 Apr 2026 04:39:02 +0000 sashiko-bot@kernel.org wrote:

> Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
> - [High] The default region setup creates a single contiguous bounding box encompassing all System RAM resources, incorrectly including unpopulated memory holes.
> - [High] Integer overflow during physical address boundary calculation (`arg.res.end + 1`) can cause DAMON initialization to fail.

Both are not a blocker of this patch in my opinion.  Please read below for
details.

> --
> 
> commit cd855b0d7d334ccf9a13e1331105a3281e5b0aeb
> Author: SeongJae Park <sj@kernel.org>
> 
> mm/damon: introduce damon_set_region_system_rams_default()
> 
> Introduces a default target setup for DAMON that sets a physical address
> range covering all System RAM resources when the caller doesn't specify
> a region.
> 
> > diff --git a/mm/damon/core.c b/mm/damon/core.c
> > index 05e4bef367db..980a31cd3498 100644
> > --- a/mm/damon/core.c
> > +++ b/mm/damon/core.c
> [ ... ]
> > +static bool damon_find_system_rams_range(unsigned long *start,
> > +		unsigned long *end, unsigned long addr_unit)
> > +{
> > +	struct damon_system_ram_range_walk_arg arg = {};
> > +
> > +	walk_system_ram_res(0, -1, &arg, damon_system_ram_walk_fn);
> > +	if (!arg.walked)
> > +		return false;
> > +	*start = damon_res_to_core_addr(arg.res.start, addr_unit);
> > +	*end = damon_res_to_core_addr(arg.res.end + 1, addr_unit);
> 
> Can arg.res.end + 1 overflow here?
> 
> If a 32-bit system has physical memory extending to the end of the address
> space, arg.res.end will be the maximum representable value. Adding 1 would
> overflow to 0, making *end 0. The subsequent check if (*end <= *start)
> would then evaluate to true, causing the function to silently return false
> and abort initialization with -EINVAL.

Yes, such corner case could exist.  But, similar overflow-caused initialization
could happen even before this patch, if the biggest System RAM's end address is
same to the U32T_MAX.  And even in the corner case, failing initialization
shouldn't cause a real problem.  The user could manually set the monitoring
regions and work.

So, not a blocker of this patch.

> 
> > +	if (*end <= *start)
> > +		return false;
> > +	return true;
> > +}
> [ ... ]
> > +int damon_set_region_system_rams_default(struct damon_target *t,
> > +			unsigned long *start, unsigned long *end,
> > +			unsigned long addr_unit, unsigned long min_region_sz)
> > +{
> > +	struct damon_addr_range addr_range;
> > +
> > +	if (*start > *end)
> > +		return -EINVAL;
> > +
> > +	if (!*start && !*end &&
> > +		!damon_find_system_rams_range(start, end, addr_unit))
> > +		return -EINVAL;
> > +
> > +	addr_range.start = *start;
> > +	addr_range.end = *end;
> > +	return damon_set_regions(t, &addr_range, 1, min_region_sz);
> 
> Does this create a single bounding box encompassing all System RAM resources,
> including unpopulated memory holes?
> 
> On systems with sparse physical memory layouts, this combined range will
> encompass massive memory holes. Because DAMON uses uniform random sampling
> within a region to estimate access frequencies, samples landing in the gaps
> will inherently register as unaccessed, diluting the perceived access rates
> and preventing effective adaptive region splitting and merging.

As also answered to the same previous questions, DAMON's adaptive regions
adjustment mechanism should solve this accuracy issue.

So, not a blocker for this patch.

> 
> Could the implementation instead construct an array of multiple ranges,
> one for each distinct System RAM resource, and pass them to
> damon_set_regions()?

When the number of such distinct areas is high, because distict regions cannot
be merged, it will degrade the accuracy.  So, no.  Like vaddr, adding a finite
number of biggest gaps might make sense.  But, it wouldn't be late to revist
after such problematic real use case is found.


Thanks,
SJ

[...]

[PATCH 2/7] mm/damon/reclaim: cover all system rams

[SeongJae Park]

DAMON_RECLAIM allows users to set the physical address range to monitor
and do the work on.  When users don't explicitly set the range, the
biggest System RAM resource of the system is selected as the monitoring
target address range.  The intention was to reduce the overhead from
monitoring non-System RAM areas because monitoring of non-System RAM may
be meaningless.  However, because of the sampling based access check and
adaptive regions adjustment, the overhead should be negligible.  It
makes more sense to just cover all system rams of the system.  Do so.

Signed-off-by: SeongJae Park <sj@kernel.org>
---
 mm/damon/reclaim.c | 14 +++++++-------
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/mm/damon/reclaim.c b/mm/damon/reclaim.c
index b330ff1695907..a60ee800d63e9 100644
--- a/mm/damon/reclaim.c
+++ b/mm/damon/reclaim.c
@@ -113,7 +113,8 @@ DEFINE_DAMON_MODULES_MON_ATTRS_PARAMS(damon_reclaim_mon_attrs);
  * Start of the target memory region in physical address.
  *
  * The start physical address of memory region that DAMON_RECLAIM will do work
- * against.  By default, biggest System RAM is used as the region.
+ * against.  By default, the system's entire physical memory is used as the
+ * region.
  */
 static unsigned long monitor_region_start __read_mostly;
 module_param(monitor_region_start, ulong, 0600);
@@ -122,7 +123,8 @@ module_param(monitor_region_start, ulong, 0600);
  * End of the target memory region in physical address.
  *
  * The end physical address of memory region that DAMON_RECLAIM will do work
- * against.  By default, biggest System RAM is used as the region.
+ * against.  By default, the system's entire physical memory is used as the
+ * region.
  */
 static unsigned long monitor_region_end __read_mostly;
 module_param(monitor_region_end, ulong, 0600);
@@ -232,11 +234,9 @@ static int damon_reclaim_apply_parameters(void)
 		damos_add_filter(scheme, filter);
 	}
 
-	err = damon_set_region_biggest_system_ram_default(param_target,
-					&monitor_region_start,
-					&monitor_region_end,
-					param_ctx->addr_unit,
-					param_ctx->min_region_sz);
+	err = damon_set_region_system_rams_default(param_target,
+			&monitor_region_start, &monitor_region_end,
+			param_ctx->addr_unit, param_ctx->min_region_sz);
 	if (err)
 		goto out;
 	err = damon_commit_ctx(ctx, param_ctx);
-- 
2.47.3

Re: [PATCH 2/7] mm/damon/reclaim: cover all system rams

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [High] Massive single DAMON region spanning physical address holes causes CPU soft lockups and quota starvation.
- [High] Time-of-Check to Time-of-Use (TOCTOU) vulnerability in damon_set_region_system_rams_default() leads to infinite loop and OOM panic.
--

commit 179df0c96a01c49e5644b5cc1a9154fb63368993
Author: SeongJae Park <sj@kernel.org>

mm/damon/reclaim: cover all system rams

This commit changes DAMON_RECLAIM to monitor the entire system RAM by
default, rather than just the biggest System RAM region, to cover all
available memory.

> diff --git a/mm/damon/reclaim.c b/mm/damon/reclaim.c
> index b330ff169590..a60ee800d63e 100644
> --- a/mm/damon/reclaim.c
> +++ b/mm/damon/reclaim.c

[ ... ]

> @@ -232,11 +234,9 @@ static int damon_reclaim_apply_parameters(void)
>  		damos_add_filter(scheme, filter);
>  	}
>  
> -	err = damon_set_region_biggest_system_ram_default(param_target,
> -					&monitor_region_start,
> -					&monitor_region_end,
> -					param_ctx->addr_unit,
> -					param_ctx->min_region_sz);
> +	err = damon_set_region_system_rams_default(param_target,
> +			&monitor_region_start, &monitor_region_end,
> +			param_ctx->addr_unit, param_ctx->min_region_sz);

Can monitor_region_start and monitor_region_end be modified concurrently
via sysfs module parameters while this code is executing?

Looking at damon_set_region_system_rams_default(), the pointers are
dereferenced multiple times:

mm/damon/core.c:damon_set_region_system_rams_default() {
	if (*start > *end)
		return -EINVAL;

	if (!*start && !*end &&
		!damon_find_system_rams_range(start, end, addr_unit))
		return -EINVAL;

	addr_range.start = *start;
	addr_range.end = *end;
	return damon_set_regions(t, &addr_range, 1, min_region_sz);
}

If a concurrent sysfs write alters the values between the initial check and
the subsequent assignment, could this result in an inverted range where start
is greater than end?

If an inverted range is passed to damon_set_regions(), the size calculation
(end - start) could underflow to a massive value. When the thread later
executes damon_apply_min_nr_regions(), it might enter an infinite loop trying
to split the underflowed region, endlessly allocating damon_region objects.

Additionally, could damon_find_system_rams_range() create a single bounding
box that spans massive unpopulated physical address holes on sparse memory
systems?

Since DAMON applies schemes by linearly looping over the region page-by-page,
would spinning over terabytes of holes without calling cond_resched() cause
CPU soft lockups?

Furthermore, because these holes are never accessed, they might perfectly match
PAGEOUT schemes. Could the massive region size (including holes) be incorrectly
charged against the reclaim quota, instantly depleting it and preventing actual
RAM from being reclaimed?

Would it be better to dynamically populate multiple regions (one for each
RAM block) instead of using a single bounding box?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260429041232.90257-1-sj@kernel.org?part=2

Re: [PATCH 2/7] mm/damon/reclaim: cover all system rams

[SeongJae Park]

On Wed, 29 Apr 2026 05:23:16 +0000 sashiko-bot@kernel.org wrote:

> Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
> - [High] Massive single DAMON region spanning physical address holes causes CPU soft lockups and quota starvation.
> - [High] Time-of-Check to Time-of-Use (TOCTOU) vulnerability in damon_set_region_system_rams_default() leads to infinite loop and OOM panic.

No blocker of this patch in my opinion.  Pleae read below for more details.

> --
> 
> commit 179df0c96a01c49e5644b5cc1a9154fb63368993
> Author: SeongJae Park <sj@kernel.org>
> 
> mm/damon/reclaim: cover all system rams
> 
> This commit changes DAMON_RECLAIM to monitor the entire system RAM by
> default, rather than just the biggest System RAM region, to cover all
> available memory.
> 
> > diff --git a/mm/damon/reclaim.c b/mm/damon/reclaim.c
> > index b330ff169590..a60ee800d63e 100644
> > --- a/mm/damon/reclaim.c
> > +++ b/mm/damon/reclaim.c
> 
> [ ... ]
> 
> > @@ -232,11 +234,9 @@ static int damon_reclaim_apply_parameters(void)
> >  		damos_add_filter(scheme, filter);
> >  	}
> >  
> > -	err = damon_set_region_biggest_system_ram_default(param_target,
> > -					&monitor_region_start,
> > -					&monitor_region_end,
> > -					param_ctx->addr_unit,
> > -					param_ctx->min_region_sz);
> > +	err = damon_set_region_system_rams_default(param_target,
> > +			&monitor_region_start, &monitor_region_end,
> > +			param_ctx->addr_unit, param_ctx->min_region_sz);
> 
> Can monitor_region_start and monitor_region_end be modified concurrently
> via sysfs module parameters while this code is executing?

No.

The function can be invoked in three places.

1. damon_reclaim_init()
2. enabled parameter write callback
3. commit_inputs parameter write callback

Because init function is called before users can write to sysfs, path 1 cannot
race with paths 2 and 3.  Because parameter write callbacks are protected by
kernel_param_lock, paths 2 and 3 cannot race each other.

> 
> Looking at damon_set_region_system_rams_default(), the pointers are
> dereferenced multiple times:
> 
> mm/damon/core.c:damon_set_region_system_rams_default() {
> 	if (*start > *end)
> 		return -EINVAL;
> 
> 	if (!*start && !*end &&
> 		!damon_find_system_rams_range(start, end, addr_unit))
> 		return -EINVAL;
> 
> 	addr_range.start = *start;
> 	addr_range.end = *end;
> 	return damon_set_regions(t, &addr_range, 1, min_region_sz);
> }
> 
> If a concurrent sysfs write alters the values between the initial check and
> the subsequent assignment, could this result in an inverted range where start
> is greater than end?
> 
> If an inverted range is passed to damon_set_regions(), the size calculation
> (end - start) could underflow to a massive value. When the thread later
> executes damon_apply_min_nr_regions(), it might enter an infinite loop trying
> to split the underflowed region, endlessly allocating damon_region objects.

So, such an issue cannot happen.

> 
> Additionally, could damon_find_system_rams_range() create a single bounding
> box that spans massive unpopulated physical address holes on sparse memory
> systems?
> 
> Since DAMON applies schemes by linearly looping over the region page-by-page,
> would spinning over terabytes of holes without calling cond_resched() cause
> CPU soft lockups?

Answered on RFC.  To repeat, operations for the holes should be lightweight
enough, since we will just see it is hole and move to next page.  Users can
manually set the monitoring regions.

> 
> Furthermore, because these holes are never accessed, they might perfectly match
> PAGEOUT schemes. Could the massive region size (including holes) be incorrectly
> charged against the reclaim quota, instantly depleting it and preventing actual
> RAM from being reclaimed?

Also answered on RFC.  Users can manually set the regions for this kind of
extremem corner case.

> 
> Would it be better to dynamically populate multiple regions (one for each
> RAM block) instead of using a single bounding box?

I answered this on the review to the first patch of this series.


Thanks,
SJ

[...]

[PATCH 3/7] mm/damon/lru_sort: cover all system rams

[SeongJae Park]

DAMON_LRU_SORT allows users to set the physical address range to monitor
and do the work on.  When users don't explicitly set the range, the
biggest system ram resource of the system is selected as the monitoring
target address range.  The intention was to reduce the overhead from
monitoring non-System RAM areas because monitoring non-System RAM may be
meaningless.  However, because of the sampling based access check and
adaptive regions adjustment, the overhead should be negligible.  It
makes more sense to just cover all system rams of the system.  Do so.

Signed-off-by: SeongJae Park <sj@kernel.org>
---
 mm/damon/lru_sort.c | 8 +++++---
 1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/mm/damon/lru_sort.c b/mm/damon/lru_sort.c
index 7569e471160a0..2eb559d913b62 100644
--- a/mm/damon/lru_sort.c
+++ b/mm/damon/lru_sort.c
@@ -139,7 +139,8 @@ DEFINE_DAMON_MODULES_MON_ATTRS_PARAMS(damon_lru_sort_mon_attrs);
  * Start of the target memory region in physical address.
  *
  * The start physical address of memory region that DAMON_LRU_SORT will do work
- * against.  By default, biggest System RAM is used as the region.
+ * against.  By default, the system's entire physical memory is used as the
+ * region.
  */
 static unsigned long monitor_region_start __read_mostly;
 module_param(monitor_region_start, ulong, 0600);
@@ -148,7 +149,8 @@ module_param(monitor_region_start, ulong, 0600);
  * End of the target memory region in physical address.
  *
  * The end physical address of memory region that DAMON_LRU_SORT will do work
- * against.  By default, biggest System RAM is used as the region.
+ * against.  By default, the system's entire physical memory is used as the
+ * region.
  */
 static unsigned long monitor_region_end __read_mostly;
 module_param(monitor_region_end, ulong, 0600);
@@ -326,7 +328,7 @@ static int damon_lru_sort_apply_parameters(void)
 	if (err)
 		goto out;
 
-	err = damon_set_region_biggest_system_ram_default(param_target,
+	err = damon_set_region_system_rams_default(param_target,
 					&monitor_region_start,
 					&monitor_region_end,
 					param_ctx->addr_unit,
-- 
2.47.3

Re: [PATCH 3/7] mm/damon/lru_sort: cover all system rams

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] Single bounding box for sparse memory layouts causes soft lockups and algorithmic failure
--

commit 692650636f4214ec9c2fa1c5d7fd43fe3bf049fe
Author: SeongJae Park <sj@kernel.org>

mm/damon/lru_sort: cover all system rams

This commit changes the default monitoring region from the biggest System RAM
resource to a single region that spans all system RAMs. This is intended to
cover the entire physical memory instead of just the largest block.

> diff --git a/mm/damon/lru_sort.c b/mm/damon/lru_sort.c
> index 7569e471160a..2eb559d913b6 100644
> --- a/mm/damon/lru_sort.c
> +++ b/mm/damon/lru_sort.c

[ ... ]

> @@ -326,7 +328,7 @@ static int damon_lru_sort_apply_parameters(void)
>  	if (err)
>  		goto out;
>  
> -	err = damon_set_region_biggest_system_ram_default(param_target,
> +	err = damon_set_region_system_rams_default(param_target,
>  					&monitor_region_start,
>  					&monitor_region_end,
>  					param_ctx->addr_unit,

Could this lead to a regression on systems with sparse memory layouts?

When creating a single bounding box from the first to the last physical
address, systems with sparse memory like CXL or distant NUMA nodes could end
up with a region containing terabytes of unpopulated physical address space.

Will this cause soft lockups during DAMOS operations?

If a scheme like PAGEOUT iterates linearly over this massive region in
PAGE_SIZE increments, iterating over these large memory holes might stall the
CPU and trigger the watchdog, since cond_resched() is typically placed after
the loop.

Does this also cause an algorithmic regression with the sampling probability?

DAMON's adaptive logic merges adjacent regions with identical access
frequencies. Since memory holes report 0 accesses, they might be aggressively
merged with interspersed RAM into maximum-sized regions. Because sampling
selects a single random address per region, the probability of actually
sampling the populated RAM might drop to near zero.

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260429041232.90257-1-sj@kernel.org?part=3

Re: [PATCH 3/7] mm/damon/lru_sort: cover all system rams

[SeongJae Park]

On Wed, 29 Apr 2026 06:03:13 +0000 sashiko-bot@kernel.org wrote:

> Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
> - [High] Single bounding box for sparse memory layouts causes soft lockups and algorithmic failure

Not a real issue in my opinion.  Please read below for more details.

> --
> 
> commit 692650636f4214ec9c2fa1c5d7fd43fe3bf049fe
> Author: SeongJae Park <sj@kernel.org>
> 
> mm/damon/lru_sort: cover all system rams
> 
> This commit changes the default monitoring region from the biggest System RAM
> resource to a single region that spans all system RAMs. This is intended to
> cover the entire physical memory instead of just the largest block.
> 
> > diff --git a/mm/damon/lru_sort.c b/mm/damon/lru_sort.c
> > index 7569e471160a..2eb559d913b6 100644
> > --- a/mm/damon/lru_sort.c
> > +++ b/mm/damon/lru_sort.c
> 
> [ ... ]
> 
> > @@ -326,7 +328,7 @@ static int damon_lru_sort_apply_parameters(void)
> >  	if (err)
> >  		goto out;
> >  
> > -	err = damon_set_region_biggest_system_ram_default(param_target,
> > +	err = damon_set_region_system_rams_default(param_target,
> >  					&monitor_region_start,
> >  					&monitor_region_end,
> >  					param_ctx->addr_unit,
> 
> Could this lead to a regression on systems with sparse memory layouts?
> 
> When creating a single bounding box from the first to the last physical
> address, systems with sparse memory like CXL or distant NUMA nodes could end
> up with a region containing terabytes of unpopulated physical address space.
> 
> Will this cause soft lockups during DAMOS operations?
> 
> If a scheme like PAGEOUT iterates linearly over this massive region in
> PAGE_SIZE increments, iterating over these large memory holes might stall the
> CPU and trigger the watchdog, since cond_resched() is typically placed after
> the loop.
> 
> Does this also cause an algorithmic regression with the sampling probability?
> 
> DAMON's adaptive logic merges adjacent regions with identical access
> frequencies. Since memory holes report 0 accesses, they might be aggressively
> merged with interspersed RAM into maximum-sized regions. Because sampling
> selects a single random address per region, the probability of actually
> sampling the populated RAM might drop to near zero.

Exactly same question to the one for the second patch of this series.  My
answer to it is also samely applied here.  Not a real issue.


Thanks,
SJ

[...]

[PATCH 4/7] mm/damon/core: remove damon_set_region_biggest_system_ram_default()

[SeongJae Park]

Now nobody is using damon_set_region_biggest_system_ram_default().
Remove it.

Signed-off-by: SeongJae Park <sj@kernel.org>
---
 include/linux/damon.h |  5 ----
 mm/damon/core.c       | 64 -------------------------------------------
 2 files changed, 69 deletions(-)

diff --git a/include/linux/damon.h b/include/linux/damon.h
index f656908b2d389..c7a31572689be 100644
--- a/include/linux/damon.h
+++ b/include/linux/damon.h
@@ -1015,11 +1015,6 @@ int damon_set_region_system_rams_default(struct damon_target *t,
 				unsigned long addr_unit,
 				unsigned long min_region_sz);
 
-int damon_set_region_biggest_system_ram_default(struct damon_target *t,
-				unsigned long *start, unsigned long *end,
-				unsigned long addr_unit,
-				unsigned long min_region_sz);
-
 #endif	/* CONFIG_DAMON */
 
 #endif	/* _DAMON_H */
diff --git a/mm/damon/core.c b/mm/damon/core.c
index 980a31cd3498e..9f38deddcb30e 100644
--- a/mm/damon/core.c
+++ b/mm/damon/core.c
@@ -3408,70 +3408,6 @@ int damon_set_region_system_rams_default(struct damon_target *t,
 	return damon_set_regions(t, &addr_range, 1, min_region_sz);
 }
 
-static int walk_system_ram(struct resource *res, void *arg)
-{
-	struct resource *a = arg;
-
-	if (resource_size(a) < resource_size(res)) {
-		a->start = res->start;
-		a->end = res->end;
-	}
-	return 0;
-}
-
-/*
- * Find biggest 'System RAM' resource and store its start and end address in
- * @start and @end, respectively.  If no System RAM is found, returns false.
- */
-static bool damon_find_biggest_system_ram(unsigned long *start,
-		unsigned long *end, unsigned long addr_unit)
-
-{
-	struct resource res = {};
-
-	walk_system_ram_res(0, -1, &res, walk_system_ram);
-	*start = damon_res_to_core_addr(res.start, addr_unit);
-	*end = damon_res_to_core_addr(res.end + 1, addr_unit);
-	if (*end <= *start)
-		return false;
-	return true;
-}
-
-/**
- * damon_set_region_biggest_system_ram_default() - Set the region of the given
- * monitoring target as requested, or biggest 'System RAM'.
- * @t:		The monitoring target to set the region.
- * @start:	The pointer to the start address of the region.
- * @end:	The pointer to the end address of the region.
- * @addr_unit:	The address unit for the damon_ctx of @t.
- * @min_region_sz:	Minimum region size.
- *
- * This function sets the region of @t as requested by @start and @end.  If the
- * values of @start and @end are zero, however, this function finds the biggest
- * 'System RAM' resource and sets the region to cover the resource.  In the
- * latter case, this function saves the start and end addresses of the resource
- * in @start and @end, respectively.
- *
- * Return: 0 on success, negative error code otherwise.
- */
-int damon_set_region_biggest_system_ram_default(struct damon_target *t,
-			unsigned long *start, unsigned long *end,
-			unsigned long addr_unit, unsigned long min_region_sz)
-{
-	struct damon_addr_range addr_range;
-
-	if (*start > *end)
-		return -EINVAL;
-
-	if (!*start && !*end &&
-			!damon_find_biggest_system_ram(start, end, addr_unit))
-		return -EINVAL;
-
-	addr_range.start = *start;
-	addr_range.end = *end;
-	return damon_set_regions(t, &addr_range, 1, min_region_sz);
-}
-
 /*
  * damon_moving_sum() - Calculate an inferred moving sum value.
  * @mvsum:	Inferred sum of the last @len_window values.
-- 
2.47.3

[PATCH 5/7] mm/damon/stat: use damon_set_region_system_rams_default()

[SeongJae Park]

damon_stat_set_moniotirng_region() is nearly a duplicate of the core
function, damon_set_region_system_rams_default().  Use the core
implementation.

Signed-off-by: SeongJae Park <sj@kernel.org>
---
 mm/damon/stat.c | 53 +++----------------------------------------------
 1 file changed, 3 insertions(+), 50 deletions(-)

diff --git a/mm/damon/stat.c b/mm/damon/stat.c
index 3951b762cbddf..f4d3203e92639 100644
--- a/mm/damon/stat.c
+++ b/mm/damon/stat.c
@@ -148,59 +148,12 @@ static int damon_stat_damon_call_fn(void *data)
 	return 0;
 }
 
-struct damon_stat_system_ram_range_walk_arg {
-	bool walked;
-	struct resource res;
-};
-
-static int damon_stat_system_ram_walk_fn(struct resource *res, void *arg)
-{
-	struct damon_stat_system_ram_range_walk_arg *a = arg;
-
-	if (!a->walked) {
-		a->walked = true;
-		a->res.start = res->start;
-	}
-	a->res.end = res->end;
-	return 0;
-}
-
-static unsigned long damon_stat_res_to_core_addr(resource_size_t ra,
-		unsigned long addr_unit)
-{
-	/*
-	 * Use div_u64() for avoiding linking errors related with __udivdi3,
-	 * __aeabi_uldivmod, or similar problems.  This should also improve the
-	 * performance optimization (read div_u64() comment for the detail).
-	 */
-	if (sizeof(ra) == 8 && sizeof(addr_unit) == 4)
-		return div_u64(ra, addr_unit);
-	return ra / addr_unit;
-}
-
-static int damon_stat_set_monitoring_region(struct damon_target *t,
-		unsigned long addr_unit, unsigned long min_region_sz)
-{
-	struct damon_addr_range addr_range;
-	struct damon_stat_system_ram_range_walk_arg arg = {};
-
-	walk_system_ram_res(0, -1, &arg, damon_stat_system_ram_walk_fn);
-	if (!arg.walked)
-		return -EINVAL;
-	addr_range.start = damon_stat_res_to_core_addr(
-			arg.res.start, addr_unit);
-	addr_range.end = damon_stat_res_to_core_addr(
-			arg.res.end + 1, addr_unit);
-	if (addr_range.end <= addr_range.start)
-		return -EINVAL;
-	return damon_set_regions(t, &addr_range, 1, min_region_sz);
-}
-
 static struct damon_ctx *damon_stat_build_ctx(void)
 {
 	struct damon_ctx *ctx;
 	struct damon_attrs attrs;
 	struct damon_target *target;
+	unsigned long start = 0, end = 0;
 
 	ctx = damon_new_ctx();
 	if (!ctx)
@@ -230,8 +183,8 @@ static struct damon_ctx *damon_stat_build_ctx(void)
 	if (!target)
 		goto free_out;
 	damon_add_target(ctx, target);
-	if (damon_stat_set_monitoring_region(target, ctx->addr_unit,
-				ctx->min_region_sz))
+	if (damon_set_region_system_rams_default(target, &start, &end,
+				ctx->addr_unit, ctx->min_region_sz))
 		goto free_out;
 	return ctx;
 free_out:
-- 
2.47.3

[PATCH 6/7] Docs/admin-guide/mm/damon/reclaim: update for entire memory monitoring

[SeongJae Park]

Update DAMON_RECLAIM usage document for the changed default monitoring
target region selection.

Signed-off-by: SeongJae Park <sj@kernel.org>
---
 Documentation/admin-guide/mm/damon/reclaim.rst | 6 ++++--
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/Documentation/admin-guide/mm/damon/reclaim.rst b/Documentation/admin-guide/mm/damon/reclaim.rst
index 01a34c215b66f..57ab8b1876506 100644
--- a/Documentation/admin-guide/mm/damon/reclaim.rst
+++ b/Documentation/admin-guide/mm/damon/reclaim.rst
@@ -229,7 +229,8 @@ Start of target memory region in physical address.
 
 The start physical address of memory region that DAMON_RECLAIM will do work
 against.  That is, DAMON_RECLAIM will find cold memory regions in this region
-and reclaims.  By default, biggest System RAM is used as the region.
+and reclaims.  By default, the system's entire physical memory is used as the
+region.
 
 monitor_region_end
 ------------------
@@ -238,7 +239,8 @@ End of target memory region in physical address.
 
 The end physical address of memory region that DAMON_RECLAIM will do work
 against.  That is, DAMON_RECLAIM will find cold memory regions in this region
-and reclaims.  By default, biggest System RAM is used as the region.
+and reclaims.  By default, the system's entire physical memory is used as the
+region.
 
 addr_unit
 ---------
-- 
2.47.3

Re: [PATCH 6/7] Docs/admin-guide/mm/damon/reclaim: update for entire memory monitoring

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Low] The commit updates the English documentation for DAMON_RECLAIM but fails to update the corresponding translated documents.
--

commit 0775463e5909bcac92ff21d728b9a1b112304371
Author: SeongJae Park <sj@kernel.org>

Docs/admin-guide/mm/damon/reclaim: update for entire memory monitoring

This commit updates the DAMON_RECLAIM usage document to reflect the new
default monitoring target region selection, which now spans the system's
entire physical memory instead of just the biggest System RAM region.

> diff --git a/Documentation/admin-guide/mm/damon/reclaim.rst b/Documentation/admin-guide/mm/damon/reclaim.rst
> index 01a34c215b66..57ab8b187650 100644
> --- a/Documentation/admin-guide/mm/damon/reclaim.rst
> +++ b/Documentation/admin-guide/mm/damon/reclaim.rst
> @@ -229,7 +229,8 @@ Start of target memory region in physical address.
>  
>  The start physical address of memory region that DAMON_RECLAIM will do work
>  against.  That is, DAMON_RECLAIM will find cold memory regions in this region
> -and reclaims.  By default, biggest System RAM is used as the region.
> +and reclaims.  By default, the system's entire physical memory is used as the
> +region.

Should the corresponding zh_CN and zh_TW translations be updated alongside
this to keep them in sync? The translated documents currently still state
that the biggest System RAM is used by default.

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260429041232.90257-1-sj@kernel.org?part=6

Re: [PATCH 6/7] Docs/admin-guide/mm/damon/reclaim: update for entire memory monitoring

[SeongJae Park]

On Wed, 29 Apr 2026 07:02:01 +0000 sashiko-bot@kernel.org wrote:

> Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
> - [Low] The commit updates the English documentation for DAMON_RECLAIM but fails to update the corresponding translated documents.
> --
> 
> commit 0775463e5909bcac92ff21d728b9a1b112304371
> Author: SeongJae Park <sj@kernel.org>
> 
> Docs/admin-guide/mm/damon/reclaim: update for entire memory monitoring
> 
> This commit updates the DAMON_RECLAIM usage document to reflect the new
> default monitoring target region selection, which now spans the system's
> entire physical memory instead of just the biggest System RAM region.
> 
> > diff --git a/Documentation/admin-guide/mm/damon/reclaim.rst b/Documentation/admin-guide/mm/damon/reclaim.rst
> > index 01a34c215b66..57ab8b187650 100644
> > --- a/Documentation/admin-guide/mm/damon/reclaim.rst
> > +++ b/Documentation/admin-guide/mm/damon/reclaim.rst
> > @@ -229,7 +229,8 @@ Start of target memory region in physical address.
> >  
> >  The start physical address of memory region that DAMON_RECLAIM will do work
> >  against.  That is, DAMON_RECLAIM will find cold memory regions in this region
> > -and reclaims.  By default, biggest System RAM is used as the region.
> > +and reclaims.  By default, the system's entire physical memory is used as the
> > +region.
> 
> Should the corresponding zh_CN and zh_TW translations be updated alongside
> this to keep them in sync? The translated documents currently still state
> that the biggest System RAM is used by default.

Updates of the translations are usually done by the contributors.  Hopefully
they will do, and I will help if needed.


Thanks,
SJ

[...]

[PATCH 7/7] Docs/admin-guide/mm/damon/lru_sort: update for entire memory monitoring

[SeongJae Park]

Update DAMON_LRU_SORT usage document for the changed default monitoring
target region selection.

Signed-off-by: SeongJae Park <sj@kernel.org>
---
 Documentation/admin-guide/mm/damon/lru_sort.rst | 6 ++++--
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/Documentation/admin-guide/mm/damon/lru_sort.rst b/Documentation/admin-guide/mm/damon/lru_sort.rst
index 25e2f042a383f..b93ca9b0853d2 100644
--- a/Documentation/admin-guide/mm/damon/lru_sort.rst
+++ b/Documentation/admin-guide/mm/damon/lru_sort.rst
@@ -246,7 +246,8 @@ monitor_region_start
 Start of target memory region in physical address.
 
 The start physical address of memory region that DAMON_LRU_SORT will do work
-against.  By default, biggest System RAM is used as the region.
+against.  By default, the system's entire physical memory is used as the
+region.
 
 monitor_region_end
 ------------------
@@ -254,7 +255,8 @@ monitor_region_end
 End of target memory region in physical address.
 
 The end physical address of memory region that DAMON_LRU_SORT will do work
-against.  By default, biggest System RAM is used as the region.
+against.  By default, the system's entire physical memory is used as the
+region.
 
 addr_unit
 ---------
-- 
2.47.3

Re: [PATCH 0/7] mm/damon/reclaim,lru_sort: monitor all system rams by default

[SeongJae Park]

On Tue, 28 Apr 2026 21:12:22 -0700 SeongJae Park <sj@kernel.org> wrote:

> DAMON_RECLAIM and DAMON_LRU_SORT set the biggest 'System RAM' resource
> of the system as the default monitoring target address range.  The main
> intention behind the design is to minimize the overhead coming from
> monitoring of non-System RAM areas.
> 
> This could result in an odd setup when there are multiple discrete
> System RAMs of considerable sizes.  For example, there are System RAMs
> each having 500 GiB size.  In this case, only the first 500 GiB will be
> set as the monitoring region by default.  This is particularly common on
> NUMA systems.  Hence the modules allow users to set the monitoring
> target address range using the module parameters if the default setup
> doesn't work for them.  In other words, the current design trades ease
> of setup for lower overhead.
> 
> However, because DAMON utilizes the sampling based access check and the
> adaptive regions adjustment mechanisms, the overhead from the monitoring
> of non-System RAM areas should be negligible in most setups.  Meanwhile,
> the setup complexity is causing real headaches for users who need to run
> those modules on various types of systems.  That is, the current
> tradeoff is not a good deal.
> 
> Set the physical address range that can cover all System RAM areas of
> the system as the default monitoring regions for DAMON_RECLAIM and
> DAMON_LRU_SORT.


FYI, Sashiko reviews and my review of the reviews are available on replies to
this thread that Cc-ing only me and damon@lists.linux.dev
(https://lore.kernel.org/20260429041232.90257-1-sj@kernel.org).  In short, no
real issue that blocks this series is found by Sashiko.


Thanks,
SJ

[...]