mm/damon: Introduce a huge page collapsing mechanism using auto tuning

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 <[email protected]>

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.

[ ... ]

mm/damon/core.c static unsigned int damos_get_in_active_mem_bp(bool active_ratio) · line 2795

Quoted 6 lines

mm/damon/core.c +0 -0

index 7e4b9affc5b06..b001f80681b12 100644
@@ -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.

mm/damon/core.c static unsigned int damos_get_in_active_mem_bp(bool active_ratio) · line 2806

Quoted 11 lines

mm/damon/core.c +9 -0

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

mm/damon/core.c static unsigned int damos_get_in_active_mem_bp(bool active_ratio) · line 2807

Quoted 1 line

mm/damon/core.c +1 -0

+}

From: Asier Gutierrez <[email protected]>

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 <[email protected]>

---
 include/linux/damon.h |  2 ++
 mm/damon/core.c       | 14 ++++++++++++++
 2 files changed, 16 insertions(+)

include/linux/damon.h +2 -0

index 6f7edb3590ef..23a9cec05033 100644
@@ -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,
 };
 

mm/damon/core.c +14 -0

index 7e4b9affc5b0..b001f80681b1 100644
@@ -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;
 	}

Signature · 1 line

2.43.0

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 <[email protected]>

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.

samples/damon/Makefile line 6

Quoted 9 lines

samples/damon/Makefile +1 -0

index 72f68cbf422aa..a348dc74ddcb1 100644
@@ -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.

Quoted 5 lines

samples/damon/hpage.c new file +0 -0

new file mode 100644
index 0000000000000..ebbe5e1be1a1d

[ ... ]

samples/damon/hpage.c line 94

Quoted 5 lines

samples/damon/hpage.c new file +5 -0

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

[ ... ]

samples/damon/hpage.c line 128

Quoted 9 lines

samples/damon/hpage.c new file +9 -0

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

Quoted 29 lines · On 6/16/2026 6:21 PM, [email protected] 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 <[email protected]>

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.

samples/damon/Makefile line 6

Quoted 9 lines

samples/damon/Makefile +1 -0

index 72f68cbf422aa..a348dc74ddcb1 100644
@@ -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?

Quoted 3 lines

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.

Quoted 17 lines

Quoted 5 lines

samples/damon/hpage.c new file +0 -0

new file mode 100644
index 0000000000000..ebbe5e1be1a1d

[ ... ]

samples/damon/hpage.c line 94

Quoted 5 lines

samples/damon/hpage.c new file +5 -0

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

Quoted 6 lines

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.

Quoted 19 lines

[ ... ]

samples/damon/hpage.c line 128

Quoted 9 lines

samples/damon/hpage.c new file +9 -0

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

Quoted 3 lines

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.

From: Asier Gutierrez <[email protected]>

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 <[email protected]>

---
 samples/damon/Kconfig       |  14 +++
 samples/damon/Makefile      |   1 +
 samples/damon/hpage.c (new) | 207 ++++++++++++++++++++++++++++++++++++
 3 files changed, 222 insertions(+)

samples/damon/Kconfig +0 -0

index cbf96fd8a8bf..1ef0b12c32e6 100644

samples/damon/hpage.c new file +13 -0

new file mode 100644
index 000000000000..ebbe5e1be1a1
@@ -0,0 +1,207 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (C) 2026 HUAWEI, Inc.
+ *             https://www.huawei.com
+ *
+ * Author: Asier Gutierrez <[email protected]>
+ */
+
+#define pr_fmt(fmt) "damon_sample_hpage: " fmt
+
+#include <linux/damon.h>
+#include <linux/kstrtox.h>
+#include <linux/module.h>

samples/damon/hpage.c new file +12 -0

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

samples/damon/hpage.c new file +6 -0

+
+static struct damon_call_control call_control = {
+	.fn = damon_sample_hpage_damon_call_fn,
+	.repeat = true,
+};
+

samples/damon/hpage.c new file +21 -0

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

samples/damon/hpage.c new file +19 -0

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

samples/damon/hpage.c new file +48 -0

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

samples/damon/hpage.c new file +21 -0

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

Signature · 1 line

2.43.0

Quoted 4 lines · On Tue, 16 Jun 2026 15:03:15 +0000 <[email protected]> wrote:

From: Asier Gutierrez <[email protected]>

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

Quoted 6 lines · On Tue, 16 Jun 2026 21:04:52 -0700 SeongJae Park <[email protected]> wrote:

Quoted 4 lines · On Tue, 16 Jun 2026 15:03:15 +0000 <[email protected]> wrote:

From: Asier Gutierrez <[email protected]>

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

As I mentioned on the previous version of this series, this sample module looks much better than the initial shape to my humble eyes. Much smaller and simpler. I really appreciate Asier's efforts on making this.

However... I was asking myself if this module is really needed last night, and still got not real good and confident answer.

After all, this is a sample module. The purpose is to show sample code thhat helps people understanding how they can use DAMON API. Maybe we can argue this module can be helpful at understanding how DAMOS quota goal can be used. But, mtier is already showing that. So I cannot say what new advantage this module is really bringing.

Meanwhile, this patch adds ~200 lines of code. It is a very small and simple sample module, but still we should maintain it. I, to be honest, getting little bit concerned about the maintenance overhead now.

So, if Asier has a good reason to add this module that I'm missing, I'd like to

humbly ask to consider dropping of this module for now. I'm so sorry for raising this concern this late. But, Asier, may I ask what do you think?

Thanks,
SJ

[...]

Quoted 6 lines · On Tue, 16 Jun 2026 21:04:52 -0700 SeongJae Park <[email protected]> wrote:

Quoted 4 lines · On Tue, 16 Jun 2026 15:03:15 +0000 <[email protected]> wrote:

From: Asier Gutierrez <[email protected]>

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

As I mentioned on the previous version of this series, this sample module looks much better than the initial shape to my humble eyes. Much smaller and simpler. I really appreciate Asier's efforts on making this.

However... I was asking myself if this module is really needed last night, and still got not real good and confident answer.

After all, this is a sample module. The purpose is to show sample code thhat helps people understanding how they can use DAMON API. Maybe we can argue this module can be helpful at understanding how DAMOS quota goal can be used. But, mtier is already showing that. So I cannot say what new advantage this module is really bringing.

Meanwhile, this patch adds ~200 lines of code. It is a very small and simple sample module, but still we should maintain it. I, to be honest, getting little bit concerned about the maintenance overhead now.

So, if Asier has a good reason to add this module that I'm missing, I'd like to humbly ask to consider dropping of this module for now. I'm so sorry for raising this concern this late. But, Asier, may I ask what do you think?

Thanks,
SJ

[...]

Hi SJ,

Quoted 13 lines · SeongJae Park

Quoted 6 lines · On Tue, 16 Jun 2026 21:04:52 -0700 SeongJae Park <[email protected]> wrote:

Quoted 4 lines · On Tue, 16 Jun 2026 15:03:15 +0000 <[email protected]> wrote:

From: Asier Gutierrez <[email protected]>

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

As I mentioned on the previous version of this series, this sample module looks much better than the initial shape to my humble eyes. Much smaller and simpler. I really appreciate Asier's efforts on making this.

Quoted 8 lines

However... I was asking myself if this module is really needed last night, and still got not real good and confident answer.

After all, this is a sample module. The purpose is to show sample code thhat helps people understanding how they can use DAMON API. Maybe we can argue this module can be helpful at understanding how DAMOS quota goal can be used. But, mtier is already showing that. So I cannot say what new advantage this module is really bringing.

You are right, the main goal was to show how this quota goal can be used.

Quoted 3 lines

Meanwhile, this patch adds ~200 lines of code. It is a very small and simple sample module, but still we should maintain it. I, to be honest, getting little bit concerned about the maintenance overhead now.

I understand your concerns. I know code need maintenance, and DAMON is already growing significantly.

Quoted 3 lines

So, if Asier has a good reason to add this module that I'm missing, I'd like to humbly ask to consider dropping of this module for now. I'm so sorry for raising this concern this late. But, Asier, may I ask what do you think?

So, are you suggesting to drop the module and upstreaming only the DAMOS quota goal stuff?>

Quoted 30 lines · On Thu, 18 Jun 2026 14:51:42 +0300 Gutierrez Asier…

Hi SJ,

Quoted 13 lines · SeongJae Park

Quoted 6 lines · On Tue, 16 Jun 2026 21:04:52 -0700 SeongJae Park <[email protected]> wrote:

Quoted 4 lines · On Tue, 16 Jun 2026 15:03:15 +0000 <[email protected]> wrote:

From: Asier Gutierrez <[email protected]>

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

As I mentioned on the previous version of this series, this sample module looks much better than the initial shape to my humble eyes. Much smaller and simpler. I really appreciate Asier's efforts on making this.

Quoted 8 lines

However... I was asking myself if this module is really needed last night, and still got not real good and confident answer.

After all, this is a sample module. The purpose is to show sample code thhat helps people understanding how they can use DAMON API. Maybe we can argue this module can be helpful at understanding how DAMOS quota goal can be used. But, mtier is already showing that. So I cannot say what new advantage this module is really bringing.

You are right, the main goal was to show how this quota goal can be used.

Quoted 3 lines

Meanwhile, this patch adds ~200 lines of code. It is a very small and simple sample module, but still we should maintain it. I, to be honest, getting little bit concerned about the maintenance overhead now.

I understand your concerns. I know code need maintenance, and DAMON is already growing significantly.

Quoted 5 lines

Quoted 3 lines

So, if Asier has a good reason to add this module that I'm missing, I'd like to humbly ask to consider dropping of this module for now. I'm so sorry for raising this concern this late. But, Asier, may I ask what do you think?

So, are you suggesting to drop the module and upstreaming only the DAMOS quota goal stuff?>

Yes, if you don't mind.

Thanks,
SJ

[...]

Quoted 32 lines · SeongJae Park

Quoted 30 lines · On Thu, 18 Jun 2026 14:51:42 +0300 Gutierrez Asier…

Hi SJ,

Quoted 13 lines · SeongJae Park

Quoted 6 lines · On Tue, 16 Jun 2026 21:04:52 -0700 SeongJae Park <[email protected]> wrote:

Quoted 4 lines · On Tue, 16 Jun 2026 15:03:15 +0000 <[email protected]> wrote:

From: Asier Gutierrez <[email protected]>

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

As I mentioned on the previous version of this series, this sample module looks much better than the initial shape to my humble eyes. Much smaller and simpler. I really appreciate Asier's efforts on making this.

Quoted 8 lines

However... I was asking myself if this module is really needed last night, and still got not real good and confident answer.

After all, this is a sample module. The purpose is to show sample code thhat helps people understanding how they can use DAMON API. Maybe we can argue this module can be helpful at understanding how DAMOS quota goal can be used. But, mtier is already showing that. So I cannot say what new advantage this module is really bringing.

You are right, the main goal was to show how this quota goal can be used.

Quoted 3 lines

Meanwhile, this patch adds ~200 lines of code. It is a very small and simple sample module, but still we should maintain it. I, to be honest, getting little bit concerned about the maintenance overhead now.

I understand your concerns. I know code need maintenance, and DAMON is already growing significantly.

Quoted 7 lines

Quoted 5 lines

Quoted 3 lines

