[PATCH 0/2] mm/damon/reclaim: support monitoring intervals auto-tuning

[PATCH 0/2] mm/damon/reclaim: support monitoring intervals auto-tuning

[SeongJae Park]

The monitoring intervals auto-tuning feature of DAMON has proven to be
useful in multiple environments.  Add a new DAMON_RECLAIM parameter for
supporting the feature, and update the document for the new parameter.

Changes from RFC
- rfc link: https://lore.kernel.org/20260414052855.90123-1-sj@kernel.org
- Add notes about behavioral changes that introduced by the auto-tuning.

SeongJae Park (2):
  mm/damon/reclaim: add autotune_monitoring_intervals parameter
  Docs/admin-guide/mm/damon/reclaim: update for
    autotune_monitoring_intervals

 .../admin-guide/mm/damon/reclaim.rst          | 11 +++++++
 mm/damon/reclaim.c                            | 33 ++++++++++++++++---
 2 files changed, 39 insertions(+), 5 deletions(-)


base-commit: 061bdca57aa1fc22d0f74a7c7bd35c7576194484
-- 
2.47.3

[PATCH 1/2] mm/damon/reclaim: add autotune_monitoring_intervals parameter

[SeongJae Park]

DAMON's monitoring intervals auto-tuning feature has proven to be useful
in multiple environments.  DAMON_RECLAIM is still asking users to do the
manual tuning of the intervals.  Add a module parameter for utilizing
the auto-tuning feature with the suggested default setup.

Note that use of the auto-tuning overrides the manually entered
monitoring intervals.  Also, note that the 'min_age' will dynamically
changed proportional to auto-tuned intervals.  It is recommended to use
'min_age' short enough and use 'quota_mem_pressure_us' like coldness
threshold auto-tuning features together.

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

diff --git a/mm/damon/reclaim.c b/mm/damon/reclaim.c
index a60ee800d63e9..7126d47fb8b2f 100644
--- a/mm/damon/reclaim.c
+++ b/mm/damon/reclaim.c
@@ -91,6 +91,20 @@ module_param(quota_mem_pressure_us, ulong, 0600);
 static unsigned long quota_autotune_feedback __read_mostly;
 module_param(quota_autotune_feedback, ulong, 0600);
 
