[PATCH v1 0/3] mm/damon: Introduce a huge page collapsing mechanism using auto tuning

[PATCH v1 0/3] 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 sample module (SAMPLE_DAMON_HPAGE) 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 sample module launches
a kdamond thread for a certain task provided by the user through
taget_pid module argument. Hugepage goal autotuning will automatically
adjust the aggressiveness of hot region collapses.

This sample 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) > taget_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. Timestamp is in
second and the memory usage in is MBytes. Gaps in the timestamp means
that no changes in the hugepage consumption happened over that period
of time in MB. The total used memory is calculated as
mem_total - mem free. The huge page used is calculated as
huge_page_anon + huge_page_shmem + huge_page_file. The table also
shows the huge pages to total memory ratio.

Hugepage autotune benchmark:
+-----------+----------------+----------------+----------------------+
| 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


THP (always) benchmark:
+-----------+----------------+----------------+---------------------+
| timestamp | total mem used | huge page used | percentage hugepage |
+-----------+----------------+----------------+---------------------+
|         1 |    4489.320313 |            184 |         4.098615986 |
|        15 |    4581.871094 |            214 |         4.670580984 |
|        30 |    4757.742188 |            376 |         7.902908253 |
|        45 |    4937.574219 |            558 |         11.30109595 |
|        60 |    5147.867188 |            728 |         14.14177898 |
|        75 |      5407.0625 |            918 |         16.97779524 |
|        95 |    5668.796875 |           1040 |         18.34604455 |
|       105 |    5723.839844 |           1056 |         18.44915352 |
|       115 |     5736.84375 |           1072 |         18.68623317 |
|       125 |    5732.042969 |           1088 |         18.98101612 |
|       186 |    5753.601563 |           1184 |         20.57841488 |
|       246 |    5746.398438 |           1280 |         22.27482159 |
|       306 |    5752.128906 |           1376 |         23.92157795 |
|       367 |      5772.5625 |           1472 |         25.49994045 |
|       427 |    5832.019531 |           1568 |         26.88605536 |
|       488 |    5813.246094 |           1664 |         28.62428277 |
|       548 |    5807.621094 |           1760 |         30.30500736 |
|       598 |    5841.253906 |           1822 |         31.19193292 |
|       669 |    5982.160156 |           1854 |         30.99214918 |
|       931 |    5946.605469 |           1868 |         31.41287933 |
|       981 |    6020.207031 |           1896 |         31.49393352 |
|       991 |    5988.445313 |           1910 |         31.89475566 |
|      1011 |    5988.570313 |           1926 |         32.16126554 |
|      1032 |    6016.039063 |           1936 |         32.18064211 |
|      1575 |    6057.289063 |           1968 |         32.48978181 |
|      1606 |    6026.167969 |           2000 |         33.18858702 |
+-----------+----------------+----------------+---------------------+
I ignored some points to make the table shorter. Anyway, the amount
of memory consumption, total and huge pages, is a lot higher than
with DAMON hugepage autotuning.


Performance:
Baseline (no THP, module off) -> 18,162.45 transactions per second
Hugepage autotune -> 18,211.82 transactions per second (+0.27% improvement)
THP always -> 18,388.3 (+1.24%)
THP madvise -> 18,179.25 (+0.09%)

Improvement is due to lower TLB misses

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

Changes from previous versions
==============================
RFC 4[3] -> v1
  - Renamed config to SAMPLE_DAMON_HPAGE, file to hpage.c and
    functions to damon_sample_hpage_...
  - Make the module depend on TRANSPARENT_HUGEPAGE, since
    the module will need some THP functions anyway
  - Removed documentation, since this is just a sample module
  - Removed DAMOS_QUOTA_HUGEPAGE_MEM_BP from
    damos_sysfs_add_quota_score
  - Added a short description of the module in Kconfig

RFC 3[4] -> 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[5] -> 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 [6]
  - Fixed typos and added quota_sz to the documentation
    discovered by sashiko [7]

RFC 1[8] -> 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.[9]

[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/20260611150244.3454699-1-gutierrez.asier@huawei-partners.com
[4] https://lore.kernel.org/20260604150338.501128-1-gutierrez.asier@huawei-partners.com
[5] https://lore.kernel.org/20260522145518.158910-1-gutierrez.asier@huawei-partners.com
[6] https://lore.kernel.org/20260522171210.900B11F00A3D@smtp.kernel.org
[7] https://lore.kernel.org/20260522171633.AAF5B1F000E9@smtp.kernel.org
[8] https://lore.kernel.org/20260430134139.2446417-1-gutierrez.asier@huawei-partners.com
[9] https://lore.kernel.org/all/20260430154338.E22E6C2BCB3@smtp.kernel.org/

Asier Gutierrez (3):
  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

 include/linux/damon.h    |  2 ++
 mm/damon/core.c          | 14 ++++++++++++++
 mm/damon/sysfs-schemes.c |  4 ++++
 samples/damon/Kconfig    | 14 ++++++++++++++
 samples/damon/Makefile   |  1 +
 5 files changed, 35 insertions(+)

-- 
2.43.0

[PATCH v1 1/3] 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

[PATCH v1 2/3] 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_HPAGE)
which collapses hot regions into huge pages.

SAMPLE_DAMON_HPAGE 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 target_pid module
variable.

SAMPLE_DAMON_HPAGE 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       |  14 +++
 samples/damon/Makefile      |   1 +
 samples/damon/hpage.c (new) | 207 ++++++++++++++++++++++++++++++++++++
 3 files changed, 222 insertions(+)

