[RFC PATCH] mm/damon/reclaim: add 'available' memory as an optional watermarks metric

[RFC PATCH] mm/damon/reclaim: add 'available' memory as an optional watermarks metric

[Liew Rui Yan]

Problem
=======

Currently, DAMON's watermarks metric is calculated based on the
proportion of the system's free memory.

However, on devices like Android, the system typically maintains a very
low amount of free memory, even when the available memory is abundant.
This causes DAMON_RECLAIM to prematurely or aggressive trigger memory
reclamation, thereby increasing the risk of page refaults.

Solution
========

Introduce a new sysfs parameter 'memrate_type' to DAMON_RECLAIM. Users
can switch DAMON's watermark metric evaluation to be based on available
memory by writing 'available' to this parameter and commit the change.

Signed-off-by: Liew Rui Yan <aethernet65535@gmail.com>
---
 include/linux/damon.h    |  9 ++++---
 mm/damon/core.c          |  6 +++++
 mm/damon/reclaim.c       | 56 ++++++++++++++++++++++++++++++++++++++++
 mm/damon/sysfs-schemes.c |  4 +++
 4 files changed, 72 insertions(+), 3 deletions(-)

diff --git a/include/linux/damon.h b/include/linux/damon.h
index 6f7edb3590ef..0006e3a25317 100644
--- a/include/linux/damon.h
+++ b/include/linux/damon.h
@@ -314,13 +314,16 @@ struct damos_quota {
 /**
  * enum damos_wmark_metric - Represents the watermark metric.
  *
- * @DAMOS_WMARK_NONE:		Ignore the watermarks of the given scheme.
- * @DAMOS_WMARK_FREE_MEM_RATE:	Free memory rate of the system in [0,1000].
- * @NR_DAMOS_WMARK_METRICS:	Total number of DAMOS watermark metrics
+ * @DAMOS_WMARK_NONE:		    Ignore the watermarks of the given scheme.
+ * @DAMOS_WMARK_FREE_MEM_RATE:	    Free memory rate of the system in [0,1000].
+ * @DAMOS_WMARK_AVAILABLE_MEM_RATE: Available memory rate of the system in
+ *				    [0,1000].
+ * @NR_DAMOS_WMARK_METRICS:	    Total number of DAMOS watermark metrics
  */
 enum damos_wmark_metric {
 	DAMOS_WMARK_NONE,
 	DAMOS_WMARK_FREE_MEM_RATE,
+	DAMOS_WMARK_AVAILABLE_MEM_RATE,
 	NR_DAMOS_WMARK_METRICS,
 };
 
diff --git a/mm/damon/core.c b/mm/damon/core.c
index 7e4b9affc5b0..f12d06081d70 100644
--- a/mm/damon/core.c
+++ b/mm/damon/core.c
@@ -3300,11 +3300,17 @@ static bool kdamond_need_stop(struct damon_ctx *ctx)
 static int damos_get_wmark_metric_value(enum damos_wmark_metric metric,
 					unsigned long *metric_value)
 {
+	long available_pages;
+
 	switch (metric) {
 	case DAMOS_WMARK_FREE_MEM_RATE:
 		*metric_value = global_zone_page_state(NR_FREE_PAGES) * 1000 /
 		       totalram_pages();
 		return 0;
+	case DAMOS_WMARK_AVAILABLE_MEM_RATE:
+		available_pages = si_mem_available();
+		*metric_value = available_pages * 1000 / totalram_pages();
+		return 0;
 	default:
 		break;
 	}
diff --git a/mm/damon/reclaim.c b/mm/damon/reclaim.c
index ce4499cf4b8b..229bc68bb1ad 100644
--- a/mm/damon/reclaim.c
+++ b/mm/damon/reclaim.c
@@ -159,6 +159,17 @@ static unsigned long addr_unit __read_mostly = 1;
 static bool skip_anon __read_mostly;
 module_param(skip_anon, bool, 0600);
 
+/*
+ * Watermarks metric options.
+ *
+ * If this parameter is set as ``free``, DAMON_RECLAIM calculates the watermark
+ * metric based on the system's free memory rate. If set as ``available``, it
+ * calculates the metric based on the system's available memory rate.
+ *
+ * Default is ``free``.
+ */
+static enum damos_wmark_metric memrate_type = DAMOS_WMARK_FREE_MEM_RATE;
+
 static struct damos_stat damon_reclaim_stat;
 DEFINE_DAMON_MODULES_DAMOS_STATS_PARAMS(damon_reclaim_stat,
 		reclaim_tried_regions, reclaimed_regions, quota_exceeds);
@@ -220,6 +231,8 @@ static int damon_reclaim_apply_parameters(void)
 		goto out;
 	}
 
+	damon_reclaim_wmarks.metric = memrate_type;
+
 	attrs = damon_reclaim_mon_attrs;
 	if (autotune_monitoring_intervals) {
 		attrs.sample_interval = 5000;
@@ -376,6 +389,49 @@ module_param_cb(addr_unit, &addr_unit_param_ops, &addr_unit, 0600);
 MODULE_PARM_DESC(addr_unit,
 	"Scale factor for DAMON_RECLAIM to ops address conversion (default: 1)");
 
+static int damon_reclaim_memrate_type_store(const char *val,
+					    const struct kernel_param *kp)
+{
+	if (sysfs_streq(val, "free"))
+		memrate_type = DAMOS_WMARK_FREE_MEM_RATE;
+	else if (sysfs_streq(val, "available"))
+		memrate_type = DAMOS_WMARK_AVAILABLE_MEM_RATE;
+	else
+		return -EINVAL;
+
+	return 0;
+}
+
+static int damon_reclaim_memrate_type_load(char *buffer,
+					   const struct kernel_param *kp)
+{
+	int type = READ_ONCE(memrate_type);
+	int len = 0;
+
+	if (type == DAMOS_WMARK_FREE_MEM_RATE)
+		len += sysfs_emit_at(buffer, len, "[free] ");
+	else
+		len += sysfs_emit_at(buffer, len, "free ");
+
+	if (type == DAMOS_WMARK_AVAILABLE_MEM_RATE)
+		len += sysfs_emit_at(buffer, len, "[available] ");
+	else
+		len += sysfs_emit_at(buffer, len, "available ");
+
+	len += sysfs_emit_at(buffer, len, "\n");
+
+	return len;
+}
+
+static const struct kernel_param_ops memrate_type_param_ops = {
+	.set = damon_reclaim_memrate_type_store,
+	.get = damon_reclaim_memrate_type_load,
+};
+module_param_cb(memrate_type, &memrate_type_param_ops, &memrate_type, 0600);
+MODULE_PARM_DESC(memrate_type,
+		 "Memory rate type for watermarks metric "
+		 "(free or available, default: free)");
+
 static bool damon_reclaim_enabled(void)
 {
 	if (!ctx)
diff --git a/mm/damon/sysfs-schemes.c b/mm/damon/sysfs-schemes.c
index 329cfd0bbe9f..5d6636433bd6 100644
--- a/mm/damon/sysfs-schemes.c
+++ b/mm/damon/sysfs-schemes.c
@@ -1056,6 +1056,10 @@ damos_sysfs_wmark_metric_names[] = {
 		.metric = DAMOS_WMARK_FREE_MEM_RATE,
 		.name = "free_mem_rate",
 	},
+	{
+		.metric = DAMOS_WMARK_AVAILABLE_MEM_RATE,
+		.name = "available_mem_rate",
+	},
 };
 
 static ssize_t metric_show(struct kobject *kobj, struct kobj_attribute *attr,
-- 
2.54.0

Re: [RFC PATCH] mm/damon/reclaim: add 'available' memory as an optional watermarks metric

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Low] Integer overflow in `DAMOS_WMARK_AVAILABLE_MEM_RATE` metric calculation on 32-bit systems with large RAM.
--

commit 6e3a23f197986b131330f066a94d4821743b7d21
Author: Liew Rui Yan <aethernet65535@gmail.com>

mm/damon/reclaim: add 'available' memory as an optional watermarks metric

This commit introduces a new 'memrate_type' sysfs parameter to DAMON_RECLAIM.
It allows users to switch the watermark metric evaluation from free memory to
available memory, which is particularly useful on devices like Android that
maintain low free memory.

> diff --git a/mm/damon/core.c b/mm/damon/core.c
> index 7e4b9affc5b06..f12d06081d70f 100644
> --- a/mm/damon/core.c
> +++ b/mm/damon/core.c

[ ... ]

> @@ -3300,11 +3300,17 @@ static bool kdamond_need_stop(struct damon_ctx *ctx)
>  static int damos_get_wmark_metric_value(enum damos_wmark_metric metric,
>  					unsigned long *metric_value)
>  {
> +	long available_pages;
> +
>  	switch (metric) {
>  	case DAMOS_WMARK_FREE_MEM_RATE:
>  		*metric_value = global_zone_page_state(NR_FREE_PAGES) * 1000 /
>  		       totalram_pages();
>  		return 0;
> +	case DAMOS_WMARK_AVAILABLE_MEM_RATE:
> +		available_pages = si_mem_available();
> +		*metric_value = available_pages * 1000 / totalram_pages();

[Severity: Low]
Can this calculation overflow on 32-bit systems with a large amount of memory?

Since available_pages is a long type, on 32-bit architectures it is a 32-bit
integer. If the system's available memory exceeds roughly 17.1 GB (about
4,294,967 pages), multiplying available_pages by 1000 before the division would
overflow the maximum 32-bit value.

This truncation could result in an artificially low watermark metric rate.

Would it be safer to cast available_pages to a 64-bit type or use mult_frac() 
to prevent the potential overflow, even if such large memory sizes are uncommon
on 32-bit targets?

> +		return 0;
>  	default:
>  		break;
>  	}

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260626081038.46569-1-aethernet65535@gmail.com?part=1

Re: [RFC PATCH] mm/damon/reclaim: add 'available' memory as an optional watermarks metric

[SeongJae Park]

Hi Liew,


Thank you for this patch!

On Fri, 26 Jun 2026 16:10:38 +0800 Liew Rui Yan <aethernet65535@gmail.com> wrote:

> Problem
> =======
> 
> Currently, DAMON's watermarks metric is calculated based on the
> proportion of the system's free memory.
> 
> However, on devices like Android, the system typically maintains a very
> low amount of free memory, even when the available memory is abundant.
> This causes DAMON_RECLAIM to prematurely or aggressive trigger memory
> reclamation, thereby increasing the risk of page refaults.
> 
> Solution
> ========
> 
> Introduce a new sysfs parameter 'memrate_type' to DAMON_RECLAIM. Users
> can switch DAMON's watermark metric evaluation to be based on available
> memory by writing 'available' to this parameter and commit the change.

How about using DAMOS quota with its aim-based auto-tuning, instead?

I developed DAMOS watermarks and quota as safe guards of DAMOS.  In more
detail, DAMOS quota is for restricting only resource usage of DAMOS.
Meanwhile, watermarks is for restricting resource usage of both DAMON and
DAMOS.  That is, when the watermarks condition is met, not only DAMOS but also
DAMON is completely paused.  Also, watermarks feature was considered smarter
than quota, because it is a kind of auto-tuning.

However, it turned out completely turning DAMON off is not a very good idea,
because it drops monitoring results when the watermarks condition is met and
therefore completely stops DAMON and DAMOS.  It drops the region shapes and
'age' information.  Especially, 'age' of some regions commonly cumulated up to
hours or even days.  Dropping that was a problem in production use cases.

Meanwhile, we introduced aim-oriented DAMOS quota auto-tuning (a.k.a DAMOS
quota goal).  It made DAMOS quota smarter and easier to extend than watermarks.
Nowadays, users can also pause and resume [1] DAMON/DAMOS without losing the
monitoring information when they want.

So, I personally don't encourage people to use watermarks.  Of course, I may
missing some problems in alternatives.  Hence I'm asking the question to you.

How about using DAMOS quota with its aim-based auto-tuning, instead?  If you
cannot, could you share more details?

I'll hold reviewing the code until this high level discussion is resolved.

[1] https://lore.kernel.org/20260427151231.113429-1-sj@kernel.org


Thanks,
SJ

[...]