So, if Asier has a good reason to add this module that I'm missing, I'd like to humbly ask to consider dropping of this module for now. I'm so sorry for raising this concern this late. But, Asier, may I ask what do you think?

So, are you suggesting to drop the module and upstreaming only the DAMOS quota goal stuff?>

Yes, if you don't mind.

Sure. I will do it a bit later.

Thanks a lot for your help reviewing the code so far.

Hi Asier,

samples/damon/Kconfig config SAMPLE_DAMON_MTIER · line 45

Quoted 3 lines · On 6/16/26 16:03, [email protected] wrote:

samples/damon/Kconfig +3 -0

+config SAMPLE_DAMON_HPAGE
+	bool "Build DAMON-based collapse of hot regions (SAMPLE_DAMON_HPAGE)"
+	depends on DAMON && DAMON_VADDR && TRANSPARENT_HUGEPAGE

The dependency on DAMON is unnecessary because you already depend on DAMON_VADDR.

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 <[email protected]>

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.

mm/damon/sysfs-schemes.c struct damos_sysfs_qgoal_metric_name damos_sysfs_qgoal_metric_names[] = { · line 1273

Quoted 12 lines

mm/damon/sysfs-schemes.c +4 -0

index 329cfd0bbe9f3..4b5429a5b4158 100644
@@ -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.

Quoted 3 lines

mm/damon/sysfs-schemes.c +0 -0

 };
 
 static ssize_t target_metric_show(struct kobject *kobj,

Quoted 44 lines · On 6/16/2026 6:21 PM, [email protected] 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 <[email protected]>

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.

mm/damon/sysfs-schemes.c struct damos_sysfs_qgoal_metric_name damos_sysfs_qgoal_metric_names[] = { · line 1273

Quoted 12 lines

mm/damon/sysfs-schemes.c +4 -0

index 329cfd0bbe9f3..4b5429a5b4158 100644
@@ -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():

Quoted 7 lines

    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.

Quoted 47 lines · On Tue, 16 Jun 2026 22:35:21 +0300 Gutierrez Asier…

Quoted 44 lines · On 6/16/2026 6:21 PM, [email protected] 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 <[email protected]>

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.

mm/damon/sysfs-schemes.c struct damos_sysfs_qgoal_metric_name damos_sysfs_qgoal_metric_names[] = { · line 1273

Quoted 12 lines

mm/damon/sysfs-schemes.c +4 -0

index 329cfd0bbe9f3..4b5429a5b4158 100644
@@ -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():

Quoted 8 lines

Quoted 7 lines

    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

[...]

Hi SJ,

Quoted 65 lines · SeongJae Park

Quoted 47 lines · On Tue, 16 Jun 2026 22:35:21 +0300 Gutierrez Asier…

Quoted 44 lines · On 6/16/2026 6:21 PM, [email protected] 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 <[email protected]>

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.

mm/damon/sysfs-schemes.c struct damos_sysfs_qgoal_metric_name damos_sysfs_qgoal_metric_names[] = { · line 1273

Quoted 12 lines

mm/damon/sysfs-schemes.c +4 -0

index 329cfd0bbe9f3..4b5429a5b4158 100644
@@ -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():

Quoted 8 lines

Quoted 7 lines

    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

Quoted 2 lines

[...]

What I meant is the system already initialized after booting. The thing is that by the time the sysadmin sets up DAMON, vmstat should show at least some memory usage, not 0. That was my guess, but I may be wrong.

If my initial thought was wrong, I can just add a guard there.

Quoted 68 lines · On Wed, 15 Jul 2026 17:47:38 +0300 Gutierrez Asier…

Hi SJ,

Quoted 65 lines · SeongJae Park

Quoted 47 lines · On Tue, 16 Jun 2026 22:35:21 +0300 Gutierrez Asier…

Quoted 44 lines · On 6/16/2026 6:21 PM, [email protected] 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 <[email protected]>

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.

mm/damon/sysfs-schemes.c struct damos_sysfs_qgoal_metric_name damos_sysfs_qgoal_metric_names[] = { · line 1273

Quoted 12 lines

mm/damon/sysfs-schemes.c +4 -0

index 329cfd0bbe9f3..4b5429a5b4158 100644
@@ -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():

Quoted 8 lines

Quoted 7 lines

    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

Quoted 6 lines

Quoted 2 lines

[...]

What I meant is the system already initialized after booting. The thing is that by the time the sysadmin sets up DAMON, vmstat should show at least some memory usage, not 0. That was my guess, but I may be wrong.

I think that's a fair argument. And I also not quite sure. But having zero due to the races in per-CPU vmstat sounds possible in an extreme and weird lab environments.

Quoted 1 line

Quoted 1 line

If my initial thought was wrong, I can just add a guard there.

So I'm not really sure if you're wrong. But adding the guard would be simple. I'd recommend just adding the guard instead of get wrestle on this thoery for now. Does that make sense?

Thanks,
SJ

[...]

From: Asier Gutierrez <[email protected]>

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 <[email protected]>

From: Asier Gutierrez <[email protected]>

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

[1] https://dl.acm.org/doi/pdf/10.1145/3307650.3322227
[2] https://lore.kernel.org/[email protected]
[3] https://lore.kernel.org/[email protected]
[4] https://lore.kernel.org/[email protected]
[5] https://lore.kernel.org/[email protected]
[6] https://lore.kernel.org/[email protected]
[7] https://lore.kernel.org/[email protected]
[8] https://lore.kernel.org/[email protected]
[9] https://lore.kernel.org/all/[email protected]/

Quoted 16 lines · On Tue, 16 Jun 2026 15:03:13 +0000 <[email protected]> wrote:

From: Asier Gutierrez <[email protected]>

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.

Quoted 7 lines

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?

Quoted 28 lines

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.

Quoted 4 lines

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?

Quoted 4 lines

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

Quoted 2 lines

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.

Quoted 58 lines

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

Quoted 3 lines

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

Quoted 7 lines

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%)

Quoted 1 line

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?

Quoted 8 lines

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

Quoted 11 lines

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!

[...]

Quoted 9 lines

[1] https://dl.acm.org/doi/pdf/10.1145/3307650.3322227
[2] https://lore.kernel.org/[email protected]
[3] https://lore.kernel.org/[email protected]
[4] https://lore.kernel.org/[email protected]
[5] https://lore.kernel.org/[email protected]
[6] https://lore.kernel.org/[email protected]
[7] https://lore.kernel.org/[email protected]
[8] https://lore.kernel.org/[email protected]
[9] https://lore.kernel.org/all/[email protected]/

[1] https://lore.kernel.org/[email protected]

Thanks,
SJ

[...]

Hi SJ,

So sorry, I missed your email. I just found it. Sorry for the late answer.

Quoted 59 lines · SeongJae Park

Quoted 16 lines · On Tue, 16 Jun 2026 15:03:13 +0000 <[email protected]> wrote:

From: Asier Gutierrez <[email protected]>

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.

Quoted 7 lines

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?

Quoted 30 lines

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:

Quoted 6 lines

Quoted 2 lines

# 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?

Right, we agreed to change the name. I will correct it.

Quoted 8 lines

Quoted 4 lines

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

I actually set it to 500. I will update the cover letter.

Quoted 7 lines

Quoted 2 lines

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.

Actually, this is what I got using the TEMPORAL quota goals. With the regular quota goals, it actually over-achieves the goal.

Is this an actual bug in the TEMPORAL quota goal?

Quoted 62 lines

Quoted 61 lines

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.

Quoted 1 line

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

Memory fragmentation. I will add information about memory fragmentation in the next cover letter. >>

Quoted 7 lines

Quoted 7 lines

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%)

Quoted 5 lines

Quoted 1 line

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?

It's better than THP "never", but worse than THP "always". THP "always" is worse in terms of memory consumption, "always" is worse.

Quoted 37 lines

Quoted 8 lines

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

Quoted 11 lines

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!

[...]

Quoted 9 lines

[1] https://dl.acm.org/doi/pdf/10.1145/3307650.3322227
[2] https://lore.kernel.org/[email protected]
[3] https://lore.kernel.org/[email protected]
[4] https://lore.kernel.org/[email protected]
[5] https://lore.kernel.org/[email protected]
[6] https://lore.kernel.org/[email protected]
[7] https://lore.kernel.org/[email protected]
[8] https://lore.kernel.org/[email protected]
[9] https://lore.kernel.org/all/[email protected]/

[1] https://lore.kernel.org/[email protected]

Quoted 5 lines

Thanks,
SJ

[...]

SJ, once again, sorry for the late answer. Please, disregard my new patch set, I will fix it with your feedback.

Quoted 64 lines · On Sat, 20 Jun 2026 20:11:46 +0300 Gutierrez Asier…

Hi SJ,

So sorry, I missed your email. I just found it. Sorry for the late answer.

Quoted 59 lines · SeongJae Park

Quoted 16 lines · On Tue, 16 Jun 2026 15:03:13 +0000 <[email protected]> wrote:

From: Asier Gutierrez <[email protected]>

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.

Quoted 7 lines

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?

Quoted 30 lines

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:

Quoted 7 lines

Quoted 6 lines

Quoted 2 lines

# 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?

Right, we agreed to change the name. I will correct it.

Thank you. Because we agreed to drop the module, this could simply be dropped?

Quoted 8 lines

Quoted 8 lines

Quoted 4 lines

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

Quoted 1 line

I actually set it to 500. I will update the cover letter.

I think changes of this series is matured and very close to land. Discrepancies in the cover letter and commit messages are my concern that blocking this series. Please keep everything up to date and in high quality, from the next version.

Quoted 11 lines

Quoted 7 lines

Quoted 2 lines

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.

Actually, this is what I got using the TEMPORAL quota goals. With the regular quota goals, it actually over-achieves the goal.

Is this an actual bug in the TEMPORAL quota goal?

You mentioned "Since the database was not very big, we may not be able to ...". Based on that, I was assuming you will be able to make the goal achieved, by increasing the database size. Now you are saying about the goal.

Do you mean the database size is not expected to contributed to this result?

Of course TEMPORAL goal might have bugs. I find no clue from this datta, though. Do you have some evidences that make you suspect it? If so, could you please share?

Quoted 62 lines

Quoted 62 lines

Quoted 61 lines

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.

Quoted 3 lines

Quoted 1 line

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

Memory fragmentation. I will add information about memory fragmentation in the next cover letter. >>

Yes, please. Let's make the complete story of the benchmark.

Quoted 7 lines

Quoted 7 lines

Quoted 7 lines

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%)

Quoted 7 lines

Quoted 5 lines

Quoted 1 line

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?

It's better than THP "never", but worse than THP "always". THP "always" is worse in terms of memory consumption, "always" is worse.

I think it is arguable, but yes, please make the argument clear. We can discuss only after that.

Since we agreed to drop the module, you may need to do the benchmark again, using DAMON sysfs interface of 'damo'. I'd encourage 'damo' path. Extending it for ddamos_quota_hugepage_mem_bp should be easy. Let me know if you need my help.

Because the change is simple, I wouldn't request you to show clear performance benefit. But I want it to clearly show the functionality. That is, by applying the new feature, we should be able to show the hugepage memory ratio is controllable.

Quoted 37 lines

Quoted 37 lines

Quoted 8 lines

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

Quoted 11 lines

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!

[...]

Quoted 9 lines

[1] https://dl.acm.org/doi/pdf/10.1145/3307650.3322227
[2] https://lore.kernel.org/[email protected]
[3] https://lore.kernel.org/[email protected]
[4] https://lore.kernel.org/[email protected]
[5] https://lore.kernel.org/[email protected]
[6] https://lore.kernel.org/[email protected]
[7] https://lore.kernel.org/[email protected]
[8] https://lore.kernel.org/[email protected]
[9] https://lore.kernel.org/all/[email protected]/

[1] https://lore.kernel.org/[email protected]

Quoted 8 lines

Quoted 5 lines

Thanks,
SJ

[...]

SJ, once again, sorry for the late answer. Please, disregard my new patch set, I will fix it with your feedback.

No worries. Thank you for your grateful continued work on this.

Thanks,
SJ

[...]

Quoted 30 lines · SeongJae Park

Quoted 28 lines · On Sat, 20 Jun 2026 20:11:46 +0300 Gutierrez Asier…

Hi SJ,

So sorry, I missed your email. I just found it. Sorry for the late answer.

Quoted 23 lines · SeongJae Park

Quoted 21 lines · On Tue, 16 Jun 2026 15:03:13 +0000 <[email protected]> wrote:

From: Asier Gutierrez <[email protected]>

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.

Quoted 5 lines

Quoted 5 lines

Quoted 5 lines

Quoted 2 lines

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?

Quoted 34 lines

Quoted 34 lines

Quoted 34 lines

Quoted 33 lines

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

Quoted 6 lines

Quoted 4 lines

Quoted 3 lines

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?

Right, we agreed to change the name. I will correct it.

Thank you. Because we agreed to drop the module, this could simply be dropped?

Quoted 9 lines

Quoted 9 lines

Quoted 9 lines

Quoted 5 lines

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

Quoted 6 lines

Quoted 1 line

I actually set it to 500. I will update the cover letter.

I think changes of this series is matured and very close to land. Discrepancies in the cover letter and commit messages are my concern that blocking this series. Please keep everything up to date and in high quality, from the next version.

I will test it with a bigger database.

Quoted 16 lines

Quoted 11 lines

Quoted 7 lines

Quoted 2 lines

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.

Actually, this is what I got using the TEMPORAL quota goals. With the regular quota goals, it actually over-achieves the goal.

Is this an actual bug in the TEMPORAL quota goal?

You mentioned "Since the database was not very big, we may not be able to ...". Based on that, I was assuming you will be able to make the goal achieved, by increasing the database size. Now you are saying about the goal.

Quoted 5 lines

Do you mean the database size is not expected to contributed to this result?

Of course TEMPORAL goal might have bugs. I find no clue from this datta, though. Do you have some evidences that make you suspect it? If so, could you please share?

Quoted 63 lines

Quoted 63 lines

Quoted 63 lines

Quoted 62 lines

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.

Quoted 5 lines

Quoted 3 lines

Quoted 1 line

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

Memory fragmentation. I will add information about memory fragmentation in the next cover letter. >>

Yes, please. Let's make the complete story of the benchmark.

Quoted 24 lines

Quoted 8 lines

Quoted 8 lines

Quoted 8 lines

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%)

Quoted 7 lines

Quoted 5 lines

Quoted 1 line

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?

It's better than THP "never", but worse than THP "always". THP "always" is worse in terms of memory consumption, "always" is worse.

I think it is arguable, but yes, please make the argument clear. We can discuss only after that.

Since we agreed to drop the module, you may need to do the benchmark again, using DAMON sysfs interface of 'damo'. I'd encourage 'damo' path. Extending it for ddamos_quota_hugepage_mem_bp should be easy. Let me know if you need my help.

Quoted 4 lines

Because the change is simple, I wouldn't request you to show clear performance benefit. But I want it to clearly show the functionality. That is, by applying the new feature, we should be able to show the hugepage memory ratio is controllable.

I agree. I will start testing manually through sysfs first. Once it works, I will fork damo, make small changes to support the functionality and provide all the details in the cover letter using damo.

Quoted 46 lines

Quoted 45 lines

Quoted 34 lines

Quoted 8 lines

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

Quoted 11 lines

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!

[...]

Quoted 9 lines

[1] https://dl.acm.org/doi/pdf/10.1145/3307650.3322227
[2] https://lore.kernel.org/[email protected]
[3] https://lore.kernel.org/[email protected]
[4] https://lore.kernel.org/[email protected]
[5] https://lore.kernel.org/[email protected]
[6] https://lore.kernel.org/[email protected]
[7] https://lore.kernel.org/[email protected]
[8] https://lore.kernel.org/[email protected]
[9] https://lore.kernel.org/all/[email protected]/

Quoted 8 lines

[1] https://lore.kernel.org/[email protected]

Thanks,
SJ

[...]

SJ, once again, sorry for the late answer. Please, disregard my new patch set, I will fix it with your feedback.

Quoted 8 lines

No worries. Thank you for your grateful continued work on this.

Thanks,
SJ

[...]

Signature · 2 lines

Asier Gutierrez
Huawei

Hello Gutierrez,

Thank you for your replies. I still find some of my comments are not replied, acknowledged or objected. Could you please address those all before the next revision?

Quoted 33 lines · On Tue, 7 Jul 2026 16:31:03 +0300 Gutierrez Asier…

Quoted 30 lines · SeongJae Park

Quoted 28 lines · On Sat, 20 Jun 2026 20:11:46 +0300 Gutierrez Asier…

Hi SJ,

So sorry, I missed your email. I just found it. Sorry for the late answer.

Quoted 23 lines · SeongJae Park

Quoted 21 lines · On Tue, 16 Jun 2026 15:03:13 +0000 <[email protected]> wrote:

From: Asier Gutierrez <[email protected]>

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.

Quoted 5 lines

Quoted 5 lines

Quoted 5 lines

Quoted 5 lines

Quoted 2 lines

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?

WDYT?

Quoted 34 lines

Quoted 34 lines

Quoted 34 lines

Quoted 34 lines

Quoted 33 lines

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

Quoted 6 lines

Quoted 6 lines

Quoted 4 lines

Quoted 3 lines

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?

Right, we agreed to change the name. I will correct it.

Thank you. Because we agreed to drop the module, this could simply be dropped?

WDYT?

Quoted 11 lines

Quoted 11 lines

Quoted 10 lines

Quoted 9 lines

Quoted 5 lines

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

I actually set it to 500. I will update the cover letter.

Quoted 5 lines

Quoted 4 lines

I think changes of this series is matured and very close to land. Discrepancies in the cover letter and commit messages are my concern that blocking this series. Please keep everything up to date and in high quality, from the next version.

I will test it with a bigger database.

Thank you. Couuld you further clarify what you expect to see as the result, and how it will complete the story?

Quoted 16 lines

Quoted 16 lines

Quoted 11 lines

Quoted 7 lines

Quoted 2 lines

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.

Actually, this is what I got using the TEMPORAL quota goals. With the regular quota goals, it actually over-achieves the goal.

Is this an actual bug in the TEMPORAL quota goal?

You mentioned "Since the database was not very big, we may not be able to ...". Based on that, I was assuming you will be able to make the goal achieved, by increasing the database size. Now you are saying about the goal.

Quoted 5 lines

Quoted 5 lines

Do you mean the database size is not expected to contributed to this result?

Of course TEMPORAL goal might have bugs. I find no clue from this datta, though. Do you have some evidences that make you suspect it? If so, could you please share?

WDYT?

Quoted 67 lines

Quoted 67 lines

Quoted 66 lines

Quoted 63 lines

Quoted 59 lines

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

Quoted 3 lines

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.

Quoted 1 line

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

Memory fragmentation. I will add information about memory fragmentation in the next cover letter. >>

Quoted 1 line

Quoted 1 line

Yes, please. Let's make the complete story of the benchmark.

I'd like to again call out I'd like to show "complete story". I don't think additional data points that look interesting but not providing a complete story is really adding much values to this work.

If you want my feedback on benchmark results first, sending benchmark results (with your analysis an discussions) without the code change could be an option.

Quoted 24 lines

Quoted 24 lines

Quoted 8 lines

Quoted 8 lines

Quoted 8 lines

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%)

