[RFC PATCH v4 0/4] mm/damon: Introduce a huge page collapsing mechanism using auto tuning

[RFC PATCH v4 0/4] mm/damon: Introduce a huge page collapsing mechanism using auto tuning

[gutierrez.asier]

From: Asier Gutierrez <gutierrez.asier@huawei-partners.com>

Overview
========

This patch set introduces a new autotuning which allows to collapse
hot regions into hugepages.

Motivation
==========

Since TLB is a bottleneck for many systems[1], a way to optimize TLB
misses (or hits) is to use huge pages. Unfortunately, using "always"
in THP leads to memory fragmentation and memory waste. For this reason,
most application guides and system administrators suggest to disable THP.

Currently DAMON has DAMOS_HUGEPAGE, DAMOS_NONHUGEPAGE and DAMOS_COLLAPSE.
However, there is no way to tune the settings. It will collapse all the
hot regions that meet the access pattern. If the server is a bare metal
database or big data server, this will also lead to eventual fragmentation.

Additionally, currently THP is set globally. Ideally, there should be a
way to control which tasks can use huge pages.

Solution
========

DAMON has now a way to autotune some of the variables and adjust quotas
automatically, so that DAMON is fired only under the right circumstances.
It would be nice to have something similar, but for huge pages.

A new autotuning quota goal[2], damos_hugepage_mem_bp, is introduced,
which checks the huge page consumption to total memory consumption. This
new quota mechanism reuses current autotuning architecture.

A new module is introduced to demonstrate the use of huge pages
collapse autotuning. The goal is to collapse hot regions of a given
process into huge pages. The module launches a kdamond thread for a
certain task provided by the user through monitored_pid module argument.
Hugepage goal autotuning will automatically adjust the aggressiveness
of hot region collapses.

This module also has a user autotuning knob which allows the user to
adjust the aggressiveness of page collapsing.

Benchmarks
==========

Huge page collapse autotuning was tested in a physicial machine with
MariaDB 10.5.29 and sysbench as the benchmark framework.

The hugepage module was set up in the following way:

# echo 1000 > min_age
# echo 1000 > quota_percentage_hugepage
# echo $(pidof mariadbd) > monitored_pid
# echo on > enabled

The goal was to achieve 5% of the total memory used as hugepage.
Since the database was not very big, we may not be able to achieve
high amount of huge pages per total memory consumption ratio.

The table below shows the memory consumption over time. Gaps in the
timestamp means that no changes in the hugepage consumption happened
over that period of time in MB.

+-----------+----------------+----------------+----------------------+
| timestamp | total mem used | huge page used | percentage hugepage  |
+-----------+----------------+----------------+----------------------+
| 0         | 3044.988281    | 0              | 0%                   |
| 22        | 3160.207031    | 2              | 0.06%                |
| 30        | 3250.90625     | 4              | 0.12%                |
| 69        | 3781.238281    | 6              | 0.16%                |
| 71        | 3822.226563    | 8              | 0.21%                |
| 72        | 3846.578125    | 10             | 0.26%                |
| 73        | 3852.402344    | 12             | 0.31%                |
| 74        | 3868           | 14             | 0.36%                |
| 75        | 3881.84375     | 104            | 2.68%                |
| 275       | 4194.175781    | 106            | 2.52%                |
+-----------+----------------+----------------+----------------------+

After second 275, no more pages are collapsed into hugepages

Performance:
Baseline -> 18,124.1 transactions per second
Hugepage autotune -> 18,163.64 transactions per second

TODO
====
- Support page splitting for cold hugepages.

Patches Sequence
================
Patch 1 -> Introduce DAMOS_QUOTA_HUGEPAGE_MEM_BP and autotuning
Patch 2 -> Module that demonstrates how to use
           DAMOS_QUOTA_HUGEPAGE_MEM_BP and DAMOS_QUOTA_GOAL_TUNER_TEMPORAL
Patch 3 -> Support for DAMOS_QUOTA_HUGEPAGE_MEM_BP in sysfs-schemes
Patch 4 -> Documentation

Changes from previous versions
==============================
RFC 3[3] -> RFC 4
  - Simplified the module
  - Removed unnecessary parameters
  - Renamed DAMOS_QUOTA_HUGEPAGE_MEM_BP to unify the
    naming style
  - Switched to DAMOS_QUOTA_GOAL_TUNER_TEMPORAL
  - Updated the documentation
  - Removed new interface for context creation with
    DAMON_OPS_VADDR

RFC 2[4] -> RFC 3
  - Module moved to samples
  - Change autotune to monitor total memory and hugepage
  - Added performnace benchmarks to the cover letter
  - Bail out gracefully when trying to start disable
    the module after the monitored task exited. This
    issue was discovered by sashiko [5]
  - Fixed typos and added quota_sz to the documentation
    discovered by sashiko [6]
RFC 1[7] -> RFC 2
  - Rebased into mm-new
  - Use DAMOS_COLLAPSE instead of DAMOS_HUGEPAGE
  - Fixed an issue that returned silently an error when the PID
    didn't exist in the system.[8]

[1] https://dl.acm.org/doi/pdf/10.1145/3307650.3322227
[2] https://lore.kernel.org/e67f05ad-dbb9-45e6-ba30-b167a99ac67d@huawei-partners.com
[3] https://lore.kernel.org/20260604150338.501128-1-gutierrez.asier@huawei-partners.com
[4] https://lore.kernel.org/20260522145518.158910-1-gutierrez.asier@huawei-partners.com
[5] https://lore.kernel.org/20260522171210.900B11F00A3D@smtp.kernel.org
[6] https://lore.kernel.org/20260522171633.AAF5B1F000E9@smtp.kernel.org
[7] https://lore.kernel.org/20260430134139.2446417-1-gutierrez.asier@huawei-partners.com
[8] https://lore.kernel.org/all/20260430154338.E22E6C2BCB3@smtp.kernel.org/