+/*
+ * Auto-tune monitoring intervals.
+ *
+ * If this parameter is set as ``Y``, DAMON_RECLAIM automatically tunes DAMON's
+ * sampling and aggregation intervals.  The auto-tuning aims to capture
+ * meaningful amount of access events in each DAMON-snapshot, while keeping the
+ * sampling intervals 5 milliseconds in minimum, and 10 seconds in maximum.
+ * Setting this as ``N`` disables the auto-tuning.
+ *
+ * Disabled by default.
+ */
+static bool autotune_monitoring_intervals __read_mostly;
+module_param(autotune_monitoring_intervals, bool, 0600);
+
 static struct damos_watermarks damon_reclaim_wmarks = {
 	.metric = DAMOS_WMARK_FREE_MEM_RATE,
 	.interval = 5000000,	/* 5 seconds */
@@ -152,7 +166,7 @@ DEFINE_DAMON_MODULES_DAMOS_STATS_PARAMS(damon_reclaim_stat,
 static struct damon_ctx *ctx;
 static struct damon_target *target;
 
-static struct damos *damon_reclaim_new_scheme(void)
+static struct damos *damon_reclaim_new_scheme(unsigned long aggr_interval)
 {
 	struct damos_access_pattern pattern = {
 		/* Find regions having PAGE_SIZE or larger size */
@@ -162,8 +176,7 @@ static struct damos *damon_reclaim_new_scheme(void)
 		.min_nr_accesses = 0,
 		.max_nr_accesses = 0,
 		/* for min_age or more micro-seconds */
-		.min_age_region = min_age /
-			damon_reclaim_mon_attrs.aggr_interval,
+		.min_age_region = min_age / aggr_interval,
 		.max_age_region = UINT_MAX,
 	};
 
@@ -184,6 +197,7 @@ static int damon_reclaim_apply_parameters(void)
 {
 	struct damon_ctx *param_ctx;
 	struct damon_target *param_target;
+	struct damon_attrs attrs;
 	struct damos *scheme;
 	struct damos_quota_goal *goal;
 	struct damos_filter *filter;
@@ -201,12 +215,21 @@ static int damon_reclaim_apply_parameters(void)
 		goto out;
 	}
 
-	err = damon_set_attrs(param_ctx, &damon_reclaim_mon_attrs);
+	attrs = damon_reclaim_mon_attrs;
+	if (autotune_monitoring_intervals) {
+		attrs.sample_interval = 5000;
+		attrs.aggr_interval = 100000;
+		attrs.intervals_goal.access_bp = 40;
+		attrs.intervals_goal.aggrs = 3;
+		attrs.intervals_goal.min_sample_us = 5000;
+		attrs.intervals_goal.max_sample_us = 10 * 1000 * 1000;
+	}
+	err = damon_set_attrs(param_ctx, &attrs);
 	if (err)
 		goto out;
 
 	err = -ENOMEM;
-	scheme = damon_reclaim_new_scheme();
+	scheme = damon_reclaim_new_scheme(attrs.aggr_interval);
 	if (!scheme)
 		goto out;
 	damon_set_schemes(param_ctx, &scheme, 1);
-- 
2.47.3

[PATCH 2/2] Docs/admin-guide/mm/damon/reclaim: update for autotune_monitoring_intervals

[SeongJae Park]

Update DAMON_RECLAIM usage document for the newly added monitoring
intervals auto-tuning enablement parameter.

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

diff --git a/Documentation/admin-guide/mm/damon/reclaim.rst b/Documentation/admin-guide/mm/damon/reclaim.rst
index 57ab8b1876506..ec7e3e32b4ac6 100644
--- a/Documentation/admin-guide/mm/damon/reclaim.rst
+++ b/Documentation/admin-guide/mm/damon/reclaim.rst
@@ -85,6 +85,17 @@ identifies the region as cold, and reclaims it.
 
 120 seconds by default.
 
+autotune_monitoring_intervals
+-----------------------------
+
+If this parameter is set as ``Y``, DAMON_RECLAIM automatically tunes DAMON's
+sampling and aggregation intervals.  The auto-tuning aims to capture meaningful
+amount of access events in each DAMON-snapshot, while keeping the sampling
+interval 5 milliseconds in minimum, and 10 seconds in maximum.  Setting this as
+``N`` disables the auto-tuning.
+
+Disabled by default.
+
 quota_ms
 --------
 
-- 
2.47.3

Re: [PATCH 1/2] mm/damon/reclaim: add autotune_monitoring_intervals parameter

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] Validation check on `damon_reclaim_mon_attrs.aggr_interval` prematurely rejects configurations when autotuning is enabled, and exposes a TOCTOU divide-by-zero panic.
--

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

mm/damon/reclaim: add autotune_monitoring_intervals parameter

This commit adds a module parameter for utilizing DAMON's auto-tuning
feature with suggested default setups. When enabled, this feature
overrides manually entered monitoring intervals to capture a meaningful
amount of access events per snapshot.

> diff --git a/mm/damon/reclaim.c b/mm/damon/reclaim.c
> index a60ee800d63e9..7126d47fb8b2f 100644
> --- a/mm/damon/reclaim.c
> +++ b/mm/damon/reclaim.c

[ ... ]

> @@ -201,12 +215,21 @@ static int damon_reclaim_apply_parameters(void)
>  		goto out;
>  	}
>  
> -	err = damon_set_attrs(param_ctx, &damon_reclaim_mon_attrs);
> +	attrs = damon_reclaim_mon_attrs;
> +	if (autotune_monitoring_intervals) {
> +		attrs.sample_interval = 5000;
> +		attrs.aggr_interval = 100000;
> +		attrs.intervals_goal.access_bp = 40;
> +		attrs.intervals_goal.aggrs = 3;
> +		attrs.intervals_goal.min_sample_us = 5000;
> +		attrs.intervals_goal.max_sample_us = 10 * 1000 * 1000;
> +	}

In the existing code just above this diff, there is a validation check:

    if (!damon_reclaim_mon_attrs.aggr_interval) {
        err = -EINVAL;
        goto out;
    }

If autotune_monitoring_intervals is enabled, could this check prematurely
reject the configuration if damon_reclaim_mon_attrs.aggr_interval is 0?
The auto-tuning override happens right below the check.

Additionally, because this check evaluates the global module parameter
directly instead of a local copy, could a concurrent sysfs write cause a
divide-by-zero panic? 

If a user sets the global interval to 0 right after this check passes:

    if (!damon_reclaim_mon_attrs.aggr_interval) {
        // passes
    }
    
    // concurrent sysfs write sets damon_reclaim_mon_attrs.aggr_interval = 0
    
    attrs = damon_reclaim_mon_attrs;

If autotune_monitoring_intervals is false, attrs.aggr_interval becomes 0
and is passed to damon_reclaim_new_scheme(), which performs:

    .min_age_region = min_age / aggr_interval,

Would moving this check to evaluate the local attrs.aggr_interval after
the auto-tuning block prevent both of these scenarios?

> +	err = damon_set_attrs(param_ctx, &attrs);
>  	if (err)
>  		goto out;
>  
>  	err = -ENOMEM;
> -	scheme = damon_reclaim_new_scheme();
> +	scheme = damon_reclaim_new_scheme(attrs.aggr_interval);
>  	if (!scheme)
>  		goto out;
>  	damon_set_schemes(param_ctx, &scheme, 1);

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

Re: [PATCH 1/2] mm/damon/reclaim: add autotune_monitoring_intervals parameter

[SeongJae Park]

On Fri, 01 May 2026 01:30:43 +0000 sashiko-bot@kernel.org wrote:

> Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
> - [High] Validation check on `damon_reclaim_mon_attrs.aggr_interval` prematurely rejects configurations when autotuning is enabled, and exposes a TOCTOU divide-by-zero panic.

No blocker for this patch is found.  Plese read below for more details.

> --
> 
> commit 34f815f9177f234892c1b9608e13d2fc0957697e
> Author: SeongJae Park <sj@kernel.org>
> 
> mm/damon/reclaim: add autotune_monitoring_intervals parameter
> 
> This commit adds a module parameter for utilizing DAMON's auto-tuning
> feature with suggested default setups. When enabled, this feature
> overrides manually entered monitoring intervals to capture a meaningful
> amount of access events per snapshot.
> 
> > diff --git a/mm/damon/reclaim.c b/mm/damon/reclaim.c
> > index a60ee800d63e9..7126d47fb8b2f 100644
> > --- a/mm/damon/reclaim.c
> > +++ b/mm/damon/reclaim.c
> 
> [ ... ]
> 
> > @@ -201,12 +215,21 @@ static int damon_reclaim_apply_parameters(void)
> >  		goto out;
> >  	}
> >  
> > -	err = damon_set_attrs(param_ctx, &damon_reclaim_mon_attrs);
> > +	attrs = damon_reclaim_mon_attrs;
> > +	if (autotune_monitoring_intervals) {
> > +		attrs.sample_interval = 5000;
> > +		attrs.aggr_interval = 100000;
> > +		attrs.intervals_goal.access_bp = 40;
> > +		attrs.intervals_goal.aggrs = 3;
> > +		attrs.intervals_goal.min_sample_us = 5000;
> > +		attrs.intervals_goal.max_sample_us = 10 * 1000 * 1000;
> > +	}
> 
> In the existing code just above this diff, there is a validation check:
> 
>     if (!damon_reclaim_mon_attrs.aggr_interval) {
>         err = -EINVAL;
>         goto out;
>     }
> 
> If autotune_monitoring_intervals is enabled, could this check prematurely
> reject the configuration if damon_reclaim_mon_attrs.aggr_interval is 0?
> The auto-tuning override happens right below the check.