Quoted 7 lines

Quoted 5 lines

Quoted 1 line

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?

It's better than THP "never", but worse than THP "always". THP "always" is worse in terms of memory consumption, "always" is worse.

I think it is arguable, but yes, please make the argument clear. We can discuss only after that.

Since we agreed to drop the module, you may need to do the benchmark again, using DAMON sysfs interface of 'damo'. I'd encourage 'damo' path. Extending it for ddamos_quota_hugepage_mem_bp should be easy. Let me know if you need my help.

Quoted 7 lines

Quoted 4 lines

Because the change is simple, I wouldn't request you to show clear performance benefit. But I want it to clearly show the functionality. That is, by applying the new feature, we should be able to show the hugepage memory ratio is controllable.

I agree. I will start testing manually through sysfs first. Once it works, I will fork damo, make small changes to support the functionality and provide all the details in the cover letter using damo.

For the damo side change, you could refer to this:
https://github.com/damonitor/damo/commit/8b3fc4a55ead

Quoted 46 lines

Quoted 46 lines

Quoted 45 lines

Quoted 34 lines

Quoted 8 lines

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

Quoted 11 lines

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!

[...]

Quoted 9 lines

[1] https://dl.acm.org/doi/pdf/10.1145/3307650.3322227
[2] https://lore.kernel.org/[email protected]
[3] https://lore.kernel.org/[email protected]
[4] https://lore.kernel.org/[email protected]
[5] https://lore.kernel.org/[email protected]
[6] https://lore.kernel.org/[email protected]
[7] https://lore.kernel.org/[email protected]
[8] https://lore.kernel.org/[email protected]
[9] https://lore.kernel.org/all/[email protected]/

Quoted 8 lines

[1] https://lore.kernel.org/[email protected]

Thanks,
SJ

[...]

SJ, once again, sorry for the late answer. Please, disregard my new patch set, I will fix it with your feedback.

Quoted 12 lines

Quoted 8 lines

No worries. Thank you for your grateful continued work on this.

Thanks,
SJ

[...]

Signature · 2 lines

Asier Gutierrez
Huawei

Thanks,
SJ

Quoted 45 lines · SJ Park

Hello Gutierrez,

Thank you for your replies. I still find some of my comments are not replied, acknowledged or objected. Could you please address those all before the next revision?

Quoted 36 lines · On Tue, 7 Jul 2026 16:31:03 +0300 Gutierrez Asier…

Quoted 33 lines · SeongJae Park

Quoted 31 lines · On Sat, 20 Jun 2026 20:11:46 +0300 Gutierrez Asier…

Hi SJ,

So sorry, I missed your email. I just found it. Sorry for the late answer.

Quoted 26 lines · SeongJae Park

Quoted 23 lines · On Tue, 16 Jun 2026 15:03:13 +0000 <[email protected]> wrote:

From: Asier Gutierrez <[email protected]>

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.

Quoted 4 lines

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

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

WDYT?

Yes, we can use prctl. However, I believe DAMON is more transparent and easier for a sysadmin. I will rephrase this sentence to explain why DAMON makes sense instead of other alternative.

Quoted 14 lines

Quoted 14 lines

Quoted 14 lines

Quoted 14 lines

Quoted 14 lines

Quoted 10 lines

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?

Quoted 5 lines

Quoted 3 lines

Quoted 3 lines

Quoted 1 line

Right, we agreed to change the name. I will correct it.