Asier Gutierrez (4):
  mm/damon: Introduce DAMOS_QUOTA_HUGEPAGE auto tuning
  mm/damon: introduce DAMON_HUGEPAGE for hot region hugepage collapsing
  mm/damon/sysfs: support hugepage_mem_bp quota goal metric
  Documentation/admin-guide/mm/damon: add DAMON-based Hugepage Management

 .../admin-guide/mm/damon/hugepage.rst (new)   | 113 ++++++++++
 Documentation/admin-guide/mm/damon/index.rst  |   1 +
 include/linux/damon.h                         |   2 +
 mm/damon/core.c                               |  14 ++
 samples/damon/Kconfig                         |  12 +
 samples/damon/Makefile                        |   1 +
 samples/damon/hugepage.c (new)                | 207 ++++++++++++++++++
 7 files changed, 350 insertions(+)
 create mode 100644 Documentation/admin-guide/mm/damon/hugepage.rst
 create mode 100644 samples/damon/hugepage.c

-- 
2.43.0

[RFC PATCH v4 1/4] mm/damon: Introduce DAMOS_QUOTA_HUGEPAGE auto tuning

[gutierrez.asier]

From: Asier Gutierrez <gutierrez.asier@huawei-partners.com>

Introduce DAMOS_QUOTA_HUGEPAGE auto tuning Add a new DAMOS
quota goal metric to measure the amount of huge page
consumption to total memory consumption ratio.

Signed-off-by: Asier Gutierrez <gutierrez.asier@huawei-partners.com>
---
 include/linux/damon.h |  2 ++
 mm/damon/core.c       | 14 ++++++++++++++
 2 files changed, 16 insertions(+)

diff --git a/include/linux/damon.h b/include/linux/damon.h
index 6f7edb3590ef..23a9cec05033 100644
--- a/include/linux/damon.h
+++ b/include/linux/damon.h
@@ -162,6 +162,7 @@ enum damos_action {
  * @DAMOS_QUOTA_INACTIVE_MEM_BP:	Inactive to total LRU memory ratio.
  * @DAMOS_QUOTA_NODE_ELIGIBLE_MEM_BP:	Scheme-eligible memory ratio of a
  *					node in basis points (0-10000).
+ * @DAMOS_QUOTA_HUGEPAGE_MEM_BP:	Huge page to total used memory ratio.
  * @NR_DAMOS_QUOTA_GOAL_METRICS:	Number of DAMOS quota goal metrics.
  *
  * Metrics equal to larger than @NR_DAMOS_QUOTA_GOAL_METRICS are unsupported.
@@ -176,6 +177,7 @@ enum damos_quota_goal_metric {
 	DAMOS_QUOTA_ACTIVE_MEM_BP,
 	DAMOS_QUOTA_INACTIVE_MEM_BP,
 	DAMOS_QUOTA_NODE_ELIGIBLE_MEM_BP,
+	DAMOS_QUOTA_HUGEPAGE_MEM_BP,
 	NR_DAMOS_QUOTA_GOAL_METRICS,
 };
 
diff --git a/mm/damon/core.c b/mm/damon/core.c
index 7e4b9affc5b0..b001f80681b1 100644
--- a/mm/damon/core.c
+++ b/mm/damon/core.c
@@ -2795,6 +2795,17 @@ static unsigned int damos_get_in_active_mem_bp(bool active_ratio)
 	return mult_frac(inactive, 10000, total);
 }
 