diff --git a/samples/damon/Kconfig b/samples/damon/Kconfig
index cbf96fd8a8bf..1ef0b12c32e6 100644
--- a/samples/damon/Kconfig
+++ b/samples/damon/Kconfig
@@ -40,4 +40,18 @@ config SAMPLE_DAMON_MTIER
 
 	  If unsure, say N.
 
+config SAMPLE_DAMON_HPAGE
+	bool "Build DAMON-based collapse of hot regions (SAMPLE_DAMON_HPAGE)"
+	depends on DAMON && DAMON_VADDR && TRANSPARENT_HUGEPAGE
+	help
+	  This builds DAMON sample module for collapsing regions into huge pages.
+
+	  This module monitors a certain PID provided by the user through
+	  target_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..a348dc74ddcb 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) += hpage.o
diff --git a/samples/damon/hpage.c b/samples/damon/hpage.c
new file mode 100644
index 000000000000..ebbe5e1be1a1
--- /dev/null
+++ b/samples/damon/hpage.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_hpage: " 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_hpage."
+
+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_hpage_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_hpage_damon_call_fn,
+	.repeat = true,
+};
+
+static int damon_sample_hpage_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_hpage_stop(void)
+{
+	pr_info("stop\n");
+	if (ctx) {
+		damon_stop(&ctx, 1);
+		damon_destroy_ctx(ctx);
+	}
+}
+static int damon_sample_hpage_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_hpage_start();
+		if (err)
+			enabled = false;
+		return err;
+	}
+	damon_sample_hpage_stop();
+	return 0;
+}
+
+static const struct kernel_param_ops enabled_param_ops = {
+	.set = damon_sample_hpage_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_hpage_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_hpage_start();
+		if (err)
+			enabled = false;
+	}
+	return err;
+}
+
+module_init(damon_sample_hpage_init);
-- 
2.43.0

[PATCH v1 3/3] mm/damon/sysfs: support hugepage_mem_bp quota goal metric

[gutierrez.asier]

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

DAMOS has a new autotune policy metric: DAMOS_QUOTA_HUGEPAGE_MEM_BP.
This patch exposes DAMOS_QUOTA_HUGEPAGE_MEM_BP through sysfs.

Add the "hugepage_mem_bp" to the sysfs-schemes interface.

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

diff --git a/mm/damon/sysfs-schemes.c b/mm/damon/sysfs-schemes.c
index 329cfd0bbe9f..4b5429a5b415 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,
-- 
2.43.0

Re: [PATCH v1 1/3] mm/damon: Introduce DAMOS_QUOTA_HUGEPAGE auto tuning

[sashiko-bot]

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

New issues:
- [High] The `mult_frac(thp, 10000, total)` macro call silently overflows `unsigned long` on 32-bit architectures, yielding incorrect DAMOS quota metrics.

Pre-existing issues:
- [Critical] The `damos_get_in_active_mem_bp()` function can trigger a divide-by-zero exception if there are no active and inactive LRU pages.
--

commit 812a9d3523a15be0a409c86d1076f2098e299808
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.

[ ... ]

> 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: Critical]
This is a pre-existing issue, but can this divide by zero if there are no
active and inactive LRU pages?

If a system has no active or inactive anonymous/file LRU pages (for example,
immediately after early boot before userspace populates the LRU), total
evaluates to exactly 0. The mult_frac macro performs division by total,
which would trigger a divide-by-zero hardware exception.

>  }
>  
> +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);

[Severity: High]
Does this calculation silently overflow unsigned long on 32-bit
architectures?

The mult_frac(x, n, d) macro computes (x / d) * n + (x % d) * n / d. Because
thp is always less than or equal to total, thp / total evaluates to 0,
leaving (thp * 10000) / total.

Both thp and 10000 evaluate as 32-bit unsigned long on 32-bit systems, so
the intermediate multiplication thp * 10000 will wrap around if thp exceeds
roughly 1.75 GB (429,496 pages). This would cause the metric to under-report
hugepage usage.

> +}

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

Re: [PATCH v1 2/3] 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:
- [Medium] The `DAMOS_QUOTA_USER_INPUT` goal tuner feedback mechanism is statically stuck because `current_value` is never dynamically updated.
- [Medium] The scheme applies the DAMOS_COLLAPSE action to all regions including completely cold ones, contradicting the patch description.
- [Low] The module cannot be compiled due to a naming mismatch between the Kconfig symbol and the Makefile variable.
--

commit 7e15caa860a55beb8439fc6bb5f299c5c42fb138
Author: Asier Gutierrez <gutierrez.asier@huawei-partners.com>

mm/damon: introduce DAMON_HUGEPAGE for hot region hugepage collapsing

This patch introduces a new DAMON module (SAMPLE_DAMON_HPAGE)
which collapses hot regions into huge pages. The module monitors
a specific task using DAMON-based sampling and applies collapsing
based on memory usage.

> diff --git a/samples/damon/Makefile b/samples/damon/Makefile
> index 72f68cbf422aa..a348dc74ddcb1 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) += hpage.o

[Severity: Low]
Does this prevent the module from building? 

The Kconfig file defines the configuration option as SAMPLE_DAMON_HPAGE, 
but the Makefile evaluates CONFIG_SAMPLE_DAMON_HUGEPAGE. This mismatch 
means the build system might silently skip compiling hpage.o.