Thank you. Because we agreed to drop the module, this could simply be dropped?

WDYT?

Yes, I will drop it. The new patch set will not include any of these parameters, but just the target value for the quota and a new quota metric.

Quoted 15 lines

Quoted 15 lines

Quoted 15 lines

Quoted 10 lines

Quoted 9 lines

Quoted 5 lines

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

I actually set it to 500. I will update the cover letter.

I think changes of this series is matured and very close to land. Discrepancies in the cover letter and commit messages are my concern that blocking this series. Please keep everything up to date and in high quality, from the next version.

Quoted 4 lines

Quoted 1 line

I will test it with a bigger database.

Thank you. Couuld you further clarify what you expect to see as the result, and how it will complete the story?

What I expect is DAMON to keep consistent huge page usage to total memory usage ration according to the target value.

Should I publish these results as well? I mean showing different target values and the actually achieved values. And theses results for different database sizes.

Quoted 18 lines

Quoted 18 lines

Quoted 18 lines

Quoted 11 lines

Quoted 7 lines

Quoted 2 lines

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.

Actually, this is what I got using the TEMPORAL quota goals. With the regular quota goals, it actually over-achieves the goal.

Is this an actual bug in the TEMPORAL quota goal?

You mentioned "Since the database was not very big, we may not be able to ...". Based on that, I was assuming you will be able to make the goal achieved, by increasing the database size. Now you are saying about the goal.

Do you mean the database size is not expected to contributed to this result?

Quoted 5 lines

Quoted 3 lines

Quoted 3 lines

Of course TEMPORAL goal might have bugs. I find no clue from this datta, though. Do you have some evidences that make you suspect it? If so, could you please share?

WDYT?

I have no idea, to be honest. I will try to test with different databasesizes with temporal and consistent policies. The behaviour was weird to me, but I don't know if this was a TEMPORAL policy issue or I didn't set the
DAMON parameters correctly.

Quoted 70 lines

Quoted 69 lines

Quoted 69 lines

Quoted 64 lines

Quoted 64 lines

Quoted 63 lines

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.

Quoted 3 lines

Quoted 1 line

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

Memory fragmentation. I will add information about memory fragmentation in the next cover letter. >>

Yes, please. Let's make the complete story of the benchmark.

Quoted 6 lines

I'd like to again call out I'd like to show "complete story". I don't think additional data points that look interesting but not providing a complete story is really adding much values to this work.

If you want my feedback on benchmark results first, sending benchmark results (with your analysis an discussions) without the code change could be an option.

That makes sense. Maybe I will just reply for now on to get your thoughts.

Quoted 48 lines · On Tue, 7 Jul 2026 17:25:36 +0300 Gutierrez Asier…

Quoted 45 lines · SJ Park

Hello Gutierrez,

Thank you for your replies. I still find some of my comments are not replied, acknowledged or objected. Could you please address those all before the next revision?

Quoted 36 lines · On Tue, 7 Jul 2026 16:31:03 +0300 Gutierrez Asier…

Quoted 33 lines · SeongJae Park

Quoted 31 lines · On Sat, 20 Jun 2026 20:11:46 +0300 Gutierrez Asier…

Hi SJ,

So sorry, I missed your email. I just found it. Sorry for the late answer.

Quoted 26 lines · SeongJae Park

Quoted 23 lines · On Tue, 16 Jun 2026 15:03:13 +0000 <[email protected]> wrote:

From: Asier Gutierrez <[email protected]>

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.

Quoted 7 lines

Quoted 4 lines

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

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

WDYT?

Yes, we can use prctl. However, I believe DAMON is more transparent and easier for a sysadmin. I will rephrase this sentence to explain why DAMON makes sense instead of other alternative.

Thank you, I agree to you. But I just want the pointer be clear. Your revision plan soudns like a good plan.

[...]

Quoted 14 lines

Quoted 14 lines

Quoted 14 lines

Quoted 14 lines

Quoted 14 lines

Quoted 14 lines

Quoted 10 lines

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?

Quoted 7 lines

Quoted 5 lines

Quoted 3 lines

Quoted 3 lines

Quoted 1 line

Right, we agreed to change the name. I will correct it.

Thank you. Because we agreed to drop the module, this could simply be dropped?

WDYT?

Yes, I will drop it. The new patch set will not include any of these parameters, but just the target value for the quota and a new quota metric.

Thank you, sounds like a good revision plan.

Quoted 15 lines

Quoted 15 lines

Quoted 15 lines

Quoted 15 lines

Quoted 10 lines

Quoted 9 lines

Quoted 5 lines

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

I actually set it to 500. I will update the cover letter.

I think changes of this series is matured and very close to land. Discrepancies in the cover letter and commit messages are my concern that blocking this series. Please keep everything up to date and in high quality, from the next version.

Quoted 6 lines

Quoted 4 lines

Quoted 1 line

I will test it with a bigger database.

Thank you. Couuld you further clarify what you expect to see as the result, and how it will complete the story?

What I expect is DAMON to keep consistent huge page usage to total memory usage ration according to the target value.

Makes sense, as long as we have a sound theory. But, I'm not sure if we really have such theory. Please read my comment below for why I'm not really sure.

Quoted 4 lines

Should I publish these results as well? I mean showing different target values and the actually achieved values. And theses results for different database sizes.

Feel free to add as much data as you want to show. Nonetheless, I'd recommend adding only data that gives us clear story in a condensed way. The data on the cover letter will live forever in the git history. Let's not make it unnecessarily long.

If you want to share your findings in volume for discussions, please feel free to share. But not necessarily it should be the part of the permanent history. You can send it as a mail without the code diff. Sending that as a reply to the patch series could also be a good option.

Quoted 18 lines

Quoted 18 lines

Quoted 18 lines

Quoted 18 lines

Quoted 11 lines

Quoted 7 lines

Quoted 2 lines

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.

Actually, this is what I got using the TEMPORAL quota goals. With the regular quota goals, it actually over-achieves the goal.

Is this an actual bug in the TEMPORAL quota goal?

You mentioned "Since the database was not very big, we may not be able to ...". Based on that, I was assuming you will be able to make the goal achieved, by increasing the database size. Now you are saying about the goal.

Do you mean the database size is not expected to contributed to this result?

Quoted 8 lines

Quoted 5 lines

Quoted 3 lines

Quoted 3 lines

Of course TEMPORAL goal might have bugs. I find no clue from this datta, though. Do you have some evidences that make you suspect it? If so, could you please share?

WDYT?

I have no idea, to be honest. I will try to test with different databasesizes with temporal and consistent policies. The behaviour was weird to me, but I don't know if this was a TEMPORAL policy issue or I didn't set the
DAMON parameters correctly.

Thank you for transparently sharing your thought. And this is little bit concerning me. It feels like we don't really have a good theory about what change will make what results for what reason. It rather feels like we just doing random experiments and showing the random results.

I understand having data first and developing the theory driven by data is also a good approach. But I feel like this is a time to step back and think about what we're doing.

IIRC, your initial experiment results on the very early version of this series looked promising. But from a point, it looked like just random. Maybe I gave you wrong change request, or some test environment has unexpectedly changed.

How about summarizing what tests you did so far, what changes in the kernel and the test setup has made for each iteration, and how the results have changed?

If it has been too long since the older tests, just doing the tests again or dive deep into debugging of your current setup with the all mighty printk() on core DAMON internall code can be an option.

Have you also monitored DAMOS stats while the tests are ongoing? Maybe that could also be a good debugging option for understanding what's going on as expected vs not.

Quoted 70 lines

Quoted 70 lines

Quoted 69 lines

Quoted 69 lines

Quoted 64 lines

Quoted 64 lines

Quoted 63 lines

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.

Quoted 3 lines

Quoted 1 line

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

Memory fragmentation. I will add information about memory fragmentation in the next cover letter. >>

Yes, please. Let's make the complete story of the benchmark.

Quoted 7 lines

Quoted 6 lines

I'd like to again call out I'd like to show "complete story". I don't think additional data points that look interesting but not providing a complete story is really adding much values to this work.

If you want my feedback on benchmark results first, sending benchmark results (with your analysis an discussions) without the code change could be an option.

That makes sense. Maybe I will just reply for now on to get your thoughts.

I suggested to take step back and look back what we tested so far to get a better idea on theory. But, yes, adding even more data shouldn't harm us. Please feel free to share your findings.

Thank you for replying to all my comments. To recap, let's keep discussing about the test.

Thanks,
SJ

[...]

Hi SJ,

Quoted 1 line · SJ Park

On Tue, 7 Jul 2026 17:25:36 +0300 Gutierrez Asier <[email protected]> wrote:

Quoted 24 lines

Quoted 3 lines

I have no idea, to be honest. I will try to test with different databasesizes with temporal and consistent policies. The behaviour was weird to me, but I don't know if this was a TEMPORAL policy issue or I didn't set the
DAMON parameters correctly.

Thank you for transparently sharing your thought. And this is little bit concerning me. It feels like we don't really have a good theory about what change will make what results for what reason. It rather feels like we just doing random experiments and showing the random results.

I understand having data first and developing the theory driven by data is also a good approach. But I feel like this is a time to step back and think about what we're doing.

IIRC, your initial experiment results on the very early version of this series looked promising. But from a point, it looked like just random. Maybe I gave you wrong change request, or some test environment has unexpectedly changed.

How about summarizing what tests you did so far, what changes in the kernel and the test setup has made for each iteration, and how the results have changed?

If it has been too long since the older tests, just doing the tests again or dive deep into debugging of your current setup with the all mighty printk() on core DAMON internall code can be an option.

Quoted 3 lines

Have you also monitored DAMOS stats while the tests are ongoing? Maybe that could also be a good debugging option for understanding what's going on as expected vs not.

The problem I've been having is inconsistent results. This may be due to thefact that I'm testing primarily with database, which contains a lot of variable data, like indexes that may be hit sometimes, and other times not,
different data distribution, etc.

I've been trying to get a test as consistent as possible, pinning the database to a single NUMA node and the tests script to another one, avoid network traffic, etc.

I am almost done getting some consistent data.

Maybe I can use perf to get DAMOS tracing. Would that make it?

Thanks to you. I will keep testing and keep you posted in the coming days.

Hi SJ,

So sorry, I missed your email. I just found it. Sorry for the late answer.

Quoted 57 lines · SeongJae Park

Quoted 16 lines · On Tue, 16 Jun 2026 15:03:13 +0000 <[email protected]> wrote:

From: Asier Gutierrez <[email protected]>

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.

Quoted 7 lines

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?

Quoted 28 lines

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.

Quoted 8 lines

Quoted 4 lines

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?

Right, we agreed to change the name. I will correct it.

Quoted 8 lines

Quoted 4 lines

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

I actually set it to 500. I will update the cover letter.

Quoted 7 lines

Quoted 2 lines

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.

Actually, this is what I got using the TEMPORAL quota goals. With the regular quota goals, it actually over-achieves the goal.

Is this an actual bug in the TEMPORAL quota goal?

Quoted 62 lines

Quoted 58 lines

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

Quoted 3 lines

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.

Quoted 1 line

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

Memory fragmentation. I will add information about memory fragmentation in the next cover letter. >>

Quoted 7 lines

Quoted 7 lines

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%)

Quoted 5 lines

Quoted 1 line

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?