+static unsigned int damos_hugepage_mem_bp(void)
+{
+	unsigned long thp, total;
+
+	thp = global_node_page_state(NR_ANON_THPS) +
+				global_node_page_state(NR_SHMEM_THPS) +
+				global_node_page_state(NR_FILE_THPS);
+	total = totalram_pages() - global_zone_page_state(NR_FREE_PAGES);
+	return mult_frac(thp, 10000, total);
+}
+
 static void damos_set_quota_goal_current_value(struct damon_ctx *c,
 		struct damos *s, struct damos_quota_goal *goal)
 {
@@ -2826,6 +2837,9 @@ static void damos_set_quota_goal_current_value(struct damon_ctx *c,
 		goal->current_value = damos_get_node_eligible_mem_bp(c, s,
 				goal->nid);
 		break;
+	case DAMOS_QUOTA_HUGEPAGE_MEM_BP:
+		goal->current_value = damos_hugepage_mem_bp();
+		break;
 	default:
 		break;
 	}
-- 
2.43.0

[RFC PATCH v4 2/4] mm/damon: introduce DAMON_HUGEPAGE for hot region hugepage collapsing

[gutierrez.asier]

From: Asier Gutierrez <gutierrez.asier@huawei-partners.com>

This patch introduces a new DAMON module (SAMPLE_DAMON_HUGEPAGE)
which collapses hot regions into huge pages.

SAMPLE_DAMON_HUGEPAGE operates in the virtual memory space, for a
specific task. The user is expected to supply the PID of the task
that is going to be monitored through the monitored_pid module
variable.

SAMPLE_DAMON_HUGEPAGE uses the hugepage auto-tune mechanism to
increase or decrease the aggressiveness of page collapsing. User
autotuning is also available for additional tuning aggressiveness
control.

The module also includes changes to the DAMON compilation, so that
the module can be enabled or disabled.

Signed-off-by: Asier Gutierrez <gutierrez.asier@huawei-partners.com>
---
 samples/damon/Kconfig          |  12 ++
 samples/damon/Makefile         |   1 +
 samples/damon/hugepage.c (new) | 207 +++++++++++++++++++++++++++++++++
 3 files changed, 220 insertions(+)

diff --git a/samples/damon/Kconfig b/samples/damon/Kconfig
index cbf96fd8a8bf..512f150aaabb 100644
--- a/samples/damon/Kconfig
+++ b/samples/damon/Kconfig
@@ -40,4 +40,16 @@ config SAMPLE_DAMON_MTIER
 
 	  If unsure, say N.
 
+config SAMPLE_DAMON_HUGEPAGE
+	bool "Build DAMON-based collapse of hot regions (SAMPLE_DAMON_HUGEPAGE)"
+	depends on DAMON && DAMON_VADDR
+	help
+	  This module monitors a certain PID provided by the user through
+	  monitored_pid attribute. Hot regions are determined by DAMON-based
+	  sampling. Collapsing occurs according to the quota goal using total
+	  memory usage to huge page usage ratio. The ratio is set by the user
+	  through a module attribute.
+
+	  If unsure, say N.
+
 endmenu
diff --git a/samples/damon/Makefile b/samples/damon/Makefile
index 72f68cbf422a..96bde2c44846 100644
--- a/samples/damon/Makefile
+++ b/samples/damon/Makefile
@@ -3,3 +3,4 @@
 obj-$(CONFIG_SAMPLE_DAMON_WSSE) += wsse.o
 obj-$(CONFIG_SAMPLE_DAMON_PRCL) += prcl.o
 obj-$(CONFIG_SAMPLE_DAMON_MTIER) += mtier.o
+obj-$(CONFIG_SAMPLE_DAMON_HUGEPAGE)	+= hugepage.o
diff --git a/samples/damon/hugepage.c b/samples/damon/hugepage.c
new file mode 100644
index 000000000000..2c7fd213a8db
--- /dev/null
+++ b/samples/damon/hugepage.c
@@ -0,0 +1,207 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (C) 2026 HUAWEI, Inc.
+ *             https://www.huawei.com
+ *
+ * Author: Asier Gutierrez <gutierrez.asier@huawei-partners.com>
+ */
+
+#define pr_fmt(fmt) "damon_sample_hugepage: " fmt
+
+#include <linux/damon.h>
+#include <linux/kstrtox.h>
+#include <linux/module.h>
+
+#ifdef MODULE_PARAM_PREFIX
+#undef MODULE_PARAM_PREFIX
+#endif
+#define MODULE_PARAM_PREFIX "damon_sample_hugepage."
+
+static bool enabled __read_mostly;
+
+static unsigned long target_pid;
+module_param(target_pid, ulong, 0600);
+
+/* By default, total huge pages to system memory usage ratio set to 10% */
+static unsigned long quota_percentage_hugepage __read_mostly = 1000;
+module_param(quota_percentage_hugepage, ulong, 0600);
+
+static unsigned long quota_autotune_feedback __read_mostly;
+module_param(quota_autotune_feedback, ulong, 0600);
+
+static struct damon_ctx *ctx;
+static struct pid *target_pidp;
+
+static int damon_sample_hugepage_damon_call_fn(void *data)
+{
+	struct damon_ctx *c = data;
+	struct damon_target *t;
+
+	damon_for_each_target(t, c) {
+		struct damon_region *r;
+		unsigned long hugepages = 0;
+
+		damon_for_each_region(r, t) {
+			if (r->nr_accesses > 0)
+				hugepages += r->ar.end - r->ar.start;
+		}
+		hugepages = hugepages / HPAGE_PMD_SIZE;
+		pr_info("hugepage: %lu\n", hugepages);
+	}
+	return 0;
+}
+
+static struct damon_call_control call_control = {
+	.fn = damon_sample_hugepage_damon_call_fn,
+	.repeat = true,
+};
+
+static int damon_sample_hugepage_start(void)
+{
+	int err;
+	struct damon_target *target;
+	struct damos *scheme;
+	struct damos_quota_goal *goal;
+
+	pr_info("start\n");
+
+
+	ctx = damon_new_ctx();
+	if (!ctx)
+		return -ENOMEM;
+	if (damon_select_ops(ctx, DAMON_OPS_VADDR)) {
+		damon_destroy_ctx(ctx);
+		return -EINVAL;
+	}
+
+	target = damon_new_target();
+	if (!target) {
+		damon_destroy_ctx(ctx);
+		return -ENOMEM;
+	}
+	damon_add_target(ctx, target);
+	target_pidp = find_get_pid(target_pid);
+	if (!target_pidp) {
+		damon_destroy_ctx(ctx);
+		return -EINVAL;
+	}
+	target->pid = target_pidp;
+
+	scheme = damon_new_scheme(&(struct damos_access_pattern) {
+				.min_sz_region = HPAGE_PMD_SIZE,
+				.max_sz_region = ULONG_MAX,
+				.min_nr_accesses = 0,
+				.max_nr_accesses = UINT_MAX,
+				.min_age_region = 50,
+				.max_age_region = UINT_MAX},
+				DAMOS_COLLAPSE, 0,
+				&(struct damos_quota) {
+				.ms = 10,
+				.sz = 128 * 1024 * 1024,
+				.reset_interval = 1000,
+				.weight_sz = 0,
+				.weight_nr_accesses = 1,
+				.weight_age = 1,
+				.goal_tuner = DAMOS_QUOTA_GOAL_TUNER_TEMPORAL},
+				&(struct damos_watermarks){}, NUMA_NO_NODE);
+	if (!scheme) {
+		damon_destroy_ctx(ctx);
+		return -ENOMEM;
+	}
+	damon_set_schemes(ctx, &scheme, 1);
+	goal = damos_new_quota_goal(DAMOS_QUOTA_HUGEPAGE_MEM_BP,
+				quota_percentage_hugepage);
+	if (!goal) {
+		damon_destroy_ctx(ctx);
+		return -ENOMEM;
+	}
+	damos_add_quota_goal(&scheme->quota, goal);
+
+	if (quota_autotune_feedback) {
+		goal = damos_new_quota_goal(DAMOS_QUOTA_USER_INPUT, 10000);
+		if (!goal) {
+			damon_destroy_ctx(ctx);
+			return -ENOMEM;
+		}
+		goal->current_value = quota_autotune_feedback;
+		damos_add_quota_goal(&scheme->quota, goal);
+	}
+
+	err = damon_start(&ctx, 1, true);
+	if (err) {
+		damon_destroy_ctx(ctx);
+		return err;
+	}
+
+	call_control.data = ctx;
+	err = damon_call(ctx, &call_control);
+	if (err) {
+		damon_stop(&ctx, 1);
+		damon_destroy_ctx(ctx);
+	}
+	return err;
+}
+
+static void damon_sample_hugepage_stop(void)
+{
+	pr_info("stop\n");
+	if (ctx) {
+		damon_stop(&ctx, 1);
+		damon_destroy_ctx(ctx);
+	}
+}
+static int damon_sample_hugepage_enabled_store(const char *val,
+				const struct kernel_param *kp)
+{
+	bool is_enabled = enabled;
+	int err;
+
+	err = kstrtobool(val, &enabled);
+	if (err)
+		return err;
+
+	if (enabled == is_enabled)
+		return 0;
+
+	if (!damon_initialized())
+		return 0;
+
+	if (enabled) {
+		err = damon_sample_hugepage_start();
+		if (err)
+			enabled = false;
+		return err;
+	}
+	damon_sample_hugepage_stop();
+	return 0;
+}
+
+static const struct kernel_param_ops enabled_param_ops = {
+	.set = damon_sample_hugepage_enabled_store,
+	.get = param_get_bool,
+};
+
+module_param_cb(enabled, &enabled_param_ops, &enabled, 0600);
+MODULE_PARM_DESC(enabled,
+	"Enable or disable DAMON_HUGEPAGE (default: disabled)");
+
+static int __init damon_sample_hugepage_init(void)
+{
+	int err = 0;
+
+	if (!damon_initialized()) {
+		if (enabled)
+			enabled = false;
+		pr_warn("Module not initialized\n");
+		return -ENOMEM;
+	}
+
+	if (enabled) {
+		err = damon_sample_hugepage_start();
+		if (err)
+			enabled = false;
+	}
+	return err;
+}
+
+module_init(damon_sample_hugepage_init);
-- 
2.43.0

[RFC PATCH v4 3/4] mm/damon/sysfs: support hugepage_mem_bp quota goal metric

[gutierrez.asier]

From: Asier Gutierrez <gutierrez.asier@huawei-partners.com>

Add the "hugepage_mem_bp" to the sysfs-schemes interface.  Also handle
DAMOS_QUOTA_HUGEPAGE_MEM_BP when constructing quota goals.

Signed-off-by: Asier Gutierrez <gutierrez.asier@huawei-partners.com>
---
 mm/damon/sysfs-schemes.c | 7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/mm/damon/sysfs-schemes.c b/mm/damon/sysfs-schemes.c
index 329cfd0bbe9f..dc46ec128083 100644
--- a/mm/damon/sysfs-schemes.c
+++ b/mm/damon/sysfs-schemes.c
@@ -1267,6 +1267,10 @@ struct damos_sysfs_qgoal_metric_name damos_sysfs_qgoal_metric_names[] = {
 		.metric = DAMOS_QUOTA_NODE_ELIGIBLE_MEM_BP,
 		.name = "node_eligible_mem_bp",
 	},
+	{
+		.metric = DAMOS_QUOTA_HUGEPAGE_MEM_BP,
+		.name = "hugepage_mem_bp",
+	},
 };
 
 static ssize_t target_metric_show(struct kobject *kobj,
@@ -2877,6 +2881,9 @@ static int damos_sysfs_add_quota_score(
 		case DAMOS_QUOTA_NODE_ELIGIBLE_MEM_BP:
 			goal->nid = sysfs_goal->nid;
 			break;
+		case DAMOS_QUOTA_HUGEPAGE_MEM_BP:
+			goal->current_value = sysfs_goal->current_value;
+			break;
 		default:
 			break;
 		}
-- 
2.43.0

[RFC PATCH v4 4/4] Documentation/admin-guide/mm/damon: add DAMON-based Hugepage Management

[gutierrez.asier]

From: Asier Gutierrez <gutierrez.asier@huawei-partners.com>

Add documentation for the DAMON-based Hugepage Management
(SAMPLE_DAMON_HUGEPAGE) feature, which automatically manages
huge pages by identifying hot memory regions and collapsing
them back to regular pages. The documentation covers the
module's features, operation, and all available module
parameters.

Signed-off-by: Asier Gutierrez <gutierrez.asier@huawei-partners.com>
---
 .../admin-guide/mm/damon/hugepage.rst (new)   | 113 ++++++++++++++++++
 Documentation/admin-guide/mm/damon/index.rst  |   1 +
 2 files changed, 114 insertions(+)

diff --git a/Documentation/admin-guide/mm/damon/hugepage.rst b/Documentation/admin-guide/mm/damon/hugepage.rst
new file mode 100644
index 000000000000..470ae2bc8cc3
--- /dev/null
+++ b/Documentation/admin-guide/mm/damon/hugepage.rst
@@ -0,0 +1,113 @@
+================================
+DAMON-based huge page collapsing
+================================
+
+DAMON-based huge page collapsing (SAMPLE_DAMON_HUGEPAGE) is a static kernel
+module that aims to collapse hot regions into huge pages.
+
+Where Proactive huge page collapsing is Required?
+=================================================
+
+The amount of available memory grows faster than the amount of TLB entries.
+This leads to higher amount of TLB misses and excessive cycle wastes. Huge
+pages are meant to solve this problem. However, huge pages usually lead to
+memory fragmentation and memory waste.
+
+Collapsing selectively hot regions in a specific process can avoid big
+memory fragmentation, while increasing TLB performance.
+
+SAMPLE_DAMON_HUGEPAGE solves this by:
+
+- Identifying hot regions that have been accessed for a configured time
+- Automatically collapsing the regions into huge pages back
+- Auto tune the huge page usage ratio to meet desired targets
+- Controlling the collapse rate with configurable quotas to avoid performance
+  degradation
+
+
+How It Works?
+=============
+
+SAMPLE_DAMON_HUGEPAGE uses kdamond to identify anonymous memory regions that
+are:
+
+1. Large enough to be backed by huge pages (``HPAGE_PMD_SIZE`` or larger)
+2. Have been accessed for a configured time period
+
+Once identified, SAMPLE_DAMON_HUGEPAGE triggers synchronous partial collapse
+of those regions. The collapse operation is controlled by quotas to limit the
+impact on system performance.
+
+The module also supports automatic tuning of the collapse rate to achieve a
+desired huge page usage ratio. Administrators can configure a target percentage
+of huge page usage vs total anonymous memory usage.
+
+Additionally, the module accepts manual feedback from system administrators to
+adjust the effective quota level based on observed system behavior.
+
+Interface: Module Parameters
+============================
+
+To use this feature, you should first ensure your system is running on a kernel
+that is built with ``CONFIG_DAMON_HUGEPAGE=y``.
+
+To let sysadmins enable or disable it and tune for the given system,
+SAMPLE_DAMON_HUGEPAGE utilizes module parameters.  That is, you can put
+``damon_sample_hugepage.<parameter>=<value>`` on the kernel boot command line or
+write proper values to ``/sys/module/damon_sample_hugepage/parameters/<parameter>``
+files.
+
+Below are the description of each parameter.
+
+enabled
+-------
+
+Enable or disable SAMPLE_DAMON_HUGEPAGE.
+
+You can enable SAMPLE_DAMON_HUGEPAGE by setting the value of this parameter as ``Y``.
+Setting it as ``N`` disables SAMPLE_DAMON_HUGEPAGE.  Note that SAMPLE_DAMON_HUGEPAGE
+could do no real monitoring and collapse due to the activation condition.
+
+quota_autotune_feedback
+-----------------------
+
+User-specifiable feedback for auto-tuning of the effective quota.
+
+While keeping the caps that set by other quotas, SAMPLE_DAMON_HUGEPAGE
+automatically increases and decreases the effective level of the quota
+aiming receiving this feedback of value ``10,000`` from the user.
+SAMPLE_DAMON_HUGEPAGE assumes the feedback value and the quota are positively
+proportional.  Value zero means disabling this auto-tuning feature.
+
+Disabled by default.
+
+quota_percentage_hugepage
+-------------------------
+
+Huge page consumption to total memory anonymous memory consumption ratio goal
+in bp ``(10,000)``. SAMPLE_DAMON_HUGEPAGE automatically increases and
+decreases page collapse aggressiveness in order to achieve the given value.
+
+target_pid
+----------
+
+PID of the task that is going to be monitored for hot regions.
+
+
+Example
+=======
+
+Below runtime example commands make SAMPLE_DAMON_HUGEPAGE to find memory
+regions of  the task with PID 1234 that have been accessed in the last 100
+milliseconds or more and collpases those pages into huge pages. The page
+collapsing is limited to be done only up to 1 GiB per second to avoid
+SAMPLE_DAMON_HUGEPAGE consuming too much CPU time for the collapse operation. ::
+
+    # cd /sys/module/damon_sample_hugepage/parameters
+    # echo 1234 > target_pid
+    # echo Y > enabled
+
+Note that this module (SAMPLE_DAMON_HUGEPAGE) cannot run simultaneously
+with other DAMON-based special-purpose modules.  Refer to
+:ref:`DAMON design special purpose modules exclusivity
+<damon_design_special_purpose_modules_exclusivity>` for more details.
\ No newline at end of file
diff --git a/Documentation/admin-guide/mm/damon/index.rst b/Documentation/admin-guide/mm/damon/index.rst
index 3ce3164480c7..6f2cad21a2da 100644
--- a/Documentation/admin-guide/mm/damon/index.rst
+++ b/Documentation/admin-guide/mm/damon/index.rst
@@ -15,3 +15,4 @@ access monitoring and access-aware system operations.
    reclaim
    lru_sort
    stat
+   hugepage
-- 
2.43.0

Re: [RFC PATCH v4 4/4] Documentation/admin-guide/mm/damon: add DAMON-based Hugepage Management

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 6 potential issue(s) to consider:
- [Medium] The commit message incorrectly states that the module collapses hot memory regions 'back to regular pages'.
- [Medium] The documentation incorrectly claims the page collapsing limit is up to 1 GiB per second, whereas the code restricts it to 128 MiB per second.
- [Medium] The documentation incorrectly describes the huge page quota percentage metric as a ratio against anonymous memory.
- [Medium] The documentation claims administrators can provide dynamic manual feedback to adjust the quota, but the module lacks runtime update capabilities.
- [Low] Missing newline at the end of the newly added documentation file.
- [Low] Multiple typographical and grammatical errors in the documentation.
--

commit 9d20df125ff887031458f9f9da39b696dcac8419
Author: Asier Gutierrez <gutierrez.asier@huawei-partners.com>

Documentation/admin-guide/mm/damon: add DAMON-based Hugepage Management

This patch adds documentation for the DAMON-based Hugepage Management
feature. It covers the module's features, operation, and all available
module parameters.

> Add documentation for the DAMON-based Hugepage Management
> (SAMPLE_DAMON_HUGEPAGE) feature, which automatically manages
> huge pages by identifying hot memory regions and collapsing
> them back to regular pages.

[Severity: Medium]
Does this module actually collapse huge pages into regular pages?

The documentation below correctly notes that the module collapses regular
pages into huge pages. Could the commit message be updated to reflect the
actual operation?

> diff --git a/Documentation/admin-guide/mm/damon/hugepage.rst b/Documentation/admin-guide/mm/damon/hugepage.rst
> new file mode 100644
> index 0000000000000..470ae2bc8cc31
> --- /dev/null
> +++ b/Documentation/admin-guide/mm/damon/hugepage.rst

[ ... ]

> +quota_autotune_feedback
> +-----------------------
> +
> +User-specifiable feedback for auto-tuning of the effective quota.
> +
> +While keeping the caps that set by other quotas, SAMPLE_DAMON_HUGEPAGE
                     ^^^^^^^^^^^^^^^^^^

[Severity: Low]
This isn't a bug, but there is a typo here. Should this be "caps set by"?

> +automatically increases and decreases the effective level of the quota
> +aiming receiving this feedback of value 10,000 from the user.
   ^^^^^^^^^^^^^^^^

[Severity: Low]
This isn't a bug, but there is a typo here. Should this be "aiming to receive"?

[Severity: Medium]
Does the module actually accept runtime feedback for the quota?

Unlike other DAMON modules like reclaim, this module does not seem to have a
commit_inputs mechanism to apply runtime updates to the DAMON context. 

Since quota_autotune_feedback is only read once during
damon_sample_hugepage_start(), is this dynamic feedback mechanism supported
by the code?

> +SAMPLE_DAMON_HUGEPAGE assumes the feedback value and the quota are positively
> +proportional.  Value zero means disabling this auto-tuning feature.
> +
> +Disabled by default.
> +
> +quota_percentage_hugepage
> +-------------------------
> +
> +Huge page consumption to total memory anonymous memory consumption ratio goal
> +in bp (10,000). SAMPLE_DAMON_HUGEPAGE automatically increases and

[Severity: Medium]
Is this ratio actually based on anonymous memory consumption?

Looking at damos_hugepage_mem_bp(), it calculates the ratio against the total
system used memory:
totalram_pages() - global_zone_page_state(NR_FREE_PAGES)

Could this be updated to reflect it does not just use anonymous memory?

[ ... ]

> +Example
> +=======
> +
> +Below runtime example commands make SAMPLE_DAMON_HUGEPAGE to find memory
> +regions of  the task with PID 1234 that have been accessed in the last 100
              ^^

[Severity: Low]
This isn't a bug, but there is an extra space here.

> +milliseconds or more and collpases those pages into huge pages. The page
                            ^^^^^^^^^

[Severity: Low]
This isn't a bug, but there is a typo here. Should this be "collapses"?

> +collapsing is limited to be done only up to 1 GiB per second to avoid

[Severity: Medium]
Is the limit actually 1 GiB per second?

The underlying module statically sets the quota limit (damos_quota.sz) to
128 * 1024 * 1024 (128 MiB) with a reset_interval of 1000 ms.

> +SAMPLE_DAMON_HUGEPAGE consuming too much CPU time for the collapse operation. ::
> +
> +    # cd /sys/module/damon_sample_hugepage/parameters
> +    # echo 1234 > target_pid
> +    # echo Y > enabled
> +
> +Note that this module (SAMPLE_DAMON_HUGEPAGE) cannot run simultaneously
> +with other DAMON-based special-purpose modules.  Refer to
> +:ref:`DAMON design special purpose modules exclusivity
> +<damon_design_special_purpose_modules_exclusivity>` for more details.
> \ No newline at end of file

[Severity: Low]
This isn't a bug, but standard POSIX text file and Linux kernel coding
guidelines require a trailing newline at the end of the file.

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260611150244.3454699-1-gutierrez.asier@huawei-partners.com?part=4

Re: [RFC PATCH v4 1/4] mm/damon: Introduce DAMOS_QUOTA_HUGEPAGE auto tuning

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 4 potential issue(s) to consider:

New issues:
- [High] Incomplete Metric Implementation (mTHP & PTE-mapped THP omitted)
- [High] 32-bit Integer Overflow in Hugepage Metric

Pre-existing issues:
- [High] Pre-existing 32-bit Integer Overflows in DAMON metrics
- [High] Pre-existing Division by Zero in damos_get_in_active_mem_bp
--

commit 7873411ecddc79aa5afd0d6d56dfa25345f98454
Author: Asier Gutierrez <gutierrez.asier@huawei-partners.com>

mm/damon: Introduce DAMOS_QUOTA_HUGEPAGE auto tuning

This commit introduces a new DAMOS quota goal metric to measure the amount
of huge page consumption to total memory consumption ratio. It adds the
DAMOS_QUOTA_HUGEPAGE_MEM_BP metric and its corresponding calculation logic
for scheme auto-tuning.

> diff --git a/mm/damon/core.c b/mm/damon/core.c
> index 7e4b9affc5b06..b001f80681b12 100644
> --- a/mm/damon/core.c
> +++ b/mm/damon/core.c
> @@ -2795,6 +2795,17 @@ static unsigned int damos_get_in_active_mem_bp(bool active_ratio)
>  	return mult_frac(inactive, 10000, total);
>  }