> diff --git a/samples/damon/hpage.c b/samples/damon/hpage.c
> new file mode 100644
> index 0000000000000..ebbe5e1be1a1d
> --- /dev/null
> +++ b/samples/damon/hpage.c

[ ... ]

> +	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,

[Severity: Medium]
Will this apply the collapse action to completely cold regions? 

The commit message states this module collapses "hot regions", but setting 
min_nr_accesses to 0 instructs DAMON to apply the action to all regions 
that meet the age threshold, including those with no accesses at all. 

Should this be set to a value strictly greater than 0 to only target 
heavily accessed regions?

[ ... ]

> +	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);
> +	}

[Severity: Medium]
Is there a missing mechanism to dynamically update this feedback value?

Since the module parameter is assigned to current_value exactly once at 
startup, without a dynamic update path while running, the auto-tuner will 
receive a constant error value. 

Won't this continuously push the quota aggressiveness in one direction 
until it hits the limits, rather than forming a proper feedback loop?

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

Re: [PATCH v1 3/3] mm/damon/sysfs: support hugepage_mem_bp quota goal metric

[sashiko-bot]

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

New issues:
- [Low] The new `DAMOS_QUOTA_HUGEPAGE_MEM_BP` metric is exposed via sysfs but lacks required documentation updates.

Pre-existing issues:
- [Critical] Potential divide-by-zero in `damos_hugepage_mem_bp()` and `damos_get_in_active_mem_bp()` due to an unhandled zero denominator.
- [High] 32-bit integer overflow in `damos_hugepage_mem_bp()` and `damos_get_in_active_mem_bp()` when calculating memory ratios.
--

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

mm/damon/sysfs: support hugepage_mem_bp quota goal metric

DAMOS has a new autotune policy metric: DAMOS_QUOTA_HUGEPAGE_MEM_BP.
This patch exposes DAMOS_QUOTA_HUGEPAGE_MEM_BP through sysfs.

> diff --git a/mm/damon/sysfs-schemes.c b/mm/damon/sysfs-schemes.c
> index 329cfd0bbe9f3..4b5429a5b4158 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",
> +	},

[Severity: Critical]
This isn't a bug introduced by this patch, but exposing this metric directly
to userspace makes a potential divide-by-zero triggerable by users
configuring DAMON quotas.

In mm/damon/core.c:damos_hugepage_mem_bp(), the denominator is computed as:

    total = totalram_pages() - global_zone_page_state(NR_FREE_PAGES);

Due to per-CPU vmstat lag or an idle system, the free pages counter can equal
totalram_pages(), resulting in total being 0. This is then passed to
mult_frac():

    return mult_frac(thp, 10000, total);

This inherently computes thp / total, causing a strict division by zero and a
kernel panic. The same issue exists in damos_get_in_active_mem_bp() where
total = active + inactive, which can be 0 if the LRU lists are empty.

Should a zero-check on total be added before performing the division?

[Severity: High]
This is a pre-existing issue, but exposing this metric also surfaces a 32-bit
integer overflow in mm/damon/core.c:damos_hugepage_mem_bp().

The mult_frac(x, n, d) macro performs the multiplication (x % d) * n. Here x
is thp, which is an unsigned long.

On 32-bit systems, if thp exceeds ~429,496 pages (around 1.75 GB),
(thp % total) * 10000 will silently overflow the 32-bit unsigned long type.

This wrap-around yields an erroneously low ratio instead of the correct value.
The same overflow applies to damos_get_in_active_mem_bp() if the active or
inactive pages exceed 1.75 GB.

Could this be fixed by casting the first argument to u64 to prevent the
overflow?

[Severity: Low]
Does this patch also require an update to the authoritative DAMON sysfs
documentation?

Documentation/mm/damon/design.rst explicitly lists all valid string values
for the target_metric sysfs file, but does not include hugepage_mem_bp.
Without documenting the new metric, it may remain undiscoverable for users.

>  };
>  
>  static ssize_t target_metric_show(struct kobject *kobj,

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

Re: [PATCH v1 2/3] mm/damon: introduce DAMON_HUGEPAGE for hot region hugepage collapsing

[Gutierrez Asier]

On 6/16/2026 6:21 PM, sashiko-bot@kernel.org wrote:
> Thank you for your contribution! Sashiko AI review found 3 potential issue(s) to consider:
> - [Medium] The `DAMOS_QUOTA_USER_INPUT` goal tuner feedback mechanism is statically stuck because `current_value` is never dynamically updated.
> - [Medium] The scheme applies the DAMOS_COLLAPSE action to all regions including completely cold ones, contradicting the patch description.
> - [Low] The module cannot be compiled due to a naming mismatch between the Kconfig symbol and the Makefile variable.
> --
> 
> commit 7e15caa860a55beb8439fc6bb5f299c5c42fb138
> Author: Asier Gutierrez <gutierrez.asier@huawei-partners.com>
> 
> mm/damon: introduce DAMON_HUGEPAGE for hot region hugepage collapsing
> 
> This patch introduces a new DAMON module (SAMPLE_DAMON_HPAGE)
> which collapses hot regions into huge pages. The module monitors
> a specific task using DAMON-based sampling and applies collapsing
> based on memory usage.
> 
>> diff --git a/samples/damon/Makefile b/samples/damon/Makefile
>> index 72f68cbf422aa..a348dc74ddcb1 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) += hpage.o
> 
> [Severity: Low]
> Does this prevent the module from building? 
> 
> The Kconfig file defines the configuration option as SAMPLE_DAMON_HPAGE, 
> but the Makefile evaluates CONFIG_SAMPLE_DAMON_HUGEPAGE. This mismatch 
> means the build system might silently skip compiling hpage.o.
Yes, my bad when moving around code from different branches. Will
be fixed in v2.
>> diff --git a/samples/damon/hpage.c b/samples/damon/hpage.c
>> new file mode 100644
>> index 0000000000000..ebbe5e1be1a1d
>> --- /dev/null
>> +++ b/samples/damon/hpage.c
> 
> [ ... ]
> 
>> +	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,
> 
> [Severity: Medium]
> Will this apply the collapse action to completely cold regions? 
> 
> The commit message states this module collapses "hot regions", but setting 
> min_nr_accesses to 0 instructs DAMON to apply the action to all regions 
> that meet the age threshold, including those with no accesses at all. 
> 
> Should this be set to a value strictly greater than 0 to only target 
> heavily accessed regions?
Good catch. I will update it to 1.
> [ ... ]
> 
>> +	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);
>> +	}
> 
> [Severity: Medium]
> Is there a missing mechanism to dynamically update this feedback value?
> 
> Since the module parameter is assigned to current_value exactly once at 
> startup, without a dynamic update path while running, the auto-tuner will 
> receive a constant error value. 
> 
> Won't this continuously push the quota aggressiveness in one direction 
> until it hits the limits, rather than forming a proper feedback loop?
> 
This is a sample module. There is no commit mechanism as in the usual
DAMON modules. It should be set up before enabling the module.