It's better than THP "never", but worse than THP "always". THP "always" is worse in terms of memory consumption, "always" is worse.

Quoted 37 lines

Quoted 8 lines

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

Quoted 11 lines

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!

[...]

Quoted 9 lines

[1] https://dl.acm.org/doi/pdf/10.1145/3307650.3322227
[2] https://lore.kernel.org/[email protected]
[3] https://lore.kernel.org/[email protected]
[4] https://lore.kernel.org/[email protected]
[5] https://lore.kernel.org/[email protected]
[6] https://lore.kernel.org/[email protected]
[7] https://lore.kernel.org/[email protected]
[8] https://lore.kernel.org/[email protected]
[9] https://lore.kernel.org/all/[email protected]/

[1] https://lore.kernel.org/[email protected]

Quoted 5 lines

Thanks,
SJ

[...]

SJ, once again, sorry for the late answer. Please, disregard my new patch set, I will fix it with your feedback.

Hi SJ,

Quoted 210 lines · Gutierrez Asier

Hi SJ,

So sorry, I missed your email. I just found it. Sorry for the late answer.

Quoted 57 lines · SeongJae Park

Quoted 16 lines · On Tue, 16 Jun 2026 15:03:13 +0000 <[email protected]> wrote:

From: Asier Gutierrez <[email protected]>

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.

Quoted 7 lines

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?

Quoted 28 lines

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.

Quoted 8 lines

Quoted 4 lines

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?

Right, we agreed to change the name. I will correct it.

Quoted 8 lines

Quoted 4 lines

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

I actually set it to 500. I will update the cover letter.

Quoted 7 lines

Quoted 2 lines

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.

Actually, this is what I got using the TEMPORAL quota goals. With the regular quota goals, it actually over-achieves the goal.

Is this an actual bug in the TEMPORAL quota goal?

Quoted 62 lines

Quoted 58 lines

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

Quoted 3 lines

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.

Quoted 1 line

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

Memory fragmentation. I will add information about memory fragmentation in the next cover letter. >>

Quoted 7 lines

Quoted 7 lines

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%)

Quoted 5 lines

Quoted 1 line

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?

It's better than THP "never", but worse than THP "always". THP "always" is worse in terms of memory consumption, "always" is worse.

Quoted 40 lines

Quoted 8 lines

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

Quoted 11 lines

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!

[...]

Quoted 9 lines

[1] https://dl.acm.org/doi/pdf/10.1145/3307650.3322227
[2] https://lore.kernel.org/[email protected]
[3] https://lore.kernel.org/[email protected]
[4] https://lore.kernel.org/[email protected]
[5] https://lore.kernel.org/[email protected]
[6] https://lore.kernel.org/[email protected]
[7] https://lore.kernel.org/[email protected]
[8] https://lore.kernel.org/[email protected]
[9] https://lore.kernel.org/all/[email protected]/

[1] https://lore.kernel.org/[email protected]

Thanks,
SJ

Quoted 6 lines

Quoted 2 lines

[...]

SJ, once again, sorry for the late answer. Please, disregard my new patch set, I will fix it with your feedback.

I didn't get a reply to this email.

I will update the cover letter and submit a new patch set soon.

Quoted 213 lines · On Mon, 6 Jul 2026 18:03:03 +0300 Gutierrez Asier…

Hi SJ,

Quoted 210 lines · Gutierrez Asier

Hi SJ,

So sorry, I missed your email. I just found it. Sorry for the late answer.

Quoted 57 lines · SeongJae Park

Quoted 16 lines · On Tue, 16 Jun 2026 15:03:13 +0000 <[email protected]> wrote:

From: Asier Gutierrez <[email protected]>

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.

Quoted 7 lines

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?

Quoted 28 lines

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.

Quoted 8 lines

Quoted 4 lines

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?

Right, we agreed to change the name. I will correct it.

Quoted 8 lines

Quoted 4 lines

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

I actually set it to 500. I will update the cover letter.

Quoted 7 lines

Quoted 2 lines

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.

Actually, this is what I got using the TEMPORAL quota goals. With the regular quota goals, it actually over-achieves the goal.

Is this an actual bug in the TEMPORAL quota goal?

Quoted 62 lines

Quoted 58 lines

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

Quoted 3 lines

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.

Quoted 1 line

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

Memory fragmentation. I will add information about memory fragmentation in the next cover letter. >>

Quoted 7 lines

Quoted 7 lines

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%)

Quoted 5 lines

Quoted 1 line

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?

It's better than THP "never", but worse than THP "always". THP "always" is worse in terms of memory consumption, "always" is worse.

Quoted 40 lines

Quoted 8 lines

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

Quoted 11 lines

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!

[...]

Quoted 9 lines

[1] https://dl.acm.org/doi/pdf/10.1145/3307650.3322227
[2] https://lore.kernel.org/[email protected]
[3] https://lore.kernel.org/[email protected]
[4] https://lore.kernel.org/[email protected]
[5] https://lore.kernel.org/[email protected]
[6] https://lore.kernel.org/[email protected]
[7] https://lore.kernel.org/[email protected]
[8] https://lore.kernel.org/[email protected]
[9] https://lore.kernel.org/all/[email protected]/

[1] https://lore.kernel.org/[email protected]

Thanks,
SJ

Quoted 8 lines

Quoted 6 lines

Quoted 2 lines

[...]

SJ, once again, sorry for the late answer. Please, disregard my new patch set, I will fix it with your feedback.

I didn't get a reply to this email.

I sent the reply [1] weeks ago.

Quoted 2 lines

I will update the cover letter and submit a new patch set soon.

No, please. Let's fully complete the discussion before a new version.

[1] https://lore.kernel.org/[email protected]

Thanks,
SJ

[...]

Hi SJ,

Quoted 231 lines · SJ Park

Quoted 213 lines · On Mon, 6 Jul 2026 18:03:03 +0300 Gutierrez Asier…

Hi SJ,

Quoted 210 lines · Gutierrez Asier

Hi SJ,

So sorry, I missed your email. I just found it. Sorry for the late answer.

Quoted 57 lines · SeongJae Park

Quoted 16 lines · On Tue, 16 Jun 2026 15:03:13 +0000 <[email protected]> wrote:

From: Asier Gutierrez <[email protected]>

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.

Quoted 7 lines

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?

Quoted 28 lines

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.

Quoted 8 lines

Quoted 4 lines

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?

Right, we agreed to change the name. I will correct it.

Quoted 8 lines

Quoted 4 lines

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

I actually set it to 500. I will update the cover letter.

Quoted 7 lines

Quoted 2 lines

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.

Actually, this is what I got using the TEMPORAL quota goals. With the regular quota goals, it actually over-achieves the goal.

Is this an actual bug in the TEMPORAL quota goal?

Quoted 62 lines

Quoted 58 lines

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

Quoted 3 lines

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.

Quoted 1 line

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

Memory fragmentation. I will add information about memory fragmentation in the next cover letter. >>

Quoted 7 lines

Quoted 7 lines

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%)

Quoted 5 lines

Quoted 1 line

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?

It's better than THP "never", but worse than THP "always". THP "always" is worse in terms of memory consumption, "always" is worse.

Quoted 40 lines

Quoted 8 lines

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

Quoted 11 lines

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!

[...]

Quoted 9 lines

[1] https://dl.acm.org/doi/pdf/10.1145/3307650.3322227
[2] https://lore.kernel.org/[email protected]
[3] https://lore.kernel.org/[email protected]
[4] https://lore.kernel.org/[email protected]
[5] https://lore.kernel.org/[email protected]
[6] https://lore.kernel.org/[email protected]
[7] https://lore.kernel.org/[email protected]
[8] https://lore.kernel.org/[email protected]
[9] https://lore.kernel.org/all/[email protected]/

[1] https://lore.kernel.org/[email protected]

Thanks,
SJ

Quoted 8 lines

Quoted 6 lines

Quoted 2 lines

[...]

SJ, once again, sorry for the late answer. Please, disregard my new patch set, I will fix it with your feedback.

I didn't get a reply to this email.

I sent the reply [1] weeks ago.

Quoted 2 lines

I will update the cover letter and submit a new patch set soon.

No, please. Let's fully complete the discussion before a new version.

Quoted 7 lines

[1] https://lore.kernel.org/[email protected]

Thanks,
SJ

[...]

Hi SJ,

So, I finally got some stable results which make sense now.

Setup: physical server with arm64 processor with 4 NUMA nodes, 1 TB RAM and running mariaDB 10.5.29. I use sysbench for the benchmark, with 20 tables and 3 million rows per table. The database was pinned to one of the nodes, and the benchmark framework to a different node. No network traffic involved in the benchmark.

I forked damo and added hugepage_mem_bp support[1].

I launch DAMON using this command line:

sudo ./damo start $(pidof mariadbd) \
--monitoring_nr_regions_range 10 1000 \
--monitoring_intervals 5000 100000 60000000 \
--damos_quota_time 0 --damos_quota_space 128000000 \
--damos_quota_interval 1000 \
--damos_quota_weights 0 1 1 \
--damos_quota_goal hugepage_mem_bp <target> \
--damos_quota_goal_tuner temporal \
--damos_apply_interval 50000 \

--damos_access_rate 0 max --damos_age 50 max \
--damos_action collapse --debug_damon

<target> was 1000 to taget 10% hugepage to total memory ratio, or 2500 to target 25%. Tuner was also tested with consistent and temporal.

Results
=======
After the last timestamp, there was no change in huge page use, and the total huge page to memory consumption ratio barely moved.

Timestamp is measured in seconds, and the memory consumption (total and huge page) is in MB.

hugepage_mem_bp: 1000
goal tuner: temporal

+-----------+----------------+----------------+----------------------+
| timestamp | total mem used | huge page used | percentage hugepage  |
+-----------+----------------+----------------+----------------------+
| 0         | 16945.04297    | 0              | 0                    |
| 7         | 17008.69531    | 74             | 0.435071583          |
| 8         | 17036.40234    | 194            | 1.138738074          |
| 9         | 17017.01563    | 314            | 1.845211916          |
| 10        | 17029.67969    | 434            | 2.548491856          |
| 61        | 17111.30859    | 584            | 3.412947623          |
| 75        | 17068.51953    | 612            | 3.58554823           |
| 90        | 17098.84766    | 638            | 3.731245595          |
| 105       | 17076.32031    | 664            | 3.888425538          |
| 120       | 17071.05859    | 694            | 4.065360072          |
| 135       | 17088.94531    | 722            | 4.22495354           |
| 150       | 17101.42578    | 746            | 4.362209383          |
| 165       | 17097.33984    | 776            | 4.53871776           |
| 180       | 17133.88281    | 804            | 4.692456513          |
| 195       | 17099.12891    | 832            | 4.865744943          |
| 201       | 17103.5        | 852            | 4.981436548          |
| 202       | 17077.84375    | 862            | 5.047475622          |
| 203       | 17088.16406    | 916            | 5.360435426          |

| 204       | 17126.34766    | 1046           | 6.107548562          |
| 205       | 17093.84375    | 1176           | 6.879669764          |
| 206       | 17142.77734    | 1298           | 7.571701913          |
| 207       | 17129.86719    | 1428           | 8.336316822          |
| 208       | 17099.76953    | 1556           | 9.099537846          |
| 209       | 17149.17969    | 1686           | 9.831374041          |
| 210       | 17097.30859    | 1754           | 10.25892462          |
+-----------+----------------+----------------+----------------------+

