[RFC PATCH 0/2] mm/damon/stat: expose auto-tuned intervals and non-idle ages

[RFC PATCH 0/2] mm/damon/stat: expose auto-tuned intervals and non-idle ages

[SeongJae Park]

DAMON_STAT is intentionally providing limited information for easy
consumption.  From production fleet level usages, below limitations are
found, though.

The aggregation interval of DAMON_STAT represents the granularity of the
memory_idle_ms_percentiles.  But it is auto-tuned and not exposed to
users, so users cannot know the granularity.

All memory regions of non-zero (positive) nr_accesses are treated as
having zero idle time.  A significant portion of production systems have
such zero idle time.  Hence breakdown of warm and hot data is
impossible.

To overcome the limitations, expose the auto-tuned aggregation interval
with a new parameter named xxx and the age of non-zero nr_accesses
regions as negative idle time, via the existing idle time percentiles
parameter.

SeongJae Park (2):
  mm/damon/stat: expose the current tuned aggregation interval
  mm/damon/stat: expose negative idle time

 mm/damon/stat.c | 16 +++++++++++-----
 1 file changed, 11 insertions(+), 5 deletions(-)


base-commit: adc22cc8eb821b7d8274403ad7bdafb411fcc9d7
-- 
2.39.5

[RFC PATCH 1/2] mm/damon/stat: expose the current tuned aggregation interval

[SeongJae Park]

DAMON_STAT calculates the idle time for a region as the region's age
multiplied by the aggregation interval.  That is, the aggregation
interval is the granularity of the idle time.  Since the aggregation
interval is auto-tuned and not exposed to users, however, users cannot
easily know in what granularity the stat is made.  Expose the tuned
aggregation interval in microseconds via a new parameter,
aggr_interval_us.

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

diff --git a/mm/damon/stat.c b/mm/damon/stat.c
index 87bcd8866d4b..ff1c076185e6 100644
--- a/mm/damon/stat.c
+++ b/mm/damon/stat.c
@@ -39,6 +39,11 @@ module_param_array(memory_idle_ms_percentiles, ulong, NULL, 0400);
 MODULE_PARM_DESC(memory_idle_ms_percentiles,
 		"Memory idle time percentiles in milliseconds");
 
+static unsigned long aggr_interval_us;
+module_param(aggr_interval_us, ulong, 0400);
+MODULE_PARM_DESC(aggr_interval_us,
+		"Current tuned aggregation interval in microseconds");
+
 static struct damon_ctx *damon_stat_context;
 
 static void damon_stat_set_estimated_memory_bandwidth(struct damon_ctx *c)
@@ -133,6 +138,7 @@ static int damon_stat_damon_call_fn(void *data)
 		return 0;
 	last_refresh_jiffies = jiffies;
 
+	aggr_interval_us = c->attrs.aggr_interval;
 	damon_stat_set_estimated_memory_bandwidth(c);
 	damon_stat_set_idletime_percentiles(c);
 	return 0;
-- 
2.39.5

[RFC PATCH 2/2] mm/damon/stat: expose negative idle time

[SeongJae Park]

DAMON_STAT calculates the idle time of a region using the region's age
if the region's nr_accesses is zero.  If the nr_accesses value is
non-zero (positive), the idle time of the region becomes zero.

This means the users cannot know how warm and hot data is distributed,
using DAMON_STAT's memory_idle_ms_percentiles output.  The other stat,
namely estimated_memory_bandwidth, can help understanding how the
overall access temperature of the system is, but it is still very rough
information.  On production systems, actually, a significant portion of
the system memory is observed with zero idle time, and we cannot break
it down based on its internal hotness distribution.

Define the idle time of the region using its age, similar to those
having zero nr_accesses, but multiples '-1' to distinguish it.  And
expose that using the same parameter interface,
memory_idle_ms_percentiles.

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

diff --git a/mm/damon/stat.c b/mm/damon/stat.c
index ff1c076185e6..c33df0ade183 100644
--- a/mm/damon/stat.c
+++ b/mm/damon/stat.c
@@ -34,8 +34,8 @@ module_param(estimated_memory_bandwidth, ulong, 0400);
 MODULE_PARM_DESC(estimated_memory_bandwidth,
 		"Estimated memory bandwidth usage in bytes per second");
 
-static unsigned long memory_idle_ms_percentiles[101] __read_mostly = {0,};
-module_param_array(memory_idle_ms_percentiles, ulong, NULL, 0400);
+static long memory_idle_ms_percentiles[101] __read_mostly = {0,};
+module_param_array(memory_idle_ms_percentiles, long, NULL, 0400);
 MODULE_PARM_DESC(memory_idle_ms_percentiles,
 		"Memory idle time percentiles in milliseconds");
 
@@ -61,10 +61,10 @@ static void damon_stat_set_estimated_memory_bandwidth(struct damon_ctx *c)
 		MSEC_PER_SEC / c->attrs.aggr_interval;
 }
 
-static unsigned int damon_stat_idletime(const struct damon_region *r)
+static int damon_stat_idletime(const struct damon_region *r)
 {
 	if (r->nr_accesses)
-		return 0;
+		return -1 * (r->age + 1);
 	return r->age + 1;
 }
 
@@ -122,7 +122,7 @@ static void damon_stat_set_idletime_percentiles(struct damon_ctx *c)
 		while (next_percentile <= accounted_bytes * 100 / total_sz)
 			memory_idle_ms_percentiles[next_percentile++] =
 				damon_stat_idletime(region) *
-				c->attrs.aggr_interval / USEC_PER_MSEC;
+				(long)c->attrs.aggr_interval / USEC_PER_MSEC;
 	}
 	kfree(sorted_regions);
 }
-- 
2.39.5

Re: [RFC PATCH 0/2] mm/damon/stat: expose auto-tuned intervals and non-idle ages

[SeongJae Park]

On Tue,  9 Sep 2025 21:00:20 -0700 SeongJae Park <sj@kernel.org> wrote:

> DAMON_STAT is intentionally providing limited information for easy
> consumption.  From production fleet level usages, below limitations are
> found, though.
> 
> The aggregation interval of DAMON_STAT represents the granularity of the
> memory_idle_ms_percentiles.  But it is auto-tuned and not exposed to
> users, so users cannot know the granularity.
> 
> All memory regions of non-zero (positive) nr_accesses are treated as
> having zero idle time.  A significant portion of production systems have
> such zero idle time.  Hence breakdown of warm and hot data is
> impossible.
> 
> To overcome the limitations, expose the auto-tuned aggregation interval
> with a new parameter named xxx and the age of non-zero nr_accesses

s/xx/aggr_interval_us/

Forgot updating that before posting, sorry.  The next version should fix it.


Thanks,
SJ

[...]