I will document this behaviour in the documentation.

-- 
Asier Gutierrez
Huawei

Re: [PATCH v1 1/3] mm/damon: Introduce DAMOS_QUOTA_HUGEPAGE auto tuning

[Gutierrez Asier]

On 6/16/2026 6:20 PM, sashiko-bot@kernel.org wrote:
> Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
> 
> New issues:
> - [High] The `mult_frac(thp, 10000, total)` macro call silently overflows `unsigned long` on 32-bit architectures, yielding incorrect DAMOS quota metrics.
> 
> Pre-existing issues:
> - [Critical] The `damos_get_in_active_mem_bp()` function can trigger a divide-by-zero exception if there are no active and inactive LRU pages.
> --
> 
> commit 812a9d3523a15be0a409c86d1076f2098e299808
> 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.
> 
> [ ... ]
> 
>> 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: Critical]
> This is a pre-existing issue, but can this divide by zero if there are no
> active and inactive LRU pages?
> 
> If a system has no active or inactive anonymous/file LRU pages (for example,
> immediately after early boot before userspace populates the LRU), total
> evaluates to exactly 0. The mult_frac macro performs division by total,
> which would trigger a divide-by-zero hardware exception.
As described in a previous patch set[1], total will never be 0, since
the module will only be enabled after the system is fully loaded.
>>  }
>>  
>> +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);
> 
> [Severity: High]
> Does this calculation silently overflow unsigned long on 32-bit
> architectures?
> 
> The mult_frac(x, n, d) macro computes (x / d) * n + (x % d) * n / d. Because
> thp is always less than or equal to total, thp / total evaluates to 0,
> leaving (thp * 10000) / total.
> 
> Both thp and 10000 evaluate as 32-bit unsigned long on 32-bit systems, so
> the intermediate multiplication thp * 10000 will wrap around if thp exceeds
> roughly 1.75 GB (429,496 pages). This would cause the metric to under-report
> hugepage usage.
As discussed before, we will leave this behaviour as it is.[2]
>> +}
> 

[1] https://lore.kernel.org/all/20260611152146.AD2821F00898@smtp.kernel.org/
[2] https://lore.kernel.org/all/20260609145240.69552-1-sj@kernel.org
-- 
Asier Gutierrez
Huawei

Re: [PATCH v1 3/3] mm/damon/sysfs: support hugepage_mem_bp quota goal metric

[Gutierrez Asier]