hugepage_mem_bp: 1000
goal tuner: consistent

+-----------+----------------+----------------+----------------------+
| timestamp | total mem used | huge page used | percentage hugepage  |
+-----------+----------------+----------------+----------------------+
| 0         | 16955.24609    | 0              | 0                    |
| 34        | 17039.71875    | 106            | 0.622075995          |
| 35        | 17022.21875    | 224            | 1.315927161          |
| 36        | 17070.08594    | 344            | 2.015221255          |
| 37        | 17005.86719    | 464            | 2.728470091          |
| 38        | 17028.92188    | 542            | 3.182820404          |
| 78        | 17009.47656    | 554            | 3.257007927          |
| 79        | 17051.82031    | 572            | 3.354480575          |
| 90        | 17048.92188    | 596            | 3.495822225          |
| 105       | 17086.22656    | 624            | 3.652064414          |
| 120       | 17102.49609    | 654            | 3.824003212          |
| 135       | 17081.31641    | 680            | 3.980957813          |
| 150       | 17092.90625    | 706            | 4.130368409          |
| 165       | 17093.69531    | 736            | 4.305681051          |
| 180       | 17053.08984    | 764            | 4.480126517          |
| 195       | 17095.73047    | 788            | 4.609337995          |
| 210       | 17086.20703    | 818            | 4.787487349          |
| 225       | 17095.04297    | 846            | 4.948803004          |
| 226       | 17057.95703    | 848            | 4.971286998          |
| 227       | 17101.46484    | 858            | 5.017114077          |
| 228       | 17053.90625    | 896            | 5.253928261          |
| 229       | 17061.48047    | 1016           | 5.954934578          |
| 230       | 17097.48828    | 1136           | 6.644250789          |
| 231       | 17080.42188    | 1256           | 7.353448347          |
| 232       | 17118.92969    | 1376           | 8.037885692          |
| 233       | 17100.50391    | 1496           | 8.748280216          |
| 234       | 17110.80859    | 1616           | 9.444322816          |
| 235       | 17138.17188    | 1736           | 10.12943512          |
| 236       | 17060.17578    | 1856           | 10.87913761          |
| 237       | 17118.92578    | 1976           | 11.54278034          |
| 238       | 17119.28516    | 2096           | 12.24350188          |
| 239       | 17098.89063    | 2216           | 12.95990511          |
| 240       | 17135.44531    | 2334           | 13.62088908          |
| 241       | 17097.58594    | 2454           | 14.35290344          |
| 242       | 17134.69531    | 2574           | 15.02215215          |
| 243       | 17127.96094    | 2694           | 15.72866735          |

| 244       | 17097.53516    | 2812           | 16.44681514          |
| 245       | 17132.55078    | 2932           | 17.11362212          |
| 246       | 17117.95313    | 3052           | 17.82923448          |
| 247       | 17154.30469    | 3172           | 18.49098554          |
| 248       | 17145.55078    | 3292           | 19.20031641          |
| 249       | 17138.36719    | 3410           | 19.89687794          |
| 250       | 17163.12109    | 3532           | 20.57900763          |
+-----------+----------------+----------------+----------------------+

hugepage_mem_bp: 2500
goal tuner: temporal

+-----------+----------------+----------------+----------------------+
| timestamp | total mem used | huge page used | percentage hugepage  |
+-----------+----------------+----------------+----------------------+
| 0         | 17010.31641    | 0              | 0                    |
| 9         | 17063.6875     | 50             | 0.2930199            |
| 10        | 17051.75781    | 170            | 0.996964664          |
| 11        | 17059.625      | 290            | 1.699920133          |
| 12        | 17053.72656    | 410            | 2.404166611          |
| 13        | 17082.44141    | 528            | 3.090893084          |
| 14        | 17097.22266    | 530            | 3.099918687          |
| 60        | 17133.85547    | 572            | 3.338419663          |
| 75        | 17149.26563    | 598            | 3.487029784          |
| 90        | 17192.07813    | 626            | 3.641211932          |
| 105       | 17196.34766    | 654            | 3.80313316           |
| 120       | 17221.44531    | 682            | 3.960178647          |
| 135       | 17225.36719    | 708            | 4.110217172          |
| 150       | 17220.15625    | 736            | 4.274061102          |
| 165       | 17223.66406    | 764            | 4.435757672          |
| 181       | 17199.76172    | 790            | 4.593086886          |
| 195       | 17139.11328    | 818            | 4.772708988          |
| 205       | 17185.85547    | 862            | 5.015752644          |
| 206       | 17228.63281    | 978            | 5.67659669           |
| 207       | 17194.80469    | 1094           | 6.362386895          |
| 208       | 17222.77734    | 1206           | 7.002354939          |
| 209       | 17177.09766    | 1320           | 7.68465096           |
| 210       | 17182.23828    | 1428           | 8.310907907          |
| 211       | 17196.77734    | 1542           | 8.966796332          |
| 212       | 17205.57031    | 1664           | 9.671286507          |
| 213       | 17227.39844    | 1784           | 10.35559726          |
| 214       | 17245.17969    | 1904           | 11.04076637          |
| 215       | 17240.45703    | 2024           | 11.73982799          |
| 216       | 17218.85156    | 2144           | 12.45146921          |
| 217       | 17183.63281    | 2264           | 13.17532809          |
| 218       | 17217.08984    | 2384           | 13.84670709          |
| 219       | 17176.72266    | 2504           | 14.57786826          |
| 220       | 17234.79688    | 2624           | 15.22501262          |
| 221       | 17221.20703    | 2744           | 15.93384247          |
| 222       | 17258.91016    | 2864           | 16.59432707          |
| 223       | 17248.64063    | 2984           | 17.29991403          |
| 224       | 17227.35156    | 3104           | 18.0178595           |
| 225       | 17194.83594    | 3224           | 18.74981542          |
| 226       | 17216.30078    | 3344           | 19.42345247          |
| 227       | 17205.71875    | 3464           | 20.13284101          |
| 228       | 17222.83594    | 3584           | 20.80958103          |

| 229       | 17232.32031    | 3704           | 21.49449368          |
| 230       | 17269.49219    | 3824           | 22.14309465          |
| 231       | 17247.55469    | 3944           | 22.86700968          |
| 232       | 17248.90234    | 4064           | 23.56091952          |
| 233       | 17229.21875    | 4184           | 24.28432804          |
| 234       | 17221.28125    | 4304           | 24.99233325          |
| 235       | 17229.37109    | 4424           | 25.67708349          |
+-----------+----------------+----------------+----------------------+

hugepage_mem_bp: 1000
goal tuner: consist

+-----------+----------------+----------------+----------------------+
| timestamp | total mem used | huge page used | percentage hugepage  |
+-----------+----------------+----------------+----------------------+
| 0         | 17125.85156    | 0              | 0                    |
| 38        | 17081.23438    | 76             | 0.444932716          |
| 39        | 17133.11719    | 196            | 1.143983304          |
| 40        | 17119.83984    | 316            | 1.84581166           |
| 41        | 17116.48438    | 436            | 2.547252055          |
| 60        | 17109.72656    | 554            | 3.237924335          |
| 75        | 17158.79297    | 600            | 3.496749457          |
| 90        | 17164.11328    | 628            | 3.65879664           |
| 105       | 17205          | 654            | 3.801220575          |
| 120       | 17176.01953    | 682            | 3.970652215          |
| 136       | 17172.19922    | 710            | 4.134589816          |
| 150       | 17154.96484    | 738            | 4.3019616            |
| 165       | 17190.66797    | 764            | 4.444271749          |
| 180       | 17177.66016    | 792            | 4.610639591          |
| 195       | 17202.01563    | 822            | 4.778509786          |
| 210       | 17160.23047    | 848            | 4.941658572          |
| 216       | 17147.09766    | 898            | 5.237037882          |
| 217       | 17180.72656    | 1018           | 5.925244176          |
| 218       | 17179.74609    | 1138           | 6.624079272          |
| 219       | 17151.43359    | 1258           | 7.334663853          |
| 220       | 17180.86719    | 1378           | 8.020549749          |
| 221       | 17201.65625    | 1498           | 8.708463756          |
| 222       | 17184.45703    | 1618           | 9.415485151          |
| 223       | 17174.21094    | 1718           | 10.00337079          |
| 224       | 17174.90234    | 1800           | 10.48040894          |
| 225       | 17204.64063    | 1874           | 10.89241002          |
| 226       | 17187.82031    | 1980           | 11.51978531          |
| 227       | 17145.08594    | 2100           | 12.24840755          |
| 228       | 17144.25781    | 2220           | 12.948942            |
| 229       | 17171.44141    | 2338           | 13.61563042          |
| 230       | 17175.02344    | 2458           | 14.31147974          |
| 231       | 17150.30469    | 2578           | 15.03180292          |
| 232       | 17148.73438    | 2698           | 15.73293948          |
| 233       | 17143.48438    | 2818           | 16.4377319           |
| 234       | 17167.57422    | 2938           | 17.11365836          |
| 235       | 17157.11328    | 3058           | 17.82351116          |
| 236       | 17151.45703    | 3178           | 18.52903805          |
| 237       | 17155.85938    | 3298           | 19.22375282          |
| 238       | 17188.00781    | 3418           | 19.88595791          |
| 239       | 17151.66406    | 3536           | 20.61607543          |
| 240       | 17137.38281    | 3656           | 21.33347921          |
| 241       | 17165.32422    | 3776           | 21.99783675          |
| 242       | 17158.48438    | 3896           | 22.70596817          |
| 243       | 17122.70313    | 4016           | 23.45424067          |
| 244       | 17151.28516    | 4136           | 24.114811            |
| 245       | 17188.16797    | 4256           | 24.76121951          |
| 246       | 17150.58984    | 4376           | 25.51515744          |
| 247       | 17178.125      | 4496           | 26.17282154          |
| 248       | 17130.97266    | 4616           | 26.94534684          |
| 249       | 17149.64063    | 4736           | 27.61573903          |
| 250       | 17175.5        | 4856           | 28.27283049          |
| 251       | 17141.30859    | 4978           | 29.04095666          |
| 252       | 17168.22266    | 5098           | 29.69439587          |
| 253       | 17158.42578    | 5218           | 30.41071522          |
| 254       | 17175.84375    | 5338           | 31.07853144          |
| 255       | 17173.60156    | 5458           | 31.78133591          |
| 256       | 17188.17188    | 5578           | 32.45254958          |
| 257       | 17217.83203    | 5698           | 33.09359732          |
| 258       | 17182.50781    | 5818           | 33.86001661          |
| 259       | 17194.44922    | 5936           | 34.52276909          |
| 260       | 17199.66406    | 6056           | 35.20999002          |
| 261       | 17188.90234    | 6176           | 35.93015933          |
| 262       | 17204.27344    | 6296           | 36.59555879          |
| 263       | 17202.03516    | 6416           | 37.29791238          |
| 264       | 17207.71484    | 6536           | 37.98296322          |
| 265       | 17224.46094    | 6656           | 38.64271877          |
| 266       | 17198.29297    | 6776           | 39.39925906          |
| 267       | 17200.13281    | 6896           | 40.09271367          |
| 268       | 17204.625      | 7014           | 40.76810741          |

