mm/damon/reclaim,lru_sort: monitor all system rams by default

Sashiko AI review found 1 potential issue(s):
- [High] Creation of a single bounding box region for all System RAM severely degrades monitoring accuracy on sparse memory topologies by including non-RAM holes. --

commit 8f8f43643f81a1ce41ad12d7eb7416faa6e23114
Author: SeongJae Park <[email protected]>

mm/damon: introduce damon_set_region_system_rams_default()

This commit introduces a function to set the default target region to cover all System RAM resources instead of just the largest one. It finds the start of the first resource and the end of the last resource, and sets this bounding box as the target region.

Quoted 4 lines

mm/damon/core.c +0 -0

index 12544c60531d3..91e14caa4f6a1 100644

[ ... ]

Quoted 11 lines

mm/damon/core.c +11 -0

+static int damon_system_ram_walk_fn(struct resource *res, void *arg)
+{
+	struct damon_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;
+}

[ ... ]

Quoted 6 lines

mm/damon/core.c +6 -0

+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;
+

mm/damon/core.c static unsigned long damon_res_to_core_addr(resource_size_t ra, · line 3266

Quoted 10 lines

mm/damon/core.c +10 -0

+	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);

Could this create a single bounding box region that includes large non-RAM holes on systems with sparse memory layouts?

Since damon_system_ram_walk_fn() only records the minimum start address and maximum end address across all System RAM resources, creating a single contiguous damon_addr_range from this bounding box includes any intervening address gaps.

On multi-socket NUMA systems or devices with large MMIO holes, this could result in massive address ranges not backed by actual RAM. Because DAMON uniformly samples random addresses within each region, sampling might predominantly hit these unbacked memory holes.

Would this dilute the access sampling and cause actively used memory to be incorrectly classified as cold? Should the code gather discrete System RAM ranges into an array of struct damon_addr_range and pass them to damon_set_regions() with nr_ranges > 1 to exclude holes?

Signature · 2 lines

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/[email protected]?part=1

Sashiko AI review found 3 potential issue(s):
- [High] Unbounded iteration over physical memory holes causes severe scheduling latency and soft lockups.
- [High] Inclusion of physical holes permanently exhausts DAMOS quotas and starves actual memory reclaim.
- [High] Bounding box over sparse memory dilutes sampling accuracy and traps RAM in cold regions.

--

commit 1ebe17b8690373c96bc931bcacccad9cbc735e44
Author: SeongJae Park <[email protected]>

mm/damon/reclaim: cover all system rams

This commit changes the default DAMON_RECLAIM monitoring region from the biggest System RAM resource to a single bounding box that spans all System RAM resources on the system.

Quoted 4 lines

mm/damon/reclaim.c +0 -0

index 86da147786583..2a2343d751f3e 100644

[ ... ]

mm/damon/reclaim.c static int damon_reclaim_apply_parameters(void) · line 249

Quoted 12 lines

mm/damon/reclaim.c +3 -5

@@ -242,11 +244,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);

When using a single bounding box that covers all System RAM, does this introduce large physical address holes (like PCIe MMIO gaps) into the monitored region? On sparse NUMA topologies, these holes can be terabytes in size.

If operations like DAMOS_PAGEOUT iterate linearly over the region page-by-page, will they process these massive holes? For physical holes, damon_get_folio() will return NULL, and the loop might continue without yielding:

damon_pa_pageout() {
    ...
    while (addr < end) {
        ...
        folio = damon_get_folio(PHYS_PFN(addr));
        if (!folio) {
            addr += PAGE_SIZE;
            continue;
        }
        ...
    }
}

Since cond_resched() is often placed outside or after such loops, could this continuous iteration over unbacked holes trigger soft lockups and severe scheduling latency?

How does the inclusion of massive physical holes interact with DAMOS quotas?

In damos_apply_scheme(), the scheme's charged size is incremented by the evaluated region size (quota->charged_sz += sz). If regions span terabytes of unbacked holes, evaluating them will quickly exhaust the quota (e.g., 128 MiB/sec for DAMON_RECLAIM) without reclaiming any actual pages.