On 6/16/2026 6:21 PM, sashiko-bot@kernel.org wrote:
> Thank you for your contribution! Sashiko AI review found 3 potential issue(s) to consider:
> 
> New issues:
> - [Low] The new `DAMOS_QUOTA_HUGEPAGE_MEM_BP` metric is exposed via sysfs but lacks required documentation updates.
> 
> Pre-existing issues:
> - [Critical] Potential divide-by-zero in `damos_hugepage_mem_bp()` and `damos_get_in_active_mem_bp()` due to an unhandled zero denominator.
> - [High] 32-bit integer overflow in `damos_hugepage_mem_bp()` and `damos_get_in_active_mem_bp()` when calculating memory ratios.
> --
> 
> commit be304699fb94d4d73bd979237fb4d7b08b7216f7
> Author: Asier Gutierrez <gutierrez.asier@huawei-partners.com>
> 
> mm/damon/sysfs: support hugepage_mem_bp quota goal metric
> 
> DAMOS has a new autotune policy metric: DAMOS_QUOTA_HUGEPAGE_MEM_BP.
> This patch exposes DAMOS_QUOTA_HUGEPAGE_MEM_BP through sysfs.
> 
>> diff --git a/mm/damon/sysfs-schemes.c b/mm/damon/sysfs-schemes.c
>> index 329cfd0bbe9f3..4b5429a5b4158 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",
>> +	},
> 
> [Severity: Critical]
> This isn't a bug introduced by this patch, but exposing this metric directly
> to userspace makes a potential divide-by-zero triggerable by users
> configuring DAMON quotas.
> 
> In mm/damon/core.c:damos_hugepage_mem_bp(), the denominator is computed as:
> 
>     total = totalram_pages() - global_zone_page_state(NR_FREE_PAGES);
> 
> Due to per-CPU vmstat lag or an idle system, the free pages counter can equal
> totalram_pages(), resulting in total being 0. This is then passed to
> mult_frac():
> 
>     return mult_frac(thp, 10000, total);
> 
> This inherently computes thp / total, causing a strict division by zero and a
> kernel panic. The same issue exists in damos_get_in_active_mem_bp() where
> total = active + inactive, which can be 0 if the LRU lists are empty.
> 
> Should a zero-check on total be added before performing the division?
DAMON is enabled after the system is fully loaded. total will not be 0 by then.
> [Severity: High]
> This is a pre-existing issue, but exposing this metric also surfaces a 32-bit
> integer overflow in mm/damon/core.c:damos_hugepage_mem_bp().
> 
> The mult_frac(x, n, d) macro performs the multiplication (x % d) * n. Here x
> is thp, which is an unsigned long.
> 
> On 32-bit systems, if thp exceeds ~429,496 pages (around 1.75 GB),
> (thp % total) * 10000 will silently overflow the 32-bit unsigned long type.
> 
> This wrap-around yields an erroneously low ratio instead of the correct value.
> The same overflow applies to damos_get_in_active_mem_bp() if the active or
> inactive pages exceed 1.75 GB.
> 
> Could this be fixed by casting the first argument to u64 to prevent the
> overflow?
As described in this patch set, this will be the default behaviour in that
case.
> [Severity: Low]
> Does this patch also require an update to the authoritative DAMON sysfs
> documentation?
> 
> Documentation/mm/damon/design.rst explicitly lists all valid string values
> for the target_metric sysfs file, but does not include hugepage_mem_bp.
> Without documenting the new metric, it may remain undiscoverable for users.
I will update the documentation. 
>>  };
>>  
>>  static ssize_t target_metric_show(struct kobject *kobj,
> 

-- 
Asier Gutierrez
Huawei

Re: [PATCH v1 0/3] mm/damon: Introduce a huge page collapsing mechanism using auto tuning

[SeongJae Park]

On Tue, 16 Jun 2026 15:03:13 +0000 <gutierrez.asier@huawei-partners.com> wrote:

> 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.

Could you please reword for prctl(PR_SET_THP_DISABLE) like per-process control
cases, as we discussed [1] on RFC v3?

> 
> 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 sample module (SAMPLE_DAMON_HPAGE) 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 sample module launches
> a kdamond thread for a certain task provided by the user through
> taget_pid module argument. Hugepage goal autotuning will automatically
> adjust the aggressiveness of hot region collapses.
> 
> This sample 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

I guess this is the quota goal?  What is the unit?  I guess it is aparently not
percentage?  The name doesn't sound like very consistent or intuitive.  How
about hugepage_mem_bp or target_hugepage_mem_bp?

> # echo $(pidof mariadbd) > taget_pid
> # echo on > enabled
> 
> The goal was to achieve 5% of the total memory used as hugepage.

I guess this is what the above example is setting using
'quotta_percentage_hugepage'?  If so, it means the unit is 1/20000 ?  Is this
correct...?

> Since the database was not very big, we may not be able to achieve
> high amount of huge pages per total memory consumption ratio.

I believe this patch series will work as you explained.  But, it seems bit
weird to show a test result that doesn't demonstrate what this patch is aimed
to achive.  Could you increase the size of the database?  IIRC, you were able
to show the percentage is over-achived case in an early version.

> 
> The table below shows the memory consumption over time. Timestamp is in
> second and the memory usage in is MBytes. Gaps in the timestamp means
> that no changes in the hugepage consumption happened over that period
> of time in MB. The total used memory is calculated as
> mem_total - mem free. The huge page used is calculated as
> huge_page_anon + huge_page_shmem + huge_page_file. The table also
> shows the huge pages to total memory ratio.
> 
> Hugepage autotune benchmark:
> +-----------+----------------+----------------+----------------------+
> | 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
> 
> 
> THP (always) benchmark:
> +-----------+----------------+----------------+---------------------+
> | timestamp | total mem used | huge page used | percentage hugepage |
> +-----------+----------------+----------------+---------------------+
> |         1 |    4489.320313 |            184 |         4.098615986 |
> |        15 |    4581.871094 |            214 |         4.670580984 |
> |        30 |    4757.742188 |            376 |         7.902908253 |
> |        45 |    4937.574219 |            558 |         11.30109595 |
> |        60 |    5147.867188 |            728 |         14.14177898 |
> |        75 |      5407.0625 |            918 |         16.97779524 |
> |        95 |    5668.796875 |           1040 |         18.34604455 |
> |       105 |    5723.839844 |           1056 |         18.44915352 |
> |       115 |     5736.84375 |           1072 |         18.68623317 |
> |       125 |    5732.042969 |           1088 |         18.98101612 |
> |       186 |    5753.601563 |           1184 |         20.57841488 |
> |       246 |    5746.398438 |           1280 |         22.27482159 |
> |       306 |    5752.128906 |           1376 |         23.92157795 |
> |       367 |      5772.5625 |           1472 |         25.49994045 |
> |       427 |    5832.019531 |           1568 |         26.88605536 |
> |       488 |    5813.246094 |           1664 |         28.62428277 |
> |       548 |    5807.621094 |           1760 |         30.30500736 |
> |       598 |    5841.253906 |           1822 |         31.19193292 |
> |       669 |    5982.160156 |           1854 |         30.99214918 |
> |       931 |    5946.605469 |           1868 |         31.41287933 |
> |       981 |    6020.207031 |           1896 |         31.49393352 |
> |       991 |    5988.445313 |           1910 |         31.89475566 |
> |      1011 |    5988.570313 |           1926 |         32.16126554 |
> |      1032 |    6016.039063 |           1936 |         32.18064211 |
> |      1575 |    6057.289063 |           1968 |         32.48978181 |
> |      1606 |    6026.167969 |           2000 |         33.18858702 |
> +-----------+----------------+----------------+---------------------+
> I ignored some points to make the table shorter. Anyway, the amount
> of memory consumption, total and huge pages, is a lot higher than
> with DAMON hugepage autotuning.

Could you further clarify why it is, and what this means?

> 
> 
> Performance:
> Baseline (no THP, module off) -> 18,162.45 transactions per second
> Hugepage autotune -> 18,211.82 transactions per second (+0.27% improvement)
> THP always -> 18,388.3 (+1.24%)
> THP madvise -> 18,179.25 (+0.09%)
> 
> Improvement is due to lower TLB misses

So this result says THP always is much better than the Hugepage autotune in
terms of the performance.  Maybe you want to claim Hugepage autotune is better
in terms of the memory efficiency?  Could you please clarify further?

> 
> 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
> 
> Changes from previous versions
> ==============================
> RFC 4[3] -> v1
>   - Renamed config to SAMPLE_DAMON_HPAGE, file to hpage.c and
>     functions to damon_sample_hpage_...
>   - Make the module depend on TRANSPARENT_HUGEPAGE, since
>     the module will need some THP functions anyway
>   - Removed documentation, since this is just a sample module
>   - Removed DAMOS_QUOTA_HUGEPAGE_MEM_BP from
>     damos_sysfs_add_quota_score
>   - Added a short description of the module in Kconfig

Thank you for continuing this work!

[...]

> [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/20260611150244.3454699-1-gutierrez.asier@huawei-partners.com
> [4] https://lore.kernel.org/20260604150338.501128-1-gutierrez.asier@huawei-partners.com
> [5] https://lore.kernel.org/20260522145518.158910-1-gutierrez.asier@huawei-partners.com
> [6] https://lore.kernel.org/20260522171210.900B11F00A3D@smtp.kernel.org
> [7] https://lore.kernel.org/20260522171633.AAF5B1F000E9@smtp.kernel.org
> [8] https://lore.kernel.org/20260430134139.2446417-1-gutierrez.asier@huawei-partners.com
> [9] https://lore.kernel.org/all/20260430154338.E22E6C2BCB3@smtp.kernel.org/

[1] https://lore.kernel.org/9f9e2159-5a6b-496f-9633-fa06c0217948@huawei-partners.com


Thanks,
SJ

[...]

Re: [PATCH v1 1/3] mm/damon: Introduce DAMOS_QUOTA_HUGEPAGE auto tuning

[SeongJae Park]

On Tue, 16 Jun 2026 15:03:14 +0000 <gutierrez.asier@huawei-partners.com> wrote:

> From: Asier Gutierrez <gutierrez.asier@huawei-partners.com>
> 
> Introduce DAMOS_QUOTA_HUGEPAGE auto tuning Add a new

Please fix the name of the quota, and add the ending period after 'tuning'.

> 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

Code looks good to me.


Thanks,
SJ

Re: [PATCH v1 2/3] mm/damon: introduce DAMON_HUGEPAGE for hot region hugepage collapsing

[SeongJae Park]

On Tue, 16 Jun 2026 15:03:15 +0000 <gutierrez.asier@huawei-partners.com> wrote:

> From: Asier Gutierrez <gutierrez.asier@huawei-partners.com>
> 
> This patch introduces a new DAMON module (SAMPLE_DAMON_HPAGE)
> which collapses hot regions into huge pages.
> 
> SAMPLE_DAMON_HPAGE 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 target_pid module
> variable.

s/variable/parameter/ ?

> 
> SAMPLE_DAMON_HPAGE 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.

Is the user autotuning really needed for this sample module?  I'm concerned if
it is unnecessarily making the code complicated.  Can we drop this?

> 
> The module also includes changes to the DAMON compilation,

I think this is not true?

> so that
> the module can be enabled or disabled.
> 
> Signed-off-by: Asier Gutierrez <gutierrez.asier@huawei-partners.com>
> ---
>  samples/damon/Kconfig       |  14 +++
>  samples/damon/Makefile      |   1 +
>  samples/damon/hpage.c (new) | 207 ++++++++++++++++++++++++++++++++++++
>  3 files changed, 222 insertions(+)
> 
> diff --git a/samples/damon/Kconfig b/samples/damon/Kconfig
> index cbf96fd8a8bf..1ef0b12c32e6 100644
> --- a/samples/damon/Kconfig
> +++ b/samples/damon/Kconfig
> @@ -40,4 +40,18 @@ config SAMPLE_DAMON_MTIER
>  
>  	  If unsure, say N.
>  
> +config SAMPLE_DAMON_HPAGE
> +	bool "Build DAMON-based collapse of hot regions (SAMPLE_DAMON_HPAGE)"

Please make this be consistent to other sample modules.  E.g., DAMON sample
module for ...

> +	depends on DAMON && DAMON_VADDR && TRANSPARENT_HUGEPAGE
> +	help
> +	  This builds DAMON sample module for collapsing regions into huge pages.

... for huge pages collapsing?

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

Please use two spaces between sentences, consistent to others.

> +	  sampling. Collapsing occurs according to the quota goal using total

"DAMON-based sampling" sounds verbose and technically not making much sense.
How about just "DAMON"?

> +	  memory usage to huge page usage ratio. The ratio is set by the user

huge page to total memory usage ratio?

> +	  through a module attribute.

s/attribute/parameter/ ?

> +
> +	  If unsure, say N.
> +
>  endmenu
> diff --git a/samples/damon/Makefile b/samples/damon/Makefile
> index 72f68cbf422a..a348dc74ddcb 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) += hpage.o

... Can this be compiled...?

> diff --git a/samples/damon/hpage.c b/samples/damon/hpage.c
> new file mode 100644
> index 000000000000..ebbe5e1be1a1
> --- /dev/null
> +++ b/samples/damon/hpage.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_hpage: " 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_hpage."
> +
> +static bool enabled __read_mostly;
> +
> +static unsigned long target_pid;
> +module_param(target_pid, ulong, 0600);

Why 'ulong'?  I think 'int' is enough?

> +
> +/* 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);

"percentage" in the name sounds weird.  What about hugepage_mem_bp or
target_hugepage_mem_bp?

> +
> +static unsigned long quota_autotune_feedback __read_mostly;
> +module_param(quota_autotune_feedback, ulong, 0600);

I'm not really sure if this is really needed.  If not, could we drop this?

> +
> +static struct damon_ctx *ctx;
> +static struct pid *target_pidp;
> +
> +static int damon_sample_hpage_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;
> +}

What's the purpose of this function?  If not really  needed, can we drop?

> +
> +static struct damon_call_control call_control = {
> +	.fn = damon_sample_hpage_damon_call_fn,
> +	.repeat = true,
> +};
> +
> +static int damon_sample_hpage_start(void)
> +{
> +	int err;
> +	struct damon_target *target;
> +	struct damos *scheme;
> +	struct damos_quota_goal *goal;
> +
> +	pr_info("start\n");
> +
> +

Let's have only one blank line.

> +	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,

I don't really suggest time quota to people nowadays.  Size quota is easier to
understand and sufficient in many cases in my humble opinion.  Did you find it
is really helpful and essential for this module?  If not, could we unset time
quota?

> +				.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);
> +	}

Seems this module is not really utilizing the user input feedback.  To use that
in real, the module should periodically read user's input and feed that to
DAMON core.  I find no code doing that in this module.  If it is not really
being used, I'd suggest to drop this.

> +
> +	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_hpage_stop(void)
> +{
> +	pr_info("stop\n");
> +	if (ctx) {
> +		damon_stop(&ctx, 1);
> +		damon_destroy_ctx(ctx);
> +	}
> +}
> +static int damon_sample_hpage_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_hpage_start();
> +		if (err)
> +			enabled = false;
> +		return err;
> +	}
> +	damon_sample_hpage_stop();
> +	return 0;
> +}
> +
> +static const struct kernel_param_ops enabled_param_ops = {
> +	.set = damon_sample_hpage_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)");

s/DAMON_HUGEPAGE/DAMON_SAMPLE_HPAGE/ ?

"(default: disabled)" seems unnecessary.  Could you please remove that?

> +
> +static int __init damon_sample_hpage_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_hpage_start();
> +		if (err)
> +			enabled = false;
> +	}
> +	return err;
> +}
> +
> +module_init(damon_sample_hpage_init);
> -- 
> 2.43.0


Thanks,
SJ

Re: [PATCH v1 2/3] mm/damon: introduce DAMON_HUGEPAGE for hot region hugepage collapsing

[SeongJae Park]

On Tue, 16 Jun 2026 22:27:41 +0300 Gutierrez Asier <gutierrez.asier@huawei-partners.com> wrote:

> 
> 
> On 6/16/2026 6:21 PM, sashiko-bot@kernel.org wrote:
> > Thank you for your contribution! Sashiko AI review found 3 potential issue(s) to consider:
> > - [Medium] The `DAMOS_QUOTA_USER_INPUT` goal tuner feedback mechanism is statically stuck because `current_value` is never dynamically updated.
> > - [Medium] The scheme applies the DAMOS_COLLAPSE action to all regions including completely cold ones, contradicting the patch description.
> > - [Low] The module cannot be compiled due to a naming mismatch between the Kconfig symbol and the Makefile variable.
> > --
> > 
> > commit 7e15caa860a55beb8439fc6bb5f299c5c42fb138
> > Author: Asier Gutierrez <gutierrez.asier@huawei-partners.com>
> > 
> > mm/damon: introduce DAMON_HUGEPAGE for hot region hugepage collapsing
> > 
> > This patch introduces a new DAMON module (SAMPLE_DAMON_HPAGE)
> > which collapses hot regions into huge pages. The module monitors
> > a specific task using DAMON-based sampling and applies collapsing
> > based on memory usage.
> > 
> >> diff --git a/samples/damon/Makefile b/samples/damon/Makefile
> >> index 72f68cbf422aa..a348dc74ddcb1 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) += hpage.o
> > 
> > [Severity: Low]
> > Does this prevent the module from building? 
> > 
> > The Kconfig file defines the configuration option as SAMPLE_DAMON_HPAGE, 
> > but the Makefile evaluates CONFIG_SAMPLE_DAMON_HUGEPAGE. This mismatch 
> > means the build system might silently skip compiling hpage.o.
> Yes, my bad when moving around code from different branches. Will
> be fixed in v2.
> >> diff --git a/samples/damon/hpage.c b/samples/damon/hpage.c
> >> new file mode 100644
> >> index 0000000000000..ebbe5e1be1a1d
> >> --- /dev/null
> >> +++ b/samples/damon/hpage.c
> > 
> > [ ... ]
> > 
> >> +	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,
> > 
> > [Severity: Medium]
> > Will this apply the collapse action to completely cold regions? 
> > 
> > The commit message states this module collapses "hot regions", but setting 
> > min_nr_accesses to 0 instructs DAMON to apply the action to all regions 
> > that meet the age threshold, including those with no accesses at all. 
> > 
> > Should this be set to a value strictly greater than 0 to only target 
> > heavily accessed regions?
> Good catch. I will update it to 1.

I was assuming you intentionally set it to 0, since quota's access hotness
based prioritization will anyway cut out cold regions.  But if it was not the
intention, please feel free to update.

> > [ ... ]
> > 
> >> +	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);
> >> +	}
> > 
> > [Severity: Medium]
> > Is there a missing mechanism to dynamically update this feedback value?
> > 
> > Since the module parameter is assigned to current_value exactly once at 
> > startup, without a dynamic update path while running, the auto-tuner will 
> > receive a constant error value. 
> > 
> > Won't this continuously push the quota aggressiveness in one direction 
> > until it hits the limits, rather than forming a proper feedback loop?
> > 
> This is a sample module. There is no commit mechanism as in the usual
> DAMON modules. It should be set up before enabling the module.

It means the user feedback is not really working.

> 
> I will document this behaviour in the documentation.

I'd suggest to just drop this unused and untested feature.


Thanks,
SJ

[...]

Re: [PATCH v1 3/3] mm/damon/sysfs: support hugepage_mem_bp quota goal metric

[SeongJae Park]

On Tue, 16 Jun 2026 22:35:21 +0300 Gutierrez Asier <gutierrez.asier@huawei-partners.com> wrote:

> 
> 
> On 6/16/2026 6:21 PM, sashiko-bot@kernel.org wrote:
> > Thank you for your contribution! Sashiko AI review found 3 potential issue(s) to consider:
> > 
> > New issues:
> > - [Low] The new `DAMOS_QUOTA_HUGEPAGE_MEM_BP` metric is exposed via sysfs but lacks required documentation updates.
> > 
> > Pre-existing issues:
> > - [Critical] Potential divide-by-zero in `damos_hugepage_mem_bp()` and `damos_get_in_active_mem_bp()` due to an unhandled zero denominator.
> > - [High] 32-bit integer overflow in `damos_hugepage_mem_bp()` and `damos_get_in_active_mem_bp()` when calculating memory ratios.
> > --
> > 
> > commit be304699fb94d4d73bd979237fb4d7b08b7216f7
> > Author: Asier Gutierrez <gutierrez.asier@huawei-partners.com>
> > 
> > mm/damon/sysfs: support hugepage_mem_bp quota goal metric
> > 
> > DAMOS has a new autotune policy metric: DAMOS_QUOTA_HUGEPAGE_MEM_BP.
> > This patch exposes DAMOS_QUOTA_HUGEPAGE_MEM_BP through sysfs.
> > 
> >> diff --git a/mm/damon/sysfs-schemes.c b/mm/damon/sysfs-schemes.c
> >> index 329cfd0bbe9f3..4b5429a5b4158 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",
> >> +	},
> > 
> > [Severity: Critical]
> > This isn't a bug introduced by this patch, but exposing this metric directly
> > to userspace makes a potential divide-by-zero triggerable by users
> > configuring DAMON quotas.
> > 
> > In mm/damon/core.c:damos_hugepage_mem_bp(), the denominator is computed as:
> > 
> >     total = totalram_pages() - global_zone_page_state(NR_FREE_PAGES);
> > 
> > Due to per-CPU vmstat lag or an idle system, the free pages counter can equal
> > totalram_pages(), resulting in total being 0. This is then passed to
> > mult_frac():
> > 
> >     return mult_frac(thp, 10000, total);
> > 
> > This inherently computes thp / total, causing a strict division by zero and a
> > kernel panic. The same issue exists in damos_get_in_active_mem_bp() where
> > total = active + inactive, which can be 0 if the LRU lists are empty.
> > 
> > Should a zero-check on total be added before performing the division?
> DAMON is enabled after the system is fully loaded. total will not be 0 by then.

Could you please further clarify what "system is fully loaded" means, reaards
to what Sashiko is claiming, particularly the per-CPU vmstat lag?


Thanks,
SJ

[...]

Re: [PATCH v1 3/3] mm/damon/sysfs: support hugepage_mem_bp quota goal metric

[SeongJae Park]

On Tue, 16 Jun 2026 15:03:16 +0000 <gutierrez.asier@huawei-partners.com> wrote:

> From: Asier Gutierrez <gutierrez.asier@huawei-partners.com>
> 
> DAMOS has a new autotune policy metric: DAMOS_QUOTA_HUGEPAGE_MEM_BP.
> This patch exposes DAMOS_QUOTA_HUGEPAGE_MEM_BP through sysfs.
> 
> Add the "hugepage_mem_bp" to the sysfs-schemes interface.
> 
> Signed-off-by: Asier Gutierrez <gutierrez.asier@huawei-partners.com>

Reviewed-by: SeongJae Park <sj@kernel.org>


Thanks,
SJ

[...]