Re: [PATCH v2] mm/damon/stat: monitor all System RAM resources

[SeongJae Park <sj@kernel.org>]

On Sun, 15 Mar 2026 09:27:15 -0700 SeongJae Park <sj@kernel.org> wrote:

> DAMON_STAT usage document (Documentation/admin-guide/mm/damon/stat.rst)
> says it monitors the system's entire physical memory.  But, it is
> monitoring only the biggest System RAM resource of the system.  When
> there are multiple System RAM resources, this results in monitoring only
> an unexpectedly small fraction of the physical memory.  For example,
> suppose the system has a 500 GiB System RAM, 10 MiB non-System RAM, and
> 500 GiB System RAM resources in order on the physical address space.
> DAMON_STAT will monitor only the first 500 GiB System RAM.  This
> situation is particularly common on NUMA systems.
> 
> Select a physical address range that covers all System RAM areas of the
> system, to fix this issue and make it work as documented.

sashiko.dev adds [1] below comment:

'''
Does this single bounding box incorrectly include unpopulated address gaps
between discrete System RAM resources?

On systems with non-contiguous physical memory, such as NUMA architectures,
there can be massive physical address gaps between memory nodes. By coalescing
all resources into a single addr_range and passing nr_ranges = 1 to
damon_set_regions(), DAMON treats these unpopulated gaps as part of the
monitored memory.

This appears to artificially inflate total_sz in
damon_stat_set_idletime_percentiles(), where the gap could completely
dominate the distribution and skew the percentiles to report that nearly
100% of memory is permanently idle.

Could this also wildly inflate estimated_memory_bandwidth in
damon_stat_set_estimated_memory_bandwidth() if an adaptive DAMON region
bridges valid RAM and a physical gap? The size (r->ar.end - r->ar.start)
would be massively inflated and multiplied by nr_accesses.

Would it be better to collect all discrete System RAM resources into an
array of struct damon_addr_range and pass them to damon_set_regions() using
the actual number of ranges?
'''

My answer is no.  It is an intended behavior and no negative impact is
expected.  I think the reason is in the patch description.  If any human needs
more clarifications about this, please let me know.

[1] https://sashiko.dev/#/patchset/20260315162717.80870-1-sj@kernel.org


Thanks,
SJ

[...]