| 269       | 17210.91406    | 7134           | 41.45044228          |
| 270       | 17203.98438    | 7254           | 42.16465118          |
| 271       | 17206.08203    | 7374           | 42.85693853          |
| 272       | 17210.62891    | 7494           | 43.54285971          |
| 273       | 17202.55859    | 7614           | 44.26085782          |
| 274       | 17223.07813    | 7734           | 44.90486511          |
| 275       | 17207.21875    | 7762           | 45.10897498          |
+-----------+----------------+----------------+----------------------+

From this, we can conclude that the huge page autotuner works fine, achieving the target. When using consistent autotuner, it actually over-achieves the target, which is expected, since quota esz_bp is not set to 0 to cap the DAMOS policy.

[1] https://github.com/asierHuawei/damo/commit/79ae1a4ab1c012a7161db85a000d14f08fa36736

Let me know what you think.

Quoted 252 lines · On Mon, 13 Jul 2026 14:30:40 +0300 Gutierrez Asier…

Hi SJ,

Quoted 231 lines · SJ Park

Quoted 213 lines · On Mon, 6 Jul 2026 18:03:03 +0300 Gutierrez Asier…

Hi SJ,

Quoted 210 lines · Gutierrez Asier

Hi SJ,

So sorry, I missed your email. I just found it. Sorry for the late answer.

Quoted 57 lines · SeongJae Park

Quoted 16 lines · On Tue, 16 Jun 2026 15:03:13 +0000 <[email protected]> wrote:

From: Asier Gutierrez <[email protected]>

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.

Quoted 7 lines

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?

Quoted 28 lines

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.

Quoted 8 lines

Quoted 4 lines

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?

Right, we agreed to change the name. I will correct it.

Quoted 8 lines

Quoted 4 lines

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

I actually set it to 500. I will update the cover letter.

Quoted 7 lines

Quoted 2 lines

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.

Actually, this is what I got using the TEMPORAL quota goals. With the regular quota goals, it actually over-achieves the goal.

Is this an actual bug in the TEMPORAL quota goal?

Quoted 62 lines

Quoted 58 lines

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

Quoted 3 lines

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.

Quoted 1 line

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

Memory fragmentation. I will add information about memory fragmentation in the next cover letter. >>

Quoted 7 lines

Quoted 7 lines

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%)

Quoted 5 lines

Quoted 1 line

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?

It's better than THP "never", but worse than THP "always". THP "always" is worse in terms of memory consumption, "always" is worse.

Quoted 40 lines

Quoted 8 lines

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

Quoted 11 lines

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!

[...]

Quoted 9 lines

[1] https://dl.acm.org/doi/pdf/10.1145/3307650.3322227
[2] https://lore.kernel.org/[email protected]
[3] https://lore.kernel.org/[email protected]
[4] https://lore.kernel.org/[email protected]
[5] https://lore.kernel.org/[email protected]
[6] https://lore.kernel.org/[email protected]
[7] https://lore.kernel.org/[email protected]
[8] https://lore.kernel.org/[email protected]
[9] https://lore.kernel.org/all/[email protected]/

[1] https://lore.kernel.org/[email protected]

Thanks,
SJ

Quoted 8 lines

Quoted 6 lines

Quoted 2 lines

[...]

SJ, once again, sorry for the late answer. Please, disregard my new patch set, I will fix it with your feedback.

I didn't get a reply to this email.

I sent the reply [1] weeks ago.

Quoted 2 lines

I will update the cover letter and submit a new patch set soon.

No, please. Let's fully complete the discussion before a new version.

Quoted 7 lines

[1] https://lore.kernel.org/[email protected]

Thanks,
SJ

[...]

Hi SJ,

So, I finally got some stable results which make sense now.

Setup: physical server with arm64 processor with 4 NUMA nodes, 1 TB RAM and running mariaDB 10.5.29. I use sysbench for the benchmark, with 20 tables and 3 million rows per table. The database was pinned to one of the nodes, and the benchmark framework to a different node. No network traffic involved in the benchmark.

Quoted 3 lines

I forked damo and added hugepage_mem_bp support[1].

I launch DAMON using this command line:

This is very helpful at understanding the test setup. Thank you for sharing!

Quoted 10 lines

sudo ./damo start $(pidof mariadbd) \
--monitoring_nr_regions_range 10 1000 \
--monitoring_intervals 5000 100000 60000000 \
--damos_quota_time 0 --damos_quota_space 128000000 \
--damos_quota_interval 1000 \
--damos_quota_weights 0 1 1 \
--damos_quota_goal hugepage_mem_bp <target> \
--damos_quota_goal_tuner temporal \
--damos_apply_interval 50000 \

So, 50 ms DAMOS apply interval? Seems quite short to me. No big deal, though.

Quoted 2 lines

--damos_access_rate 0 max --damos_age 50 max \
--damos_action collapse --debug_damon

FYI, damo supports human friendly formats. E.g.,

    --monitoring_intervals 5ms 100ms 60s \
    --damos_quota_space 128MB --damos_quota_interval 1s \
    --damos_apply_interval 50ms

Quoted 37 lines

<target> was 1000 to taget 10% hugepage to total memory ratio, or 2500 to target 25%. Tuner was also tested with consistent and temporal.

Results
=======
After the last timestamp, there was no change in huge page use, and the total huge page to memory consumption ratio barely moved.

Timestamp is measured in seconds, and the memory consumption (total and huge page) is in MB.

hugepage_mem_bp: 1000
goal tuner: temporal

+-----------+----------------+----------------+----------------------+
| timestamp | total mem used | huge page used | percentage hugepage  |
+-----------+----------------+----------------+----------------------+
| 0         | 16945.04297    | 0              | 0                    |
| 7         | 17008.69531    | 74             | 0.435071583          |
| 8         | 17036.40234    | 194            | 1.138738074          |
| 9         | 17017.01563    | 314            | 1.845211916          |
| 10        | 17029.67969    | 434            | 2.548491856          |
| 61        | 17111.30859    | 584            | 3.412947623          |
| 75        | 17068.51953    | 612            | 3.58554823           |
| 90        | 17098.84766    | 638            | 3.731245595          |
| 105       | 17076.32031    | 664            | 3.888425538          |
| 120       | 17071.05859    | 694            | 4.065360072          |
| 135       | 17088.94531    | 722            | 4.22495354           |
| 150       | 17101.42578    | 746            | 4.362209383          |
| 165       | 17097.33984    | 776            | 4.53871776           |
| 180       | 17133.88281    | 804            | 4.692456513          |
| 195       | 17099.12891    | 832            | 4.865744943          |
| 201       | 17103.5        | 852            | 4.981436548          |
| 202       | 17077.84375    | 862            | 5.047475622          |
| 203       | 17088.16406    | 916            | 5.360435426          |

Quoted 8 lines

| 204       | 17126.34766    | 1046           | 6.107548562          |
| 205       | 17093.84375    | 1176           | 6.879669764          |
| 206       | 17142.77734    | 1298           | 7.571701913          |
| 207       | 17129.86719    | 1428           | 8.336316822          |
| 208       | 17099.76953    | 1556           | 9.099537846          |
| 209       | 17149.17969    | 1686           | 9.831374041          |
| 210       | 17097.30859    | 1754           | 10.25892462          |
+-----------+----------------+----------------+----------------------+

I saw you added description of all results at the end. But adding it for each result would be nicer for readers. E.g., you could say,

"As expected, ~10 % huge page ratio is achieved."

Or, you could make tables shorter by cutting more lines, keeping the height ~10 rows per table?

Quoted 43 lines

hugepage_mem_bp: 1000
goal tuner: consistent

+-----------+----------------+----------------+----------------------+
| timestamp | total mem used | huge page used | percentage hugepage  |
+-----------+----------------+----------------+----------------------+
| 0         | 16955.24609    | 0              | 0                    |
| 34        | 17039.71875    | 106            | 0.622075995          |
| 35        | 17022.21875    | 224            | 1.315927161          |
| 36        | 17070.08594    | 344            | 2.015221255          |
| 37        | 17005.86719    | 464            | 2.728470091          |
| 38        | 17028.92188    | 542            | 3.182820404          |
| 78        | 17009.47656    | 554            | 3.257007927          |
| 79        | 17051.82031    | 572            | 3.354480575          |
| 90        | 17048.92188    | 596            | 3.495822225          |
| 105       | 17086.22656    | 624            | 3.652064414          |
| 120       | 17102.49609    | 654            | 3.824003212          |
| 135       | 17081.31641    | 680            | 3.980957813          |
| 150       | 17092.90625    | 706            | 4.130368409          |
| 165       | 17093.69531    | 736            | 4.305681051          |
| 180       | 17053.08984    | 764            | 4.480126517          |
| 195       | 17095.73047    | 788            | 4.609337995          |
| 210       | 17086.20703    | 818            | 4.787487349          |
| 225       | 17095.04297    | 846            | 4.948803004          |
| 226       | 17057.95703    | 848            | 4.971286998          |
| 227       | 17101.46484    | 858            | 5.017114077          |
| 228       | 17053.90625    | 896            | 5.253928261          |
| 229       | 17061.48047    | 1016           | 5.954934578          |
| 230       | 17097.48828    | 1136           | 6.644250789          |
| 231       | 17080.42188    | 1256           | 7.353448347          |
| 232       | 17118.92969    | 1376           | 8.037885692          |
| 233       | 17100.50391    | 1496           | 8.748280216          |
| 234       | 17110.80859    | 1616           | 9.444322816          |
| 235       | 17138.17188    | 1736           | 10.12943512          |
| 236       | 17060.17578    | 1856           | 10.87913761          |
| 237       | 17118.92578    | 1976           | 11.54278034          |
| 238       | 17119.28516    | 2096           | 12.24350188          |
| 239       | 17098.89063    | 2216           | 12.95990511          |
| 240       | 17135.44531    | 2334           | 13.62088908          |
| 241       | 17097.58594    | 2454           | 14.35290344          |
| 242       | 17134.69531    | 2574           | 15.02215215          |
| 243       | 17127.96094    | 2694           | 15.72866735          |

Quoted 8 lines

| 244       | 17097.53516    | 2812           | 16.44681514          |
| 245       | 17132.55078    | 2932           | 17.11362212          |
| 246       | 17117.95313    | 3052           | 17.82923448          |
| 247       | 17154.30469    | 3172           | 18.49098554          |
| 248       | 17145.55078    | 3292           | 19.20031641          |
| 249       | 17138.36719    | 3410           | 19.89687794          |
| 250       | 17163.12109    | 3532           | 20.57900763          |
+-----------+----------------+----------------+----------------------+

Seems the table bit long to me. When you add this to the cover letter, I think you could further cut some rows. Maybe showing the rows for ~2% jumps? E.g.,

+-----------+----------------+----------------+----------------------+
| timestamp | total mem used | huge page used | percentage hugepage  |
+-----------+----------------+----------------+----------------------+
| 0         | 16955.24609    | 0              | 0                    |
| 36        | 17070.08594    | 344            | 2.015221255          |
| 150       | 17092.90625    | 706            | 4.130368409          |
| 230       | 17097.48828    | 1136           | 6.644250789          |
| 232       | 17118.92969    | 1376           | 8.037885692          |
| 235       | 17138.17188    | 1736           | 10.12943512          |
| 238       | 17119.28516    | 2096           | 12.24350188          |
| 241       | 17097.58594    | 2454           | 14.35290344          |
| 244       | 17097.53516    | 2812           | 16.44681514          |
| 247       | 17154.30469    | 3172           | 18.49098554          |
| 250       | 17163.12109    | 3532           | 20.57900763          |
+-----------+----------------+----------------+----------------------+