Yes, and this is a behavior that consistent to that of DAMON_LRU_SORT.  I
didn't really intentionally designed this behavior but I find no problem at
this.  Zero aggregation interval is invalid.  Just keeping it as invalid even
if autotune is enabled sounds natural to me.

> 
> Additionally, because this check evaluates the global module parameter
> directly instead of a local copy, could a concurrent sysfs write cause a
> divide-by-zero panic? 
> 
> If a user sets the global interval to 0 right after this check passes:
> 
>     if (!damon_reclaim_mon_attrs.aggr_interval) {
>         // passes
>     }
>     
>     // concurrent sysfs write sets damon_reclaim_mon_attrs.aggr_interval = 0
>     
>     attrs = damon_reclaim_mon_attrs;
> 
> If autotune_monitoring_intervals is false, attrs.aggr_interval becomes 0
> and is passed to damon_reclaim_new_scheme(), which performs:
> 
>     .min_age_region = min_age / aggr_interval,
> 
> Would moving this check to evaluate the local attrs.aggr_interval after
> the auto-tuning block prevent both of these scenarios?

No.

First of all, this patch is doing nothing for the code.

And damon_reclaim_apply_parameters() does not race against itself, since it
works synchronous to the parameters update, and the parameter updates are
protected by kernel_param_lock.


Thanks,
SJ

[...]