Could this starve actual memory reclaim and inflate the sz_tried statistics?

Does the bounding box approach also affect sampling accuracy?

DAMON samples a random address within a region using damon_rand(r->ar.start, r->ar.end). If the region is mostly composed of physical holes, the sample will frequently land in unbacked space and return zero accesses.

Since the region will continuously appear cold, could damon_merge_two_regions() merge it with adjacent valid RAM regions? This might trap valid RAM inside massive cold regions, diluting the sampling probability for actual memory.

Signature · 2 lines

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/[email protected]?part=2

Sashiko AI review found 3 potential issue(s):
- [High] Monitoring the bounding box of all System RAM resources encompasses massive physical address holes, fundamentally breaking DAMON's sampling-based access check on sparse memory systems.
- [High] Applying schemes to the newly-enlarged bounding box can cause a soft lockup panic due to unbounded page iteration without yielding.
- [Low] Misspelled 'phyiscal' in module parameter documentation.

--

commit 11d2e4765abf8999777a27c53c055f1c43ca53bf
Author: SeongJae Park <[email protected]>

mm/damon/lru_sort: cover all system rams

This commit updates DAMON_LRU_SORT to cover all system RAM instead of just the biggest System RAM resource. The default monitor region start and end parameter descriptions and initializations are modified to reflect the entire physical memory space.

mm/damon/lru_sort.c DEFINE_DAMON_MODULES_MON_ATTRS_PARAMS(damon_lru_sort_mon_attrs); · line 143

Quoted 10 lines

mm/damon/lru_sort.c +1 -1

index 554559d729760..7f8c26890ffb2 100644
@@ -140,7 +140,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 phyiscal memory is used as the

This isn't a bug, but there is a typo (phyiscal) here.

mm/damon/lru_sort.c module_param(monitor_region_start, ulong, 0600); · line 153

Quoted 11 lines

mm/damon/lru_sort.c +2 -1

+ * region.
  */
 static unsigned long monitor_region_start __read_mostly;
 module_param(monitor_region_start, ulong, 0600);

@@ -149,7 +150,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 phyiscal memory is used as the

There is another typo (phyiscal) here as well.

Quoted 5 lines

mm/damon/lru_sort.c +1 -0

+ * region.
  */
 static unsigned long monitor_region_end __read_mostly;
 module_param(monitor_region_end, ulong, 0600);

[ ... ]

mm/damon/lru_sort.c static int damon_lru_sort_apply_parameters(void) · line 344

Quoted 9 lines

mm/damon/lru_sort.c +1 -1

@@ -336,7 +338,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,

Will monitoring the bounding box of all System RAM resources encompass massive physical address holes on sparse memory systems?

Because DAMON estimates access frequency by sampling uniformly at random from the region:

r->sampling_addr = damon_rand(r->ar.start, r->ar.end);

If the bounding box spans across terabytes of address gaps between NUMA nodes, would the overwhelming majority of samples hit unpopulated holes?

Since sampling a hole returns no folio, does this artificially dilute the apparent access frequency of valid hot RAM within the region and misidentify it as cold?

Can this also cause soft lockups during scheme application?

When applying a scheme, the region is iterated page-by-page. For unpopulated gaps, the folio check is skipped and the address is incremented:

while (addr < damon_pa_phys_addr(r->ar.end, addr_unit)) {
    folio = damon_get_folio(PHYS_PFN(addr));
    if (damon_pa_invalid_damos_folio(folio, s)) {
        addr += PAGE_SIZE;
        continue;
    }
    ...

Since there is no cond_resched() inside this tight loop, and because valid folios are not found (meaning quota variables don't increment to abort early), could iterating over terabytes of unpopulated gaps trigger the soft lockup watchdog on PREEMPT_NONE or PREEMPT_VOLUNTARY kernels?

Signature · 2 lines

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/[email protected]?part=3

Sashiko AI review found 1 potential issue(s):
- [Low] Typo in documentation update for monitor_region_start: 'phyiscal' instead of 'physical'.