[Severity: High]
This isn't a bug introduced by this patch, but does the use of mult_frac()
in damos_get_in_active_mem_bp() risk a division by zero?

If a system has no active or inactive pages (which is structurally possible
if user processes are non-existent, completely swapped out, or if all pages
are mlocked into the UNEVICTABLE LRU), the total evaluates to 0:

mm/damon/core.c:damos_get_in_active_mem_bp() {
    ...
    total = active + inactive;
    if (active_ratio)
        return mult_frac(active, 10000, total);
    ...
}

Since mult_frac() divides by the denominator, could this trigger a
division-by-zero kernel panic?

[Severity: High]
This is a pre-existing issue, but can the mult_frac() calculation overflow
on 32-bit architectures?

In both damos_get_in_active_mem_bp() and damos_get_node_mem_bp(), the metrics
evaluate macros like:

    mult_frac(active, 10000, total);
    mult_frac(i.totalram - i.freeram, 10000, i.totalram);

The mult_frac() macro performs an intermediate multiplication of
(x % d) * 10000.

On 32-bit architectures with more than ~1.76 GB of memory, can this
intermediate multiplication exceed UINT_MAX and silently wrap around,
corrupting the memory ratios?

>  
> +static unsigned int damos_hugepage_mem_bp(void)
> +{
> +	unsigned long thp, total;
> +
> +	thp = global_node_page_state(NR_ANON_THPS) +
> +				global_node_page_state(NR_SHMEM_THPS) +
> +				global_node_page_state(NR_FILE_THPS);

[Severity: High]
Are multi-size THPs (mTHPs) and PTE-mapped THPs omitted from this calculation?

The NR_ANON_THPS counter strictly tracks the number of base pages in
PMD-mapped anonymous THPs. It appears to ignore THPs that are mapped via
PTEs (e.g., due to VMA boundary crossing).

Furthermore, modern setups heavily rely on multi-size THPs (such as 64KB
or 128KB), which are tracked separately via per-order mthp_stats.

Will ignoring these lead to an incorrectly reported near-zero huge page
consumption on modern mTHP setups, breaking the auto-tuning behavior?

> +	total = totalram_pages() - global_zone_page_state(NR_FREE_PAGES);
> +	return mult_frac(thp, 10000, total);

[Severity: High]
Will this new metric also be impacted by the 32-bit integer overflow issue
mentioned above?

On 32-bit architectures, thp and total are 32-bit unsigned longs.

The intermediate multiplication in the mult_frac() macro evaluates to
(thp % total) * 10000.

If the system has more than UINT_MAX / 10000 memory pages (about 429,496
pages, or ~1.76 GB of RAM), could this intermediate result exceed UINT_MAX
and silently wrap around, leading to an incorrectly low hugepage ratio?

> +}
> +
[ ... ]

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260611150244.3454699-1-gutierrez.asier@huawei-partners.com?part=1