Quoted 48 lines

hugepage_mem_bp: 2500
goal tuner: temporal

+-----------+----------------+----------------+----------------------+
| timestamp | total mem used | huge page used | percentage hugepage  |
+-----------+----------------+----------------+----------------------+
| 0         | 17010.31641    | 0              | 0                    |
| 9         | 17063.6875     | 50             | 0.2930199            |
| 10        | 17051.75781    | 170            | 0.996964664          |
| 11        | 17059.625      | 290            | 1.699920133          |
| 12        | 17053.72656    | 410            | 2.404166611          |
| 13        | 17082.44141    | 528            | 3.090893084          |
| 14        | 17097.22266    | 530            | 3.099918687          |
| 60        | 17133.85547    | 572            | 3.338419663          |
| 75        | 17149.26563    | 598            | 3.487029784          |
| 90        | 17192.07813    | 626            | 3.641211932          |
| 105       | 17196.34766    | 654            | 3.80313316           |
| 120       | 17221.44531    | 682            | 3.960178647          |
| 135       | 17225.36719    | 708            | 4.110217172          |
| 150       | 17220.15625    | 736            | 4.274061102          |
| 165       | 17223.66406    | 764            | 4.435757672          |
| 181       | 17199.76172    | 790            | 4.593086886          |
| 195       | 17139.11328    | 818            | 4.772708988          |
| 205       | 17185.85547    | 862            | 5.015752644          |
| 206       | 17228.63281    | 978            | 5.67659669           |
| 207       | 17194.80469    | 1094           | 6.362386895          |
| 208       | 17222.77734    | 1206           | 7.002354939          |
| 209       | 17177.09766    | 1320           | 7.68465096           |
| 210       | 17182.23828    | 1428           | 8.310907907          |
| 211       | 17196.77734    | 1542           | 8.966796332          |
| 212       | 17205.57031    | 1664           | 9.671286507          |
| 213       | 17227.39844    | 1784           | 10.35559726          |
| 214       | 17245.17969    | 1904           | 11.04076637          |
| 215       | 17240.45703    | 2024           | 11.73982799          |
| 216       | 17218.85156    | 2144           | 12.45146921          |
| 217       | 17183.63281    | 2264           | 13.17532809          |
| 218       | 17217.08984    | 2384           | 13.84670709          |
| 219       | 17176.72266    | 2504           | 14.57786826          |
| 220       | 17234.79688    | 2624           | 15.22501262          |
| 221       | 17221.20703    | 2744           | 15.93384247          |
| 222       | 17258.91016    | 2864           | 16.59432707          |
| 223       | 17248.64063    | 2984           | 17.29991403          |
| 224       | 17227.35156    | 3104           | 18.0178595           |
| 225       | 17194.83594    | 3224           | 18.74981542          |
| 226       | 17216.30078    | 3344           | 19.42345247          |
| 227       | 17205.71875    | 3464           | 20.13284101          |
| 228       | 17222.83594    | 3584           | 20.80958103          |

Quoted 8 lines

| 229       | 17232.32031    | 3704           | 21.49449368          |
| 230       | 17269.49219    | 3824           | 22.14309465          |
| 231       | 17247.55469    | 3944           | 22.86700968          |
| 232       | 17248.90234    | 4064           | 23.56091952          |
| 233       | 17229.21875    | 4184           | 24.28432804          |
| 234       | 17221.28125    | 4304           | 24.99233325          |
| 235       | 17229.37109    | 4424           | 25.67708349          |
+-----------+----------------+----------------+----------------------+

Again, table looks bit long to me. In the final version of the cover letter, maybe we can show only ~3% jumps? E.g.,

+-----------+----------------+----------------+----------------------+
| timestamp | total mem used | huge page used | percentage hugepage  |
+-----------+----------------+----------------+----------------------+
| 0         | 17010.31641    | 0              | 0                    |
| 13        | 17082.44141    | 528            | 3.090893084          |
| 207       | 17194.80469    | 1094           | 6.362386895          |
| 212       | 17205.57031    | 1664           | 9.671286507          |
| 216       | 17218.85156    | 2144           | 12.45146921          |
| 220       | 17234.79688    | 2624           | 15.22501262          |
| 224       | 17227.35156    | 3104           | 18.0178595           |
| 229       | 17232.32031    | 3704           | 21.49449368          |
| 233       | 17229.21875    | 4184           | 24.28432804          |
| 235       | 17229.37109    | 4424           | 25.67708349          |
+-----------+----------------+----------------+----------------------+

Quoted 76 lines

hugepage_mem_bp: 1000
goal tuner: consist

+-----------+----------------+----------------+----------------------+
| timestamp | total mem used | huge page used | percentage hugepage  |
+-----------+----------------+----------------+----------------------+
| 0         | 17125.85156    | 0              | 0                    |
| 38        | 17081.23438    | 76             | 0.444932716          |
| 39        | 17133.11719    | 196            | 1.143983304          |
| 40        | 17119.83984    | 316            | 1.84581166           |
| 41        | 17116.48438    | 436            | 2.547252055          |
| 60        | 17109.72656    | 554            | 3.237924335          |
| 75        | 17158.79297    | 600            | 3.496749457          |
| 90        | 17164.11328    | 628            | 3.65879664           |
| 105       | 17205          | 654            | 3.801220575          |
| 120       | 17176.01953    | 682            | 3.970652215          |
| 136       | 17172.19922    | 710            | 4.134589816          |
| 150       | 17154.96484    | 738            | 4.3019616            |
| 165       | 17190.66797    | 764            | 4.444271749          |
| 180       | 17177.66016    | 792            | 4.610639591          |
| 195       | 17202.01563    | 822            | 4.778509786          |
| 210       | 17160.23047    | 848            | 4.941658572          |
| 216       | 17147.09766    | 898            | 5.237037882          |
| 217       | 17180.72656    | 1018           | 5.925244176          |
| 218       | 17179.74609    | 1138           | 6.624079272          |
| 219       | 17151.43359    | 1258           | 7.334663853          |
| 220       | 17180.86719    | 1378           | 8.020549749          |
| 221       | 17201.65625    | 1498           | 8.708463756          |
| 222       | 17184.45703    | 1618           | 9.415485151          |
| 223       | 17174.21094    | 1718           | 10.00337079          |
| 224       | 17174.90234    | 1800           | 10.48040894          |
| 225       | 17204.64063    | 1874           | 10.89241002          |
| 226       | 17187.82031    | 1980           | 11.51978531          |
| 227       | 17145.08594    | 2100           | 12.24840755          |
| 228       | 17144.25781    | 2220           | 12.948942            |
| 229       | 17171.44141    | 2338           | 13.61563042          |
| 230       | 17175.02344    | 2458           | 14.31147974          |
| 231       | 17150.30469    | 2578           | 15.03180292          |
| 232       | 17148.73438    | 2698           | 15.73293948          |
| 233       | 17143.48438    | 2818           | 16.4377319           |
| 234       | 17167.57422    | 2938           | 17.11365836          |
| 235       | 17157.11328    | 3058           | 17.82351116          |
| 236       | 17151.45703    | 3178           | 18.52903805          |
| 237       | 17155.85938    | 3298           | 19.22375282          |
| 238       | 17188.00781    | 3418           | 19.88595791          |
| 239       | 17151.66406    | 3536           | 20.61607543          |
| 240       | 17137.38281    | 3656           | 21.33347921          |
| 241       | 17165.32422    | 3776           | 21.99783675          |
| 242       | 17158.48438    | 3896           | 22.70596817          |
| 243       | 17122.70313    | 4016           | 23.45424067          |
| 244       | 17151.28516    | 4136           | 24.114811            |
| 245       | 17188.16797    | 4256           | 24.76121951          |
| 246       | 17150.58984    | 4376           | 25.51515744          |
| 247       | 17178.125      | 4496           | 26.17282154          |
| 248       | 17130.97266    | 4616           | 26.94534684          |
| 249       | 17149.64063    | 4736           | 27.61573903          |
| 250       | 17175.5        | 4856           | 28.27283049          |
| 251       | 17141.30859    | 4978           | 29.04095666          |
| 252       | 17168.22266    | 5098           | 29.69439587          |
| 253       | 17158.42578    | 5218           | 30.41071522          |
| 254       | 17175.84375    | 5338           | 31.07853144          |
| 255       | 17173.60156    | 5458           | 31.78133591          |
| 256       | 17188.17188    | 5578           | 32.45254958          |
| 257       | 17217.83203    | 5698           | 33.09359732          |
| 258       | 17182.50781    | 5818           | 33.86001661          |
| 259       | 17194.44922    | 5936           | 34.52276909          |
| 260       | 17199.66406    | 6056           | 35.20999002          |
| 261       | 17188.90234    | 6176           | 35.93015933          |
| 262       | 17204.27344    | 6296           | 36.59555879          |
| 263       | 17202.03516    | 6416           | 37.29791238          |
| 264       | 17207.71484    | 6536           | 37.98296322          |
| 265       | 17224.46094    | 6656           | 38.64271877          |
| 266       | 17198.29297    | 6776           | 39.39925906          |
| 267       | 17200.13281    | 6896           | 40.09271367          |
| 268       | 17204.625      | 7014           | 40.76810741          |

Quoted 8 lines

| 269       | 17210.91406    | 7134           | 41.45044228          |
| 270       | 17203.98438    | 7254           | 42.16465118          |
| 271       | 17206.08203    | 7374           | 42.85693853          |
| 272       | 17210.62891    | 7494           | 43.54285971          |
| 273       | 17202.55859    | 7614           | 44.26085782          |
| 274       | 17223.07813    | 7734           | 44.90486511          |
| 275       | 17207.21875    | 7762           | 45.10897498          |
+-----------+----------------+----------------+----------------------+

Again, seems long for the final version of the cover letter? We could show for ~5% jumps?

+-----------+----------------+----------------+----------------------+
| timestamp | total mem used | huge page used | percentage hugepage  |
+-----------+----------------+----------------+----------------------+
| 0         | 17125.85156    | 0              | 0                    |
| 216       | 17147.09766    | 898            | 5.237037882          |
| 223       | 17174.21094    | 1718           | 10.00337079          |
| 231       | 17150.30469    | 2578           | 15.03180292          |
| 239       | 17151.66406    | 3536           | 20.61607543          |
| 246       | 17150.58984    | 4376           | 25.51515744          |
| 253       | 17158.42578    | 5218           | 30.41071522          |
| 260       | 17199.66406    | 6056           | 35.20999002          |
| 267       | 17200.13281    | 6896           | 40.09271367          |
| 275       | 17207.21875    | 7762           | 45.10897498          |
+-----------+----------------+----------------+----------------------+

Quoted 6 lines

From this, we can conclude that the huge page autotuner works fine, achieving the target. When using consistent autotuner, it actually over-achieves the target, which is expected, since quota esz_bp is not set to 0 to cap the DAMOS policy.

Quoted 3 lines

[1] https://github.com/asierHuawei/damo/commit/79ae1a4ab1c012a7161db85a000d14f08fa36736

Let me know what you think.

Looks good! Let's proceed to the next version of the patch series with this great test results!

Thanks,
SJ

[...]