Re: [RFC PATCH v4 2/4] mm/damon: introduce DAMON_HUGEPAGE for hot region hugepage collapsing

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 3 potential issue(s) to consider:

New issues:
- [Medium] Mismatch between commit message documentation and actual module parameter name for the target PID.
- [Low] Missing Kconfig dependency causes build failure on architectures/configs without huge page leaf support.

Pre-existing issues:
- [High] Potential divide-by-zero kernel panic in `damos_hugepage_mem_bp` when total memory evaluates to zero.
--

commit 4d499570cf03bd13f013e3c89938e2739ead1edf
Author: Asier Gutierrez <gutierrez.asier@huawei-partners.com>

mm/damon: introduce DAMON_HUGEPAGE for hot region hugepage collapsing

This patch introduces the SAMPLE_DAMON_HUGEPAGE module to monitor a task
and collapse hot memory regions into huge pages. It adds the necessary
Kconfig, Makefile, and sample code implementation.

>     SAMPLE_DAMON_HUGEPAGE operates in the virtual memory space, for a
>     specific task. The user is expected to supply the PID of the task
>     that is going to be monitored through the monitored_pid module
>     variable.

[Severity: Medium]
Is this module variable name accurate? The commit message documents that users
should supply the PID via the monitored_pid module variable, but the Kconfig
and C code below actually define and register it as target_pid.

> diff --git a/samples/damon/Kconfig b/samples/damon/Kconfig
> index cbf96fd8a8bf9..512f150aaabba 100644
> --- a/samples/damon/Kconfig
> +++ b/samples/damon/Kconfig
> @@ -40,4 +40,16 @@ config SAMPLE_DAMON_MTIER
>  
>  	  If unsure, say N.
>  
> +config SAMPLE_DAMON_HUGEPAGE
> +	bool "Build DAMON-based collapse of hot regions (SAMPLE_DAMON_HUGEPAGE)"
> +	depends on DAMON && DAMON_VADDR

[Severity: Low]
Does this require an explicit dependency on TRANSPARENT_HUGEPAGE or
PGTABLE_HAS_HUGE_LEAVES?

If huge page leaves are not supported on the target architecture,
HPAGE_PMD_SHIFT evaluates to a BUILD_BUG() expression. Because
SAMPLE_DAMON_HUGEPAGE evaluates this unconditionally below, configuring a
kernel without huge page support will result in an immediate compile-time
failure.

> +	help
> +	  This module monitors a certain PID provided by the user through
> +	  monitored_pid attribute. Hot regions are determined by DAMON-based

[ ... ]

> diff --git a/samples/damon/hugepage.c b/samples/damon/hugepage.c
> new file mode 100644
> index 0000000000000..2c7fd213a8db1
> --- /dev/null
> +++ b/samples/damon/hugepage.c
> @@ -0,0 +1,207 @@
> +// SPDX-License-Identifier: GPL-2.0

[ ... ]

> +static int damon_sample_hugepage_start(void)
> +{
> +	int err;
> +	struct damon_target *target;
> +	struct damos *scheme;
> +	struct damos_quota_goal *goal;

[ ... ]

> +	scheme = damon_new_scheme(&(struct damos_access_pattern) {
> +				.min_sz_region = HPAGE_PMD_SIZE,

[Severity: Low]
This is where HPAGE_PMD_SIZE is evaluated unconditionally, which will trigger
the BUILD_BUG() if the Kconfig dependencies are not updated.

[Severity: High]
This isn't a bug introduced by this patch, but can this feature trigger a
divide-by-zero kernel panic?

This problem was introduced by a preceding patch in the same series
('mm/damon: Introduce DAMOS_QUOTA_HUGEPAGE auto tuning'), and it appears to
remain unfixed at the end of the series.

Looking at damos_hugepage_mem_bp() in mm/damon/core.c:

mm/damon/core.c:damos_hugepage_mem_bp() {
    ...
    total = totalram_pages() - global_zone_page_state(NR_FREE_PAGES);
    return mult_frac(thp, 10000, total);
}

Due to the nature of per-CPU counter caches,
global_zone_page_state(NR_FREE_PAGES) can drift. In extreme edge cases,
such as when nearly all managed pages are free, the free pages count can
equal or temporarily exceed totalram_pages(), causing total to evaluate to 0.

Would passing total == 0 to mult_frac() trigger a division-by-zero
exception?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260611150244.3454699-1-gutierrez.asier@huawei-partners.com?part=2

Re: [RFC PATCH v4 3/4] mm/damon/sysfs: support hugepage_mem_bp quota goal metric

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 4 potential issue(s) to consider:
- [High] Missing zero check for total memory before calling `mult_frac()` can cause a division by zero kernel panic.
- [Medium] Calculation of hugepage basis points in `damos_hugepage_mem_bp()` can overflow on 32-bit architectures.
- [Low] The metric `DAMOS_QUOTA_HUGEPAGE_MEM_BP` erroneously copies its `current_value` from sysfs, resulting in a dead store and misleading initialization.
- [Low] `samples/damon/hugepage.c` fails to compile on configs without `TRANSPARENT_HUGEPAGE` due to `HPAGE_PMD_SIZE`.
--

commit 6648426483c20398b6f6fd9f51731549de51d36d
Author: Asier Gutierrez <gutierrez.asier@huawei-partners.com>

mm/damon/sysfs: support hugepage_mem_bp quota goal metric

Add the "hugepage_mem_bp" to the sysfs-schemes interface. Also handle
DAMOS_QUOTA_HUGEPAGE_MEM_BP when constructing quota goals.

> diff --git a/mm/damon/core.c b/mm/damon/core.c
> --- a/mm/damon/core.c
> +++ b/mm/damon/core.c
> @@ -2795,6 +2795,17 @@ static unsigned int damos_get_in_active_mem_bp(bool active_ratio)
>  	return mult_frac(inactive, 10000, total);
>  }
>  
> +static unsigned int damos_hugepage_mem_bp(void)
> +{
> +	unsigned long thp, total;
> +
> +	thp = global_node_page_state(NR_ANON_THPS) +
> +				global_node_page_state(NR_SHMEM_THPS) +
> +				global_node_page_state(NR_FILE_THPS);
> +	total = totalram_pages() - global_zone_page_state(NR_FREE_PAGES);

[Severity: High]
Can total be zero here, leading to a division by zero exception?

The total variable is calculated as totalram_pages() -
global_zone_page_state(NR_FREE_PAGES). On a newly booted system or due to
vm_stat per-CPU counter drift, NR_FREE_PAGES could temporarily equal
totalram_pages(), making total exactly 0.

If total is 0, passing it to mult_frac() will trigger a division by zero
exception and panic the kernel, since mult_frac(x, n, d) evaluates x / d.

Could a safeguard like if (!total) return 0; be added to prevent this?

> +	return mult_frac(thp, 10000, total);

[Severity: Medium]
Will this calculation overflow on 32-bit architectures?

The macro mult_frac(x, n, d) executes (x % d) * n / d, which evaluates to
thp * 10000 / total. Since thp and 10000 are unsigned long, this
multiplication occurs in 32-bit arithmetic on 32-bit architectures.

NR_ANON_THPS stores the number of base pages that are PMD-mapped. If the
system has more than 429,496 THP pages (approx 1.63 GB of memory, which is
possible on 32-bit architectures like ARM with LPAE), the multiplication
thp * 10000 overflows unsigned long.

This wrap-around results in an incorrect, artificially small value being fed
to the DAMON quota tuner, leading to erratic auto-tuning behavior.

> +}
> +

[ ... ]

> diff --git a/mm/damon/sysfs-schemes.c b/mm/damon/sysfs-schemes.c
> --- a/mm/damon/sysfs-schemes.c
> +++ b/mm/damon/sysfs-schemes.c
[ ... ]
> @@ -2877,6 +2881,9 @@ static int damos_sysfs_add_quota_score(
>  		case DAMOS_QUOTA_NODE_ELIGIBLE_MEM_BP:
>  			goal->nid = sysfs_goal->nid;
>  			break;
> +		case DAMOS_QUOTA_HUGEPAGE_MEM_BP:
> +			goal->current_value = sysfs_goal->current_value;

[Severity: Low]
Does this erroneously copy the current value from sysfs?

Because DAMOS_QUOTA_HUGEPAGE_MEM_BP is an auto-calculated system metric
rather than a user-provided one, the DAMON core unconditionally overwrites
goal->current_value during the first evaluation interval in
damos_set_quota_goal_current_value().

This assignment appears to be dead code that breaks the pattern of other
system metrics which correctly fall through to the default case.

> +			break;
>  		default:
>  			break;
>  		}

[ ... ]

> diff --git a/samples/damon/Kconfig b/samples/damon/Kconfig
> --- a/samples/damon/Kconfig
> +++ b/samples/damon/Kconfig
> @@ -40,4 +40,16 @@ config SAMPLE_DAMON_MTIER
>  
>  	  If unsure, say N.
>  
> +config SAMPLE_DAMON_HUGEPAGE
> +	bool "Build DAMON-based collapse of hot regions (SAMPLE_DAMON_HUGEPAGE)"
> +	depends on DAMON && DAMON_VADDR

[Severity: Low]
Will this cause build failures on configurations without huge page support?

The Kconfig option SAMPLE_DAMON_HUGEPAGE does not depend on
TRANSPARENT_HUGEPAGE. When CONFIG_PGTABLE_HAS_HUGE_LEAVES is not set (which
happens when huge page support is disabled), HPAGE_PMD_SIZE resolves to
(1UL) << ({ BUILD_BUG(); 0; }).

This could lead to compile errors in samples/damon/hugepage.c since it uses
HPAGE_PMD_SIZE to calculate huge page counts.

> +	help
> +	  This module monitors a certain PID provided by the user through

[ ... ]

> diff --git a/samples/damon/hugepage.c b/samples/damon/hugepage.c
> new file mode 100644
> --- /dev/null
> +++ b/samples/damon/hugepage.c
[ ... ]
> +static int damon_sample_hugepage_damon_call_fn(void *data)
> +{
> +	struct damon_ctx *c = data;
> +	struct damon_target *t;
> +
> +	damon_for_each_target(t, c) {
> +		struct damon_region *r;
> +		unsigned long hugepages = 0;
> +
> +		damon_for_each_region(r, t) {
> +			if (r->nr_accesses > 0)
> +				hugepages += r->ar.end - r->ar.start;
> +		}
> +		hugepages = hugepages / HPAGE_PMD_SIZE;

[Severity: Low]
Does this use HPAGE_PMD_SIZE without verifying huge page support is available?

As mentioned above, if TRANSPARENT_HUGEPAGE is not enabled, this macro will
trigger a BUILD_BUG() and break the compilation.

> +		pr_info("hugepage: %lu\n", hugepages);
> +	}
> +	return 0;
> +}

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260611150244.3454699-1-gutierrez.asier@huawei-partners.com?part=3