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

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

[gutierrez.asier]

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

Overview
========

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

Motivation
==========

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

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

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

Solution
========

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

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

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

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

Benchmarks
==========

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

The hugepage module was set up in the following way:

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

The goal was to achieve 5% of the total memory used as hugepage.

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

+-----------+----------------+----------------+----------------------+
| timestamp | total mem used | huge page used | percentage hugepage  |
+-----------+----------------+----------------+----------------------+
| 0         | 4721188        | 0              | 0%                   |
| 28        | 4216848        | 4              | 0%                   |
| 37        | 4189912        | 38912          | 1%                   |
| 39        | 4195188        | 47104          | 1%                   |
| 55        | 4111612        | 51200          | 1%                   |
| 59        | 4137012        | 53248          | 1%                   |
| 60        | 4137052        | 55296          | 1%                   |
| 61        | 4156832        | 57344          | 1%                   |
| 62        | 4136920        | 59392          | 1%                   |
| 64        | 4109872        | 61440          | 1%                   |
| 65        | 4119108        | 63488          | 2%                   |
| 66        | 4145532        | 65536          | 2%                   |
| 67        | 4134544        | 67584          | 2%                   |
| 68        | 4158244        | 126976         | 3%                   |
| 69        | 4124276        | 204800         | 5%                   |
| 70        | 4100680        | 333824         | 8%                   |
| 71        | 4095540        | 462848         | 11%                  |
+-----------+----------------+----------------+----------------------+

Performance:
Baseline -> 18,162.45 transactions per second
Hugepage autotune -> 18,211.82 transactions per second


Eventually, the amount of huge pages reached 20%. This is consistent
with how quota goals autotuning work. We are more aggresive when the
quota is less than 10%, and less aggresive when the quota is higher.
At some point, the aggressiveness just fades and no more collapses
occur.

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

Patches Sequence
================
Patch 1 -> Introduce DAMOS_QUOTA_HUGEPAGE and autotuning
Patch 2 -> damon_modules_new_vaddr_ctx_target
Patch 3 -> Module that demonstrates how to use DAMOS_QUOTA_HUGEPAGE
           and the new VADDR ctx creation
Patch 4 -> Documentation

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

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

Asier Gutierrez (4):
  mm/damon: Generalize ctx_target creation for damon_ops_id and add vaddr support
  mm/damon: Introduce DAMOS_QUOTA_HUGEPAGE auto tuning
  mm/damon: introduce DAMON_HUGEPAGE for hot region hugepage collapsing
  Documentation/admin-guide/mm/damon: add DAMON-based Hugepage Management documentation

Asier Gutierrez (4):
  Introduce DAMOS_QUOTA_HUGEPAGE auto tuning Add a new DAMOS quota goal
    metric to measure the amount of huge page consumption to total
    anonymous memory consumption ratio.
  This patch adds a new function damon_modules_new_vaddr_ctx_target.
    Since ctx_target creation for vaddr and paddr is almost identical,
    the logic is extracted to a new function,
    damon_modules_new_ctx_target, and vaddr and paddr functions are left
    just as interfaces.
  This patch introduces a new DAMON module (SAMPLE_DAMON_HUGEPAGE) which
    collapses hot regions into huge pages.
  Add documentation for the DAMON-based Hugepage Management
    (DAMON_HUGEPAGE) feature, which automatically manages huge pages  by
    identifying hot memory regions and collapsing them back to regular
    pages. The documentation covers the module's features, operation,
    and all available module parameters.

 .../admin-guide/mm/damon/hugepage.rst (new)   | 271 ++++++++++++++
 include/linux/damon.h                         |   1 +
 mm/damon/Makefile                             |   8 +-
 mm/damon/core.c                               |  14 +
 mm/damon/modules-common.c                     |  31 +-
 mm/damon/modules-common.h                     |   3 +
 samples/damon/Kconfig                         |  12 +
 samples/damon/Makefile                        |   2 +
 samples/damon/hugepage.c (new)                | 350 ++++++++++++++++++
 9 files changed, 684 insertions(+), 8 deletions(-)
 create mode 100644 Documentation/admin-guide/mm/damon/hugepage.rst
 create mode 100644 samples/damon/hugepage.c

-- 
2.43.0

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

[gutierrez.asier]

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

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

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

diff --git a/include/linux/damon.h b/include/linux/damon.h
index c7a31572689b..8e15a674e893 100644
--- a/include/linux/damon.h
+++ b/include/linux/damon.h
@@ -177,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,
 	NR_DAMOS_QUOTA_GOAL_METRICS,
 };
 
diff --git a/mm/damon/core.c b/mm/damon/core.c
index 9f38deddcb30..7fc7477a353a 100644
--- a/mm/damon/core.c
+++ b/mm/damon/core.c
@@ -2536,6 +2536,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)
 {
@@ -2567,6 +2578,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:
+		goal->current_value = damos_hugepage_mem_bp();
+		break;
 	default:
 		break;
 	}
-- 
2.43.0

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

[sashiko-bot]

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

New issues:
- [High] A potential division by zero in damos_hugepage_mem_bp() can cause a kernel panic if the total non-free RAM pages evaluate to 0.
- [Medium] The new DAMOS_QUOTA_HUGEPAGE metric is inaccessible from userspace because it was not added to the sysfs mapping array damos_sysfs_qgoal_metric_names.
- [Medium] The implementation calculates the ratio of all THP memory to total used memory, directly contradicting the commit message's claim that it measures huge page consumption relative to total anonymous memory.
- [Medium] The calculation in mult_frac() can silently overflow a 32-bit unsigned long, resulting in arbitrarily small, incorrect quota targets.

Pre-existing issues:
- [High] The pre-existing DAMOS_QUOTA_ACTIVE_MEM_BP and INACTIVE_MEM_BP metric computation can trigger a kernel panic via division by zero.
--

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

mm/damon: Introduce DAMOS_QUOTA_HUGEPAGE auto tuning

This commit introduces a new DAMOS quota goal metric, DAMOS_QUOTA_HUGEPAGE,
which is intended to measure the ratio of huge page consumption against
total anonymous memory.

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

[Severity: Medium]
Does this description match the implementation?

The commit message states this measures huge page consumption against total
anonymous memory, but the code in damos_hugepage_mem_bp() calculates the sum
of all transparent huge pages relative to total used memory.

> diff --git a/include/linux/damon.h b/include/linux/damon.h
> index 6f7edb3590ef9..d840b0bc0b953 100644
> --- a/include/linux/damon.h
> +++ b/include/linux/damon.h
[ ... ]
> @@ -176,6 +176,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,

[Severity: Medium]
Does this new metric need to be added to damos_sysfs_qgoal_metric_names[]
in mm/damon/sysfs-schemes.c?

Without adding it to the string mapping array, it appears this metric cannot
be configured from userspace via sysfs.

> diff --git a/mm/damon/core.c b/mm/damon/core.c
> index 265d51ade25bf..71c8699bdd476 100644
> --- a/mm/damon/core.c
> +++ b/mm/damon/core.c
> @@ -2756,6 +2756,17 @@ static unsigned int damos_get_in_active_mem_bp(bool active_ratio)
>  	return mult_frac(inactive, 10000, total);
>  }

[Severity: High]
This is a pre-existing issue, but can this cause a divide by zero kernel
panic?

If there are no active or inactive pages, or if per-CPU vmstat counter drift
evaluates total to 0, mult_frac() will divide by zero.

> +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]
Can mult_frac() divide by zero here?

If the system is highly idle or due to per-CPU vmstat counter drift, total
could evaluate to exactly 0.

[Severity: Medium]
Is there a risk of a 32-bit overflow in this calculation?

On 32-bit architectures, mult_frac() preserves types, and computing
thp * 10000 could exceed the maximum unsigned long value if there are
more than ~1.7 GB of THPs, producing an arbitrarily small quota target.

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

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

[Gutierrez Asier]

On 6/4/2026 6:19 PM, sashiko-bot@kernel.org wrote:
> Thank you for your contribution! Sashiko AI review found 5 potential issue(s) to consider:
> 
> New issues:
> - [High] A potential division by zero in damos_hugepage_mem_bp() can cause a kernel panic if the total non-free RAM pages evaluate to 0.
> - [Medium] The new DAMOS_QUOTA_HUGEPAGE metric is inaccessible from userspace because it was not added to the sysfs mapping array damos_sysfs_qgoal_metric_names.
> - [Medium] The implementation calculates the ratio of all THP memory to total used memory, directly contradicting the commit message's claim that it measures huge page consumption relative to total anonymous memory.
> - [Medium] The calculation in mult_frac() can silently overflow a 32-bit unsigned long, resulting in arbitrarily small, incorrect quota targets.
> 
> Pre-existing issues:
> - [High] The pre-existing DAMOS_QUOTA_ACTIVE_MEM_BP and INACTIVE_MEM_BP metric computation can trigger a kernel panic via division by zero.
> --
> 
> commit 1f37bbf7381e392f999f133e0444c2faad754df9
> Author: Asier Gutierrez <gutierrez.asier@huawei-partners.com>
> 
> mm/damon: Introduce DAMOS_QUOTA_HUGEPAGE auto tuning
> 
> This commit introduces a new DAMOS quota goal metric, DAMOS_QUOTA_HUGEPAGE,
> which is intended to measure the ratio of huge page consumption against
> total anonymous memory.
Right, the commit is outdated. I will update it to reflect the
last changes.
>> Introduce DAMOS_QUOTA_HUGEPAGE auto tuning Add a
>> new DAMOS quota goal metric to measure the amount of huge
>> page consumption to total anonymous memory consumption
>> ratio.
> 
> [Severity: Medium]
> Does this description match the implementation?
> 
> The commit message states this measures huge page consumption against total
> anonymous memory, but the code in damos_hugepage_mem_bp() calculates the sum
> of all transparent huge pages relative to total used memory.
As mentioned, I will update the commit message.
>> diff --git a/include/linux/damon.h b/include/linux/damon.h
>> index 6f7edb3590ef9..d840b0bc0b953 100644
>> --- a/include/linux/damon.h
>> +++ b/include/linux/damon.h
> [ ... ]
>> @@ -176,6 +176,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,
> 
> [Severity: Medium]
> Does this new metric need to be added to damos_sysfs_qgoal_metric_names[]
> in mm/damon/sysfs-schemes.c?
> 
> Without adding it to the string mapping array, it appears this metric cannot
> be configured from userspace via sysfs.
> 
I had it a local branch. I forgot to add it to the patch series. I will do it.

>> diff --git a/mm/damon/core.c b/mm/damon/core.c
>> index 265d51ade25bf..71c8699bdd476 100644
>> --- a/mm/damon/core.c
>> +++ b/mm/damon/core.c
>> @@ -2756,6 +2756,17 @@ static unsigned int damos_get_in_active_mem_bp(bool active_ratio)
>>  	return mult_frac(inactive, 10000, total);
>>  }
> 
> [Severity: High]
> This is a pre-existing issue, but can this cause a divide by zero kernel
> panic?
> 
> If there are no active or inactive pages, or if per-CPU vmstat counter drift
> evaluates total to 0, mult_frac() will divide by zero.
Not a bug. The system can never have 0 consumed memory.
>> +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]
> Can mult_frac() divide by zero here?
> 
> If the system is highly idle or due to per-CPU vmstat counter drift, total
> could evaluate to exactly 0.
No, total can never be 0.
> [Severity: Medium]
> Is there a risk of a 32-bit overflow in this calculation?
> 
> On 32-bit architectures, mult_frac() preserves types, and computing
> thp * 10000 could exceed the maximum unsigned long value if there are
> more than ~1.7 GB of THPs, producing an arbitrarily small quota target.
> 
Good catch! I will cast 10000 to unsigned long to preserve the types.
-- 
Asier Gutierrez
Huawei

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

[SeongJae Park]

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

> From: Asier Gutierrez <gutierrez.asier@huawei-partners.com>
> 
> Introduce DAMOS_QUOTA_HUGEPAGE auto tuning Add a
> new DAMOS quota goal metric to measure the amount of huge
> page consumption to total anonymous memory consumption
> ratio.

s/anonymous// ?

> 
> Signed-off-by: Asier Gutierrez <gutierrez.asier@huawei-partners.com>
> ---
>  include/linux/damon.h |  1 +
>  mm/damon/core.c       | 14 ++++++++++++++
>  2 files changed, 15 insertions(+)
> 
> diff --git a/include/linux/damon.h b/include/linux/damon.h
> index c7a31572689b..8e15a674e893 100644
> --- a/include/linux/damon.h
> +++ b/include/linux/damon.h
> @@ -177,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,

On the previous revision, I suggested renaming this to
DAMOS_QUOTA_HUGEPAGE_MEM_BP for consistency, but it didn't got your reply.
Could I ask your opinion?

Also, I asked you to add the kernel-doc comment before dropping RFC.  I know
you didn't drop RFC tag yet, but could you consider adding it from the next
revision?

>  	NR_DAMOS_QUOTA_GOAL_METRICS,
>  };
>  
> diff --git a/mm/damon/core.c b/mm/damon/core.c
> index 9f38deddcb30..7fc7477a353a 100644
> --- a/mm/damon/core.c
> +++ b/mm/damon/core.c
> @@ -2536,6 +2536,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);
> +}

As Sashiko also [1] commented, let's avoid divide by zero by checking if total
is zero, before calling mult_frac().

I wouldn't mind ignoring Sashiko's 32-bit concern, but do you have any opinion?

> +
>  static void damos_set_quota_goal_current_value(struct damon_ctx *c,
>  		struct damos *s, struct damos_quota_goal *goal)
>  {
> @@ -2567,6 +2578,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:
> +		goal->current_value = damos_hugepage_mem_bp();
> +		break;
>  	default:
>  		break;
>  	}
> -- 
> 2.43.0

Other than the above comments, looks good to me overall.

[1] https://lore.kernel.org/20260604151932.93C431F00893@smtp.kernel.org


Thanks,
SJ

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

[Gutierrez Asier]

On 6/5/2026 3:44 AM, SeongJae Park wrote:
> On Thu, 4 Jun 2026 15:03:34 +0000 <gutierrez.asier@huawei-partners.com> wrote:
> 
>> From: Asier Gutierrez <gutierrez.asier@huawei-partners.com>
>>
>> Introduce DAMOS_QUOTA_HUGEPAGE auto tuning Add a
>> new DAMOS quota goal metric to measure the amount of huge
>> page consumption to total anonymous memory consumption
>> ratio.
> 
> s/anonymous// ?
> 
>>
>> Signed-off-by: Asier Gutierrez <gutierrez.asier@huawei-partners.com>
>> ---
>>  include/linux/damon.h |  1 +
>>  mm/damon/core.c       | 14 ++++++++++++++
>>  2 files changed, 15 insertions(+)
>>
>> diff --git a/include/linux/damon.h b/include/linux/damon.h
>> index c7a31572689b..8e15a674e893 100644
>> --- a/include/linux/damon.h
>> +++ b/include/linux/damon.h
>> @@ -177,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,
> 
> On the previous revision, I suggested renaming this to
> DAMOS_QUOTA_HUGEPAGE_MEM_BP for consistency, but it didn't got your reply.
> Could I ask your opinion?
> 
> Also, I asked you to add the kernel-doc comment before dropping RFC.  I know
> you didn't drop RFC tag yet, but could you consider adding it from the next
> revision?
Sorry, missed it. I will change it.
>>  	NR_DAMOS_QUOTA_GOAL_METRICS,
>>  };
>>  
>> diff --git a/mm/damon/core.c b/mm/damon/core.c
>> index 9f38deddcb30..7fc7477a353a 100644
>> --- a/mm/damon/core.c
>> +++ b/mm/damon/core.c
>> @@ -2536,6 +2536,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);
>> +}
> 
> As Sashiko also [1] commented, let's avoid divide by zero by checking if total
> is zero, before calling mult_frac().
> 
> I wouldn't mind ignoring Sashiko's 32-bit concern, but do you have any opinion?
I just answered. I can cast 10.000 to unsigned long. I don't think many people
using 32 bit systems will use over 1.6GB of huge pages, but it makes sense to
be safe anyway.
>> +
>>  static void damos_set_quota_goal_current_value(struct damon_ctx *c,
>>  		struct damos *s, struct damos_quota_goal *goal)
>>  {
>> @@ -2567,6 +2578,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:
>> +		goal->current_value = damos_hugepage_mem_bp();
>> +		break;
>>  	default:
>>  		break;
>>  	}
>> -- 
>> 2.43.0
> 
> Other than the above comments, looks good to me overall.
> 
> [1] https://lore.kernel.org/20260604151932.93C431F00893@smtp.kernel.org
> 
> 
> Thanks,
> SJ
> 

-- 
Asier Gutierrez
Huawei

[RFC PATCH v3 2/4] mm/damon: Generalize ctx_target creation for damon_ops_id and add vaddr support

[gutierrez.asier]

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

This patch adds a new function damon_modules_new_vaddr_ctx_target.
Since ctx_target creation for vaddr and paddr is almost
identical, the logic is extracted to a new function,
damon_modules_new_ctx_target, and vaddr and paddr functions
are left just as interfaces.

This change was suggested earlier1 and it is needed to allow
developers to create DAMON modules that use DAMON_OPS_VADDR targets.

Signed-off-by: Asier Gutierrez <gutierrez.asier@huawei-partners.com>
Suggested-by: SeongJae Park <sj@kernel.org>
---
 mm/damon/modules-common.c | 31 +++++++++++++++++++++++++++----
 mm/damon/modules-common.h |  3 +++
 2 files changed, 30 insertions(+), 4 deletions(-)

diff --git a/mm/damon/modules-common.c b/mm/damon/modules-common.c
index 86d58f8c4f63..9b0cc80378f8 100644
--- a/mm/damon/modules-common.c
+++ b/mm/damon/modules-common.c
@@ -10,12 +10,13 @@
 #include "modules-common.h"
 
 /*
- * Allocate, set, and return a DAMON context for the physical address space.
+ * Allocate, set, and return a DAMON context.
  * @ctxp:	Pointer to save the point to the newly created context
  * @targetp:	Pointer to save the point to the newly created target
+ * id:	DAMOS op id. It can be VADDR or PADDR
  */
-int damon_modules_new_paddr_ctx_target(struct damon_ctx **ctxp,
-		struct damon_target **targetp)
+static int _damon_modules_new_ctx_target(struct damon_ctx **ctxp,
+				struct damon_target **targetp, enum damon_ops_id id)
 {
 	struct damon_ctx *ctx;
 	struct damon_target *target;
@@ -24,7 +25,7 @@ int damon_modules_new_paddr_ctx_target(struct damon_ctx **ctxp,
 	if (!ctx)
 		return -ENOMEM;
 
-	if (damon_select_ops(ctx, DAMON_OPS_PADDR)) {
+	if (damon_select_ops(ctx, id)) {
 		damon_destroy_ctx(ctx);
 		return -EINVAL;
 	}
@@ -40,3 +41,25 @@ int damon_modules_new_paddr_ctx_target(struct damon_ctx **ctxp,
 	*targetp = target;
 	return 0;
 }
+
+/*
+ * Allocate, set, and return a DAMON context for the physical address space.
+ * @ctxp:       Pointer to save the point to the newly created context
+ * @targetp:    Pointer to save the point to the newly created target
+ */
+int damon_modules_new_paddr_ctx_target(struct damon_ctx **ctxp,
+				struct damon_target **targetp)
+{
+	return _damon_modules_new_ctx_target(ctxp, targetp, DAMON_OPS_PADDR);
+}
+
+/*
+ * Allocate, set, and return a DAMON context for the virtual address space.
+ * @ctxp:	Pointer to save the point to the newly created context
+ * @targetp:	Pointer to save the point to the newly created target
+ */
+int damon_modules_new_vaddr_ctx_target(struct damon_ctx **ctxp,
+				struct damon_target **targetp)
+{
+	return _damon_modules_new_ctx_target(ctxp, targetp, DAMON_OPS_VADDR);
+}
diff --git a/mm/damon/modules-common.h b/mm/damon/modules-common.h
index f103ad556368..324b9cb4957e 100644
--- a/mm/damon/modules-common.h
+++ b/mm/damon/modules-common.h
@@ -47,3 +47,6 @@
 
 int damon_modules_new_paddr_ctx_target(struct damon_ctx **ctxp,
 		struct damon_target **targetp);
+
+int damon_modules_new_vaddr_ctx_target(struct damon_ctx **ctxp,
+		struct damon_target **targetp);
-- 
2.43.0

Re: [RFC PATCH v3 2/4] mm/damon: Generalize ctx_target creation for damon_ops_id and add vaddr support

[SeongJae Park]

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

> From: Asier Gutierrez <gutierrez.asier@huawei-partners.com>
> 
> This patch adds a new function damon_modules_new_vaddr_ctx_target.
> Since ctx_target creation for vaddr and paddr is almost
> identical, the logic is extracted to a new function,
> damon_modules_new_ctx_target, and vaddr and paddr functions
> are left just as interfaces.
> 
> This change was suggested earlier1 and it is needed to allow
> developers to create DAMON modules that use DAMON_OPS_VADDR targets.
> 
> Signed-off-by: Asier Gutierrez <gutierrez.asier@huawei-partners.com>
> Suggested-by: SeongJae Park <sj@kernel.org>
> ---
>  mm/damon/modules-common.c | 31 +++++++++++++++++++++++++++----
>  mm/damon/modules-common.h |  3 +++
>  2 files changed, 30 insertions(+), 4 deletions(-)

This change is for the sample module that will be introduced by the third patch
of this series, right?

I'd like sample modules to be simple and completely isolated under sample/
directory.  Is this change really required for the sammple directory?  If not,
could we please drop this patch?


Thanks,
SJ

[...]

Re: [RFC PATCH v3 2/4] mm/damon: Generalize ctx_target creation for damon_ops_id and add vaddr support

[Gutierrez Asier]

On 6/5/2026 3:50 AM, SeongJae Park wrote:
> On Thu, 4 Jun 2026 15:03:35 +0000 <gutierrez.asier@huawei-partners.com> wrote:
> 
>> From: Asier Gutierrez <gutierrez.asier@huawei-partners.com>
>>
>> This patch adds a new function damon_modules_new_vaddr_ctx_target.
>> Since ctx_target creation for vaddr and paddr is almost
>> identical, the logic is extracted to a new function,
>> damon_modules_new_ctx_target, and vaddr and paddr functions
>> are left just as interfaces.
>>
>> This change was suggested earlier1 and it is needed to allow
>> developers to create DAMON modules that use DAMON_OPS_VADDR targets.
>>
>> Signed-off-by: Asier Gutierrez <gutierrez.asier@huawei-partners.com>
>> Suggested-by: SeongJae Park <sj@kernel.org>
>> ---
>>  mm/damon/modules-common.c | 31 +++++++++++++++++++++++++++----
>>  mm/damon/modules-common.h |  3 +++
>>  2 files changed, 30 insertions(+), 4 deletions(-)
> 
> This change is for the sample module that will be introduced by the third patch
> of this series, right?
> 
> I'd like sample modules to be simple and completely isolated under sample/
> directory.  Is this change really required for the sammple directory?  If not,
> could we please drop this patch?
So, just create the context manually in the module without a new
damon_modules_new_vaddr_ctx_target interface?> 
> Thanks,
> SJ
> 
> [...]
> 

-- 
Asier Gutierrez
Huawei

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

[gutierrez.asier]

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

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

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

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

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

Signed-off-by: Asier Gutierrez <gutierrez.asier@huawei-partners.com>
---
 mm/damon/Makefile              |   8 +-
 samples/damon/Kconfig          |  12 ++
 samples/damon/Makefile         |   2 +
 samples/damon/hugepage.c (new) | 350 +++++++++++++++++++++++++++++++++
 4 files changed, 368 insertions(+), 4 deletions(-)

diff --git a/mm/damon/Makefile b/mm/damon/Makefile
index d8d6bf5f8bff..16459ce40304 100644
--- a/mm/damon/Makefile
+++ b/mm/damon/Makefile
@@ -1,9 +1,9 @@
 # SPDX-License-Identifier: GPL-2.0
 
-obj-y				:= core.o
+obj-y				:= core.o modules-common.o
 obj-$(CONFIG_DAMON_VADDR)	+= ops-common.o vaddr.o
 obj-$(CONFIG_DAMON_PADDR)	+= ops-common.o paddr.o
 obj-$(CONFIG_DAMON_SYSFS)	+= sysfs-common.o sysfs-schemes.o sysfs.o
-obj-$(CONFIG_DAMON_RECLAIM)	+= modules-common.o reclaim.o
-obj-$(CONFIG_DAMON_LRU_SORT)	+= modules-common.o lru_sort.o
-obj-$(CONFIG_DAMON_STAT)	+= modules-common.o stat.o
+obj-$(CONFIG_DAMON_RECLAIM)	+= reclaim.o
+obj-$(CONFIG_DAMON_LRU_SORT)	+= lru_sort.o
+obj-$(CONFIG_DAMON_STAT)	+= stat.o
diff --git a/samples/damon/Kconfig b/samples/damon/Kconfig
index cbf96fd8a8bf..512f150aaabb 100644
--- a/samples/damon/Kconfig
+++ b/samples/damon/Kconfig
@@ -40,4 +40,16 @@ config SAMPLE_DAMON_MTIER
 
 	  If unsure, say N.
 
+config SAMPLE_DAMON_HUGEPAGE
+	bool "Build DAMON-based collapse of hot regions (SAMPLE_DAMON_HUGEPAGE)"
+	depends on DAMON && DAMON_VADDR
+	help
+	  This module monitors a certain PID provided by the user through
+	  monitored_pid attribute. Hot regions are determined by DAMON-based
+	  sampling. Collapsing occurs according to the quota goal using total
+	  memory usage to huge page usage ratio. The ratio is set by the user
+	  through a module attribute.
+
+	  If unsure, say N.
+
 endmenu
diff --git a/samples/damon/Makefile b/samples/damon/Makefile
index 72f68cbf422a..f90845faec85 100644
--- a/samples/damon/Makefile
+++ b/samples/damon/Makefile
@@ -3,3 +3,5 @@
 obj-$(CONFIG_SAMPLE_DAMON_WSSE) += wsse.o
 obj-$(CONFIG_SAMPLE_DAMON_PRCL) += prcl.o
 obj-$(CONFIG_SAMPLE_DAMON_MTIER) += mtier.o
+obj-$(CONFIG_SAMPLE_DAMON_HUGEPAGE)	+= hugepage.o
+ccflags-$(CONFIG_SAMPLE_DAMON_HUGEPAGE)	+= -I$(srctree)/mm/damon
diff --git a/samples/damon/hugepage.c b/samples/damon/hugepage.c
new file mode 100644
index 000000000000..e24562c92348
--- /dev/null
+++ b/samples/damon/hugepage.c
@@ -0,0 +1,350 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (C) 2026 HUAWEI, Inc.
+ *             https://www.huawei.com
+ *
+ * Author: Asier Gutierrez <gutierrez.asier@huawei-partners.com>
+ */
+
+#define pr_fmt(fmt) "damon-hugepage: " fmt
+
+#include <linux/damon.h>
+#include <linux/kstrtox.h>
+#include <linux/module.h>
+
+#include "modules-common.h"
+
+#ifdef MODULE_PARAM_PREFIX
+#undef MODULE_PARAM_PREFIX
+#endif
+#define MODULE_PARAM_PREFIX "damon_hugepage."
+
+/*
+ * Enable or disable DAMON_HUGEPAGE.
+ *
+ * You can enable DAMON_HUGEPAGE by setting the value of this parameter
+ * as ``Y``. Setting it as ``N`` disables DAMON_HUGEPAGE.
+ */
+static bool enabled __read_mostly;
+
+/*
+ * Make DAMON_HUGEPAGE reads the input parameters again, except ``enabled``.
+ *
+ * Input parameters that updated while DAMON_HUGEPAGE is running are not applied
+ * by default.  Once this parameter is set as ``Y``, DAMON_HUGEPAGE reads values
+ * of parametrs except ``enabled`` again.  Once the re-reading is done, this
+ * parameter is set as ``N``.  If invalid parameters are found while the
+ * re-reading, DAMON_HUGEPAGE will be disabled.
+ */
+static bool commit_inputs __read_mostly;
+module_param(commit_inputs, bool, 0600);
+
+/*
+ * Scale factor for DAMON_HUGEPAGE to ops address conversion.
+ *
+ * This parameter must not be set to 0.
+ */
+static unsigned long addr_unit __read_mostly = 1;
+
+static unsigned long monitored_pid;
+module_param(monitored_pid, ulong, 0600);
+
+/*
+ * Time threshold for hot memory regions identification in microseconds.
+ *
+ * If a memory region has been accessed for this or longer time,
+ * DAMON_HUGEPAGE identifies the region as hot, and collapse it into a huge
+ * page.  100 microseconds by default.
+ */
+static unsigned long min_age __read_mostly = 100000;
+module_param(min_age, ulong, 0600);
+
+static struct damos_quota damon_hugepage_quota = {
+	/* use up to 10 ms time, collapse up to 128 MiB per 1 sec by default */
+	.ms = 10,
+	.sz = 128 * 1024 * 1024,
+	.reset_interval = 1000,
+	.weight_sz = 0,
+	.weight_nr_accesses = 1,
+	.weight_age = 1
+};
+DEFINE_DAMON_MODULES_DAMOS_QUOTAS(damon_hugepage_quota);
+
+
+/*
+ * Desired ratio of huge pages use vs total anonymous memory usage.
+ *
+ * While keeping the caps that set by other quotas, DAMON_HUGEPAGE automatically
+ * increases and decreases the effective level of the quota to achieve the
+ * desired ratio.
+ *
+ * 100 bp by default.
+ */
+static unsigned long quota_percentage_hugepage __read_mostly = 100;
+module_param(quota_percentage_hugepage, ulong, 0600);
+
+/*
+ * User-specifiable feedback for auto-tuning of the effective quota.
+ *
+ * While keeping the caps that set by other quotas, DAMON_HUGEPAGE automatically
+ * increases and decreases the effective level of the quota aiming receiving this
+ * feedback of value ``10,000`` from the user.  DAMON_HUGEPAGE assumes the feedback
+ * value and the quota are positively proportional.  Value zero means disabling
+ * this auto-tuning feature.
+ *
+ * Disabled by default.
+ *
+ */
+static unsigned long quota_autotune_feedback __read_mostly;
+module_param(quota_autotune_feedback, ulong, 0600);
+
+/*
+ * PID of the DAMON thread
+ *
+ * If DAMON_HUGEPAGE is enabled, this becomes the PID of the worker thread.
+ * Else, -1.
+ */
+static int kdamond_pid __read_mostly = -1;
+module_param(kdamond_pid, int, 0400);
+
+static struct damos_stat damon_hugepage_stat;
+DEFINE_DAMON_MODULES_DAMOS_STATS_PARAMS(damon_hugepage_stat,
+		hugepage_tried_regions, hugepage_regions, quota_exceeds);
+
+static struct damon_attrs damon_hugepage_mon_attrs = {
+	.sample_interval = 5 * USEC_PER_MSEC,
+	.aggr_interval = 100 * USEC_PER_MSEC,
+	.ops_update_interval = 60 * USEC_PER_MSEC * MSEC_PER_SEC,
+	.min_nr_regions = 10,
+	.max_nr_regions = 1000,
+};
+DEFINE_DAMON_MODULES_MON_ATTRS_PARAMS(damon_hugepage_mon_attrs);
+
+static struct damon_ctx *ctx;
+static struct damon_target *target;
+
+static struct damos *damon_hugepage_new_scheme(void)
+{
+	struct damos_access_pattern pattern = {
+		/* Find regions having PMD_SIZE or larger size */
+		.min_sz_region = PMD_SIZE,
+		.max_sz_region = ULONG_MAX,
+		.min_nr_accesses = 0,
+		.max_nr_accesses = UINT_MAX,
+		.min_age_region = min_age /
+			damon_hugepage_mon_attrs.aggr_interval,
+		.max_age_region = UINT_MAX,
+	};
+
+	return damon_new_scheme(
+		&pattern,
+		/* synchrounous partial collapse as soon as found */
+		DAMOS_COLLAPSE, 0,
+		/* under the quota. */
+		&damon_hugepage_quota,
+		&(struct damos_watermarks){}, NUMA_NO_NODE);
+}
+
+static int damon_hugepage_apply_parameters(void)
+{
+	struct damon_ctx *param_ctx;
+	struct damon_target *param_target;
+	struct damos *scheme;
+	struct damos_quota_goal *goal;
+	struct pid *spid;
+	int err;
+
+	err = damon_modules_new_vaddr_ctx_target(&param_ctx, &param_target);
+	if (err)
+		return err;
+
+	param_ctx->addr_unit = addr_unit;
+    // align power of two
+	param_ctx->min_region_sz = max(DAMON_MIN_REGION_SZ / ALIGN(addr_unit, 2), 1);
+
+	spid = find_get_pid(monitored_pid);
+	if (!spid) {
+		err = -EINVAL;
+		goto out;
+	}
+
+	param_target->pid = spid;
+
+	if (!damon_hugepage_mon_attrs.aggr_interval) {
+		err = -EINVAL;
+		goto out;
+	}
+
+	err = damon_set_attrs(param_ctx, &damon_hugepage_mon_attrs);
+	if (err)
+		goto out;
+
+	err = -ENOMEM;
+	scheme = damon_hugepage_new_scheme();
+	if (!scheme)
+		goto out;
+	damon_set_schemes(param_ctx, &scheme, 1);
+
+	goal = damos_new_quota_goal(DAMOS_QUOTA_HUGEPAGE, quota_percentage_hugepage);
+	if (!goal)
+		goto out;
+	damos_add_quota_goal(&scheme->quota, goal);
+
+	if (quota_autotune_feedback) {
+		goal = damos_new_quota_goal(DAMOS_QUOTA_USER_INPUT, 10000);
+		if (!goal)
+			goto out;
+		goal->current_value = quota_autotune_feedback;
+		damos_add_quota_goal(&scheme->quota, goal);
+	}
+
+	err = damon_commit_ctx(ctx, param_ctx);
+out:
+	damon_destroy_ctx(param_ctx);
+	return err;
+}
+
+static int damon_hugepage_handle_commit_inputs(void)
+{
+	int err;
+
+	if (!commit_inputs)
+		return 0;
+
+	err = damon_hugepage_apply_parameters();
+	commit_inputs = false;
+	return err;
+}
+
+static int damon_hugepage_damon_call_fn(void *arg)
+{
+	struct damon_ctx *c = arg;
+	struct damos *s;
+
+	/* update the stats parameter */
+	damon_for_each_scheme(s, c)
+		damon_hugepage_stat = s->stat;
+
+	return damon_hugepage_handle_commit_inputs();
+}
+
+static struct damon_call_control call_control = {
+	.fn = damon_hugepage_damon_call_fn,
+	.repeat = true,
+};
+
+static int damon_hugepage_turn(bool on)
+{
+	int err;
+
+	if (!on) {
+		err = damon_stop(&ctx, 1);
+		if (!err)
+			kdamond_pid = -1;
+		return err;
+	}
+
+	err = damon_hugepage_apply_parameters();
+	if (err)
+		return err;
+
+	err = damon_start(&ctx, 1, true);
+	if (err)
+		return err;
+	kdamond_pid = damon_kdamond_pid(ctx);
+	if (kdamond_pid < 0)
+		return kdamond_pid;
+	return damon_call(ctx, &call_control);
+}
+
+static int damon_hugepage_addr_unit_store(const char *val,
+		const struct kernel_param *kp)
+{
+	unsigned long input_addr_unit;
+	int err = kstrtoul(val, 0, &input_addr_unit);
+
+	if (err)
+		return err;
+	if (!input_addr_unit)
+		return -EINVAL;
+
+	addr_unit = input_addr_unit;
+	return 0;
+}
+
+static const struct kernel_param_ops addr_unit_param_ops = {
+	.set = damon_hugepage_addr_unit_store,
+	.get = param_get_ulong,
+};
+
+module_param_cb(addr_unit, &addr_unit_param_ops, &addr_unit, 0600);
+MODULE_PARM_DESC(addr_unit,
+	"Scale factor for DAMON_HUGEPAGE to ops address conversion (default: 1)");
+
+static int damon_hugepage_enabled_store(const char *val,
+				const struct kernel_param *kp)
+{
+	bool is_enabled = enabled;
+	bool enable;
+	int err;
+
+	err = kstrtobool(val, &enable);
+	if (err)
+		return err;
+
+	if (is_enabled == enable)
+		return 0;
+
+	/* Monitored process may have exited. In that case, ctx->kdamon is set */
+	/* to NULL. If enabled is set to 'off' through sysfs, we just set the  */
+	/* params and exit */
+	if (!damon_is_running(ctx) && !enable)
+		goto set_param_out;
+
+	/* Called before init function.  The function will handle this. */
+	if (!damon_initialized())
+		goto set_param_out;
+
+	err = damon_hugepage_turn(enable);
+	if (err)
+		return err;
+
+set_param_out:
+	enabled = enable;
+	return err;
+}
+
+static const struct kernel_param_ops enabled_param_ops = {
+	.set = damon_hugepage_enabled_store,
+	.get = param_get_bool,
+};
+
+module_param_cb(enabled, &enabled_param_ops, &enabled, 0600);
+MODULE_PARM_DESC(enabled,
+	"Enable or disable DAMON_HUGEPAGE (default: disabled)");
+
+static int __init damon_hugepage_init(void)
+{
+	int err;
+
+	if (!damon_initialized()) {
+		err = -ENOMEM;
+		goto out;
+	}
+	err = damon_modules_new_vaddr_ctx_target(&ctx, &target);
+	if (err)
+		goto out;
+
+	call_control.data = ctx;
+
+	/* 'enabled' has set before this function, probably via command line */
+	if (enabled)
+		err = damon_hugepage_turn(true);
+
+out:
+	if (err && enabled)
+		enabled = false;
+	return err;
+}
+
+module_init(damon_hugepage_init);
-- 
2.43.0

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

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 5 potential issue(s) to consider:
- [High] A Time-of-Check to Time-of-Use (TOCTOU) race condition in damon_hugepage_apply_parameters() can lead to a division by zero kernel panic.
- [High] Writing to the enabled sysfs node or passing it as a load parameter before module_init finishes causes an immediate NULL pointer dereference.
- [High] The sysfs parameter addr_unit can be set to ULONG_MAX, leading to an integer overflow in the ALIGN macro and a division by zero kernel panic.
- [Medium] Misuse of ALIGN() produces a non-power-of-two min_region_sz, silently breaking the monitoring daemon.
- [Low] The addr_unit module parameter is exposed and documented for address translation, but is entirely ignored by VADDR operations.
--

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

mm/damon: introduce DAMON_HUGEPAGE for hot region hugepage collapsing

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

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

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

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

> diff --git a/samples/damon/hugepage.c b/samples/damon/hugepage.c
> new file mode 100644
> --- /dev/null
> +++ b/samples/damon/hugepage.c
> @@ -0,0 +1,350 @@
[ ... ]
> +static struct damos *damon_hugepage_new_scheme(void)
> +{
> +	struct damos_access_pattern pattern = {
> +		/* Find regions having PMD_SIZE or larger size */
> +		.min_sz_region = PMD_SIZE,
> +		.max_sz_region = ULONG_MAX,
> +		.min_nr_accesses = 0,
> +		.max_nr_accesses = UINT_MAX,
> +		.min_age_region = min_age /
> +			damon_hugepage_mon_attrs.aggr_interval,

[Severity: High]
Since damon_hugepage_mon_attrs.aggr_interval is a module parameter that can be
modified concurrently without locks, could it be set to zero exactly between
the zero-check in damon_hugepage_apply_parameters() and this division?

If a privileged user writes 0 to the sysfs node in that time window, it would
trigger a division by zero kernel panic.

> +		.max_age_region = UINT_MAX,
> +	};
> +
> +	return damon_new_scheme(
[ ... ]
> +static int damon_hugepage_apply_parameters(void)
> +{
> +	struct damon_ctx *param_ctx;
> +	struct damon_target *param_target;
> +	struct damos *scheme;
> +	struct damos_quota_goal *goal;
> +	struct pid *spid;
> +	int err;
> +
> +	err = damon_modules_new_vaddr_ctx_target(&param_ctx, &param_target);
> +	if (err)
> +		return err;
> +
> +	param_ctx->addr_unit = addr_unit;
> +    // align power of two
> +	param_ctx->min_region_sz = max(DAMON_MIN_REGION_SZ / ALIGN(addr_unit, 2), 1);

[Severity: High]
Does this ALIGN() macro expose us to an integer overflow if a user sets
addr_unit to ULONG_MAX?

The macro adds (2 - 1) before masking, which would overflow ULONG_MAX to 0,
making the evaluation 0. This leads to a division by zero panic on
DAMON_MIN_REGION_SZ / 0.

[Severity: Medium]
Will this ALIGN(addr_unit, 2) calculation produce a non-power-of-two result
if addr_unit is set to a value like 6?

ALIGN(6, 2) evaluates to 6, and damon_commit_ctx() strictly requires
min_region_sz to be a power of two. If it isn't, damon_commit_ctx()
returns -EINVAL and flags the context as maybe_corrupted, which silently
terminates the kdamond background thread.

Should this use roundup_pow_of_two() instead?

> +
> +	spid = find_get_pid(monitored_pid);
[ ... ]
> +static const struct kernel_param_ops addr_unit_param_ops = {
> +	.set = damon_hugepage_addr_unit_store,
> +	.get = param_get_ulong,
> +};
> +
> +module_param_cb(addr_unit, &addr_unit_param_ops, &addr_unit, 0600);
> +MODULE_PARM_DESC(addr_unit,
> +	"Scale factor for DAMON_HUGEPAGE to ops address conversion (default: 1)");

[Severity: Low]
Is this parameter accurately described for VADDR operations?

The DAMON core explicitly ignores addr_unit for VADDR operations. Exposing
this parameter does not scale addresses as documented, but it does improperly
shrink the byte-granularity of min_region_sz, creating a misleading user API.

> +
> +static int damon_hugepage_enabled_store(const char *val,
> +				const struct kernel_param *kp)
> +{
> +	bool is_enabled = enabled;
> +	bool enable;
> +	int err;
> +
> +	err = kstrtobool(val, &enable);
> +	if (err)
> +		return err;
> +
> +	if (is_enabled == enable)
> +		return 0;
> +
> +	/* Monitored process may have exited. In that case, ctx->kdamon is set */
> +	/* to NULL. If enabled is set to 'off' through sysfs, we just set the  */
> +	/* params and exit */
> +	if (!damon_is_running(ctx) && !enable)

[Severity: High]
Can this crash on boot or module load?

If the parameter damon_hugepage.enabled=Y is passed at boot or module load,
this store callback executes before the module's init function runs. Because
the init function hasn't run, the global ctx pointer is NULL here.

The left-hand side of the condition calls damon_is_running(ctx), which
unconditionally dereferences the NULL pointer at mutex_lock(&ctx->kdamond_lock),
causing a kernel panic.

> +		goto set_param_out;
> +
> +	/* Called before init function.  The function will handle this. */
> +	if (!damon_initialized())
> +		goto set_param_out;

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

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

[Gutierrez Asier]

On 6/4/2026 6:41 PM, sashiko-bot@kernel.org wrote:
> Thank you for your contribution! Sashiko AI review found 5 potential issue(s) to consider:
> - [High] A Time-of-Check to Time-of-Use (TOCTOU) race condition in damon_hugepage_apply_parameters() can lead to a division by zero kernel panic.
> - [High] Writing to the enabled sysfs node or passing it as a load parameter before module_init finishes causes an immediate NULL pointer dereference.
> - [High] The sysfs parameter addr_unit can be set to ULONG_MAX, leading to an integer overflow in the ALIGN macro and a division by zero kernel panic.
> - [Medium] Misuse of ALIGN() produces a non-power-of-two min_region_sz, silently breaking the monitoring daemon.
> - [Low] The addr_unit module parameter is exposed and documented for address translation, but is entirely ignored by VADDR operations.
> --
> 
> commit 3617a4956285835faa63e992e7cc7a6aa7cb4d8d
> Author: Asier Gutierrez <gutierrez.asier@huawei-partners.com>
> 
> mm/damon: introduce DAMON_HUGEPAGE for hot region hugepage collapsing
> 
> This patch introduces a new DAMON module (SAMPLE_DAMON_HUGEPAGE)
> which collapses hot regions into huge pages.
> 
> SAMPLE_DAMON_HUGEPAGE operates in the virtual memory space, for a
> specific task. The user is expected to supply the PID of the task
> that is going to be monitored through the monitored_pid module
> variable.
> 
> SAMPLE_DAMON_HUGEPAGE uses the hugepage auto-tune mechanism to
> increase or decrease the aggressiveness of page collapsing. User
> autotuning is also available for additional tuning aggressiveness
> control.
> 
> The module also includes changes to the DAMON compilation, so that
> the module can be enabled or disabled.
> 
>> diff --git a/samples/damon/hugepage.c b/samples/damon/hugepage.c
>> new file mode 100644
>> --- /dev/null
>> +++ b/samples/damon/hugepage.c
>> @@ -0,0 +1,350 @@
> [ ... ]
>> +static struct damos *damon_hugepage_new_scheme(void)
>> +{
>> +	struct damos_access_pattern pattern = {
>> +		/* Find regions having PMD_SIZE or larger size */
>> +		.min_sz_region = PMD_SIZE,
>> +		.max_sz_region = ULONG_MAX,
>> +		.min_nr_accesses = 0,
>> +		.max_nr_accesses = UINT_MAX,
>> +		.min_age_region = min_age /
>> +			damon_hugepage_mon_attrs.aggr_interval,
> 
> [Severity: High]
> Since damon_hugepage_mon_attrs.aggr_interval is a module parameter that can be
> modified concurrently without locks, could it be set to zero exactly between
> the zero-check in damon_hugepage_apply_parameters() and this division?
> 
> If a privileged user writes 0 to the sysfs node in that time window, it would
> trigger a division by zero kernel panic.
Changes to the modules should always be made using the commit parameter.
>> +		.max_age_region = UINT_MAX,
>> +	};
>> +
>> +	return damon_new_scheme(
> [ ... ]
>> +static int damon_hugepage_apply_parameters(void)
>> +{
>> +	struct damon_ctx *param_ctx;
>> +	struct damon_target *param_target;
>> +	struct damos *scheme;
>> +	struct damos_quota_goal *goal;
>> +	struct pid *spid;
>> +	int err;
>> +
>> +	err = damon_modules_new_vaddr_ctx_target(&param_ctx, &param_target);
>> +	if (err)
>> +		return err;
>> +
>> +	param_ctx->addr_unit = addr_unit;
>> +    // align power of two
>> +	param_ctx->min_region_sz = max(DAMON_MIN_REGION_SZ / ALIGN(addr_unit, 2), 1);
> 
> [Severity: High]
> Does this ALIGN() macro expose us to an integer overflow if a user sets
> addr_unit to ULONG_MAX?
> 
> The macro adds (2 - 1) before masking, which would overflow ULONG_MAX to 0,
> making the evaluation 0. This leads to a division by zero panic on
> DAMON_MIN_REGION_SZ / 0.
> 
> [Severity: Medium]
> Will this ALIGN(addr_unit, 2) calculation produce a non-power-of-two result
> if addr_unit is set to a value like 6?
> 
> ALIGN(6, 2) evaluates to 6, and damon_commit_ctx() strictly requires
> min_region_sz to be a power of two. If it isn't, damon_commit_ctx()
> returns -EINVAL and flags the context as maybe_corrupted, which silently
> terminates the kdamond background thread.
> 
> Should this use roundup_pow_of_two() instead?
Since VADDR doesn't use addr_unit, I will just simplify this line
in the next RFC patch.
>> +
>> +	spid = find_get_pid(monitored_pid);
> [ ... ]
>> +static const struct kernel_param_ops addr_unit_param_ops = {
>> +	.set = damon_hugepage_addr_unit_store,
>> +	.get = param_get_ulong,
>> +};
>> +
>> +module_param_cb(addr_unit, &addr_unit_param_ops, &addr_unit, 0600);
>> +MODULE_PARM_DESC(addr_unit,
>> +	"Scale factor for DAMON_HUGEPAGE to ops address conversion (default: 1)");
> 
> [Severity: Low]
> Is this parameter accurately described for VADDR operations?
> 
> The DAMON core explicitly ignores addr_unit for VADDR operations. Exposing
> this parameter does not scale addresses as documented, but it does improperly
> shrink the byte-granularity of min_region_sz, creating a misleading user API.
I will remove addr_unit.
>> +
>> +static int damon_hugepage_enabled_store(const char *val,
>> +				const struct kernel_param *kp)
>> +{
>> +	bool is_enabled = enabled;
>> +	bool enable;
>> +	int err;
>> +
>> +	err = kstrtobool(val, &enable);
>> +	if (err)
>> +		return err;
>> +
>> +	if (is_enabled == enable)
>> +		return 0;
>> +
>> +	/* Monitored process may have exited. In that case, ctx->kdamon is set */
>> +	/* to NULL. If enabled is set to 'off' through sysfs, we just set the  */
>> +	/* params and exit */
>> +	if (!damon_is_running(ctx) && !enable)
> 
> [Severity: High]
> Can this crash on boot or module load?
> 
> If the parameter damon_hugepage.enabled=Y is passed at boot or module load,
> this store callback executes before the module's init function runs. Because
> the init function hasn't run, the global ctx pointer is NULL here.
> 
> The left-hand side of the condition calls damon_is_running(ctx), which
> unconditionally dereferences the NULL pointer at mutex_lock(&ctx->kdamond_lock),
> causing a kernel panic.
This is a sample module. It's not meant to be started at boot time.
>> +		goto set_param_out;
>> +
>> +	/* Called before init function.  The function will handle this. */
>> +	if (!damon_initialized())
>> +		goto set_param_out;
> 

-- 
Asier Gutierrez
Huawei

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

[SeongJae Park]

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

> From: Asier Gutierrez <gutierrez.asier@huawei-partners.com>
> 
> This patch introduces a new DAMON module (SAMPLE_DAMON_HUGEPAGE)

Could we make the name shorter, to look more consistent with other sample
modules?  E.g., SAMPLE_DAMON_HPAGE?

> which collapses hot regions into huge pages.
> 
> SAMPLE_DAMON_HUGEPAGE operates in the virtual memory space, for a
> specific task. The user is expected to supply the PID of the task
> that is going to be monitored through the monitored_pid module
> variable.
> 
> SAMPLE_DAMON_HUGEPAGE uses the hugepage auto-tune mechanism to
> increase or decrease the aggressiveness of page collapsing. User
> autotuning is also available for additional tuning aggressiveness
> control.
> 
> The module also includes changes to the DAMON compilation, so that
> the module can be enabled or disabled.
> 
> Signed-off-by: Asier Gutierrez <gutierrez.asier@huawei-partners.com>
> ---
>  mm/damon/Makefile              |   8 +-
>  samples/damon/Kconfig          |  12 ++
>  samples/damon/Makefile         |   2 +
>  samples/damon/hugepage.c (new) | 350 +++++++++++++++++++++++++++++++++
>  4 files changed, 368 insertions(+), 4 deletions(-)
> 
> diff --git a/mm/damon/Makefile b/mm/damon/Makefile
> index d8d6bf5f8bff..16459ce40304 100644
> --- a/mm/damon/Makefile
> +++ b/mm/damon/Makefile
> @@ -1,9 +1,9 @@
>  # SPDX-License-Identifier: GPL-2.0
>  
> -obj-y				:= core.o
> +obj-y				:= core.o modules-common.o
>  obj-$(CONFIG_DAMON_VADDR)	+= ops-common.o vaddr.o
>  obj-$(CONFIG_DAMON_PADDR)	+= ops-common.o paddr.o
>  obj-$(CONFIG_DAMON_SYSFS)	+= sysfs-common.o sysfs-schemes.o sysfs.o
> -obj-$(CONFIG_DAMON_RECLAIM)	+= modules-common.o reclaim.o
> -obj-$(CONFIG_DAMON_LRU_SORT)	+= modules-common.o lru_sort.o
> -obj-$(CONFIG_DAMON_STAT)	+= modules-common.o stat.o
> +obj-$(CONFIG_DAMON_RECLAIM)	+= reclaim.o
> +obj-$(CONFIG_DAMON_LRU_SORT)	+= lru_sort.o
> +obj-$(CONFIG_DAMON_STAT)	+= stat.o

This is for letting the new sample module use the code in ops-common.o, right?
I'd like to keep sample modules simple and isolated under samples/ directory.
Could you please make the sample module simpler and remove the above change?

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

Can this be more consistent with other sample modules?  E.g.,

DAMON sample module for auto-tuned THP collapsing ?

> +	depends on DAMON && DAMON_VADDR
> +	help
> +	  This module monitors a certain PID provided by the user through
> +	  monitored_pid attribute. Hot regions are determined by DAMON-based
> +	  sampling. Collapsing occurs according to the quota goal using total
> +	  memory usage to huge page usage ratio. The ratio is set by the user
> +	  through a module attribute.
> +
> +	  If unsure, say N.
> +
>  endmenu
> diff --git a/samples/damon/Makefile b/samples/damon/Makefile
> index 72f68cbf422a..f90845faec85 100644
> --- a/samples/damon/Makefile
> +++ b/samples/damon/Makefile
> @@ -3,3 +3,5 @@
>  obj-$(CONFIG_SAMPLE_DAMON_WSSE) += wsse.o
>  obj-$(CONFIG_SAMPLE_DAMON_PRCL) += prcl.o
>  obj-$(CONFIG_SAMPLE_DAMON_MTIER) += mtier.o
> +obj-$(CONFIG_SAMPLE_DAMON_HUGEPAGE)	+= hugepage.o
> +ccflags-$(CONFIG_SAMPLE_DAMON_HUGEPAGE)	+= -I$(srctree)/mm/damon

As I mentioned above, let's not mix samples/ with mm/damon/

> diff --git a/samples/damon/hugepage.c b/samples/damon/hugepage.c
> new file mode 100644
> index 000000000000..e24562c92348
> --- /dev/null
> +++ b/samples/damon/hugepage.c
> @@ -0,0 +1,350 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Copyright (C) 2026 HUAWEI, Inc.
> + *             https://www.huawei.com
> + *
> + * Author: Asier Gutierrez <gutierrez.asier@huawei-partners.com>
> + */
> +
> +#define pr_fmt(fmt) "damon-hugepage: " fmt

Apparently this module's source code is following patterns of reclaim.c and
lru_sort.c.  That's for non-sample modules.  Could you please rewrite this
sample module following patterns in sample modules, like that for wsse.c or
prcl.c ?


Thanks,
SJ

[...]

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

[Gutierrez Asier]

On 6/5/2026 4:06 AM, SeongJae Park wrote:
> On Thu, 4 Jun 2026 15:03:36 +0000 <gutierrez.asier@huawei-partners.com> wrote:
> 
>> From: Asier Gutierrez <gutierrez.asier@huawei-partners.com>
>>
>> This patch introduces a new DAMON module (SAMPLE_DAMON_HUGEPAGE)
> 
> Could we make the name shorter, to look more consistent with other sample
> modules?  E.g., SAMPLE_DAMON_HPAGE?
> 
OK, I will change the name.
>> which collapses hot regions into huge pages.
>>
>> SAMPLE_DAMON_HUGEPAGE operates in the virtual memory space, for a
>> specific task. The user is expected to supply the PID of the task
>> that is going to be monitored through the monitored_pid module
>> variable.
>>
>> SAMPLE_DAMON_HUGEPAGE uses the hugepage auto-tune mechanism to
>> increase or decrease the aggressiveness of page collapsing. User
>> autotuning is also available for additional tuning aggressiveness
>> control.
>>
>> The module also includes changes to the DAMON compilation, so that
>> the module can be enabled or disabled.
>>
>> Signed-off-by: Asier Gutierrez <gutierrez.asier@huawei-partners.com>
>> ---
>>  mm/damon/Makefile              |   8 +-
>>  samples/damon/Kconfig          |  12 ++
>>  samples/damon/Makefile         |   2 +
>>  samples/damon/hugepage.c (new) | 350 +++++++++++++++++++++++++++++++++
>>  4 files changed, 368 insertions(+), 4 deletions(-)
>>
>> diff --git a/mm/damon/Makefile b/mm/damon/Makefile
>> index d8d6bf5f8bff..16459ce40304 100644
>> --- a/mm/damon/Makefile
>> +++ b/mm/damon/Makefile
>> @@ -1,9 +1,9 @@
>>  # SPDX-License-Identifier: GPL-2.0
>>  
>> -obj-y				:= core.o
>> +obj-y				:= core.o modules-common.o
>>  obj-$(CONFIG_DAMON_VADDR)	+= ops-common.o vaddr.o
>>  obj-$(CONFIG_DAMON_PADDR)	+= ops-common.o paddr.o
>>  obj-$(CONFIG_DAMON_SYSFS)	+= sysfs-common.o sysfs-schemes.o sysfs.o
>> -obj-$(CONFIG_DAMON_RECLAIM)	+= modules-common.o reclaim.o
>> -obj-$(CONFIG_DAMON_LRU_SORT)	+= modules-common.o lru_sort.o
>> -obj-$(CONFIG_DAMON_STAT)	+= modules-common.o stat.o
>> +obj-$(CONFIG_DAMON_RECLAIM)	+= reclaim.o
>> +obj-$(CONFIG_DAMON_LRU_SORT)	+= lru_sort.o
>> +obj-$(CONFIG_DAMON_STAT)	+= stat.o
> 
> This is for letting the new sample module use the code in ops-common.o, right?
> I'd like to keep sample modules simple and isolated under samples/ directory.
> Could you please make the sample module simpler and remove the above change?
> 
Correct. To be honest, I didn't know it this was the correct way to do it.
Thanks for the feedback, I will just create the context manually in the
module.
>> diff --git a/samples/damon/Kconfig b/samples/damon/Kconfig
>> index cbf96fd8a8bf..512f150aaabb 100644
>> --- a/samples/damon/Kconfig
>> +++ b/samples/damon/Kconfig
>> @@ -40,4 +40,16 @@ config SAMPLE_DAMON_MTIER
>>  
>>  	  If unsure, say N.
>>  
>> +config SAMPLE_DAMON_HUGEPAGE
>> +	bool "Build DAMON-based collapse of hot regions (SAMPLE_DAMON_HUGEPAGE)"
> 
> Can this be more consistent with other sample modules?  E.g.,
> 
> DAMON sample module for auto-tuned THP collapsing ?
As mentioned before, I will change the name.
> 
>> +	depends on DAMON && DAMON_VADDR
>> +	help
>> +	  This module monitors a certain PID provided by the user through
>> +	  monitored_pid attribute. Hot regions are determined by DAMON-based
>> +	  sampling. Collapsing occurs according to the quota goal using total
>> +	  memory usage to huge page usage ratio. The ratio is set by the user
>> +	  through a module attribute.
>> +
>> +	  If unsure, say N.
>> +
>>  endmenu
>> diff --git a/samples/damon/Makefile b/samples/damon/Makefile
>> index 72f68cbf422a..f90845faec85 100644
>> --- a/samples/damon/Makefile
>> +++ b/samples/damon/Makefile
>> @@ -3,3 +3,5 @@
>>  obj-$(CONFIG_SAMPLE_DAMON_WSSE) += wsse.o
>>  obj-$(CONFIG_SAMPLE_DAMON_PRCL) += prcl.o
>>  obj-$(CONFIG_SAMPLE_DAMON_MTIER) += mtier.o
>> +obj-$(CONFIG_SAMPLE_DAMON_HUGEPAGE)	+= hugepage.o
>> +ccflags-$(CONFIG_SAMPLE_DAMON_HUGEPAGE)	+= -I$(srctree)/mm/damon
> 
> As I mentioned above, let's not mix samples/ with mm/damon/
OK.
>> diff --git a/samples/damon/hugepage.c b/samples/damon/hugepage.c
>> new file mode 100644
>> index 000000000000..e24562c92348
>> --- /dev/null
>> +++ b/samples/damon/hugepage.c
>> @@ -0,0 +1,350 @@
>> +// SPDX-License-Identifier: GPL-2.0
>> +/*
>> + * Copyright (C) 2026 HUAWEI, Inc.
>> + *             https://www.huawei.com
>> + *
>> + * Author: Asier Gutierrez <gutierrez.asier@huawei-partners.com>
>> + */
>> +
>> +#define pr_fmt(fmt) "damon-hugepage: " fmt
> 
> Apparently this module's source code is following patterns of reclaim.c and
> lru_sort.c.  That's for non-sample modules.  Could you please rewrite this
> sample module following patterns in sample modules, like that for wsse.c or
> prcl.c ?
> 
Ok, I will do it.
> Thanks,
> SJ
> 
> [...]
> 

-- 
Asier Gutierrez
Huawei

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

[gutierrez.asier]

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

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

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

diff --git a/Documentation/admin-guide/mm/damon/hugepage.rst b/Documentation/admin-guide/mm/damon/hugepage.rst
new file mode 100644
index 000000000000..86104aaa4d1c
--- /dev/null
+++ b/Documentation/admin-guide/mm/damon/hugepage.rst
@@ -0,0 +1,271 @@
+================================
+DAMON-based huge page collapsing
+================================
+
+DAMON-based huge page collapsing (SAMPLE_DAMON_HUGEPAGE) is a static kernel
+module that aims to collapse hot regions into huge pages.
+
+Where Proactive huge page collapsing is Required?
+=================================================
+
+The amount of available memory grows faster than the amount of TLB entries.
+This leads to higher amount of TLB misses and excessive cycle wastes. Huge
+pages are meant to solve this problem. However, huge pages usually lead to
+memory fragmentation and memory waste.
+
+Collapsing selectively hot regions in a specific process can avoid big
+memory fragmentation, while increasing TLB performance.
+
+SAMPLE_DAMON_HUGEPAGE solves this by:
+
+- Identifying hot regions that have been accessed for a configured time
+- Automatically collapsing the regions into huge pages back
+- Auto tune the huge page usage ratio to meet desired targets
+- Controlling the collapse rate with configurable quotas to avoid performance
+  degradation
+
+
+How It Works?
+=============
+
+SAMPLE_DAMON_HUGEPAGE uses kdamond to identify anonymous memory regions that
+are:
+
+1. Large enough to be backed by huge pages (``PMD_SIZE`` or larger)
+2. Have been accessed for a configured time period
+
+Once identified, SAMPLE_DAMON_HUGEPAGE triggers synchronous partial collapse
+of those regions. The collapse operation is controlled by quotas to limit the
+impact on system performance.
+
+The module also supports automatic tuning of the collapse rate to achieve a
+desired huge page usage ratio. Administrators can configure a target percentage
+of huge page usage vs total anonymous memory usage.
+
+Additionally, the module accepts manual feedback from system administrators to
+adjust the effective quota level based on observed system behavior.
+
+Interface: Module Parameters
+============================
+
+To use this feature, you should first ensure your system is running on a kernel
+that is built with ``CONFIG_DAMON_HUGEPAGE=y``.
+
+To let sysadmins enable or disable it and tune for the given system,
+SAMPLE_DAMON_HUGEPAGE utilizes module parameters.  That is, you can put
+``damon_hugepage.<parameter>=<value>`` on the kernel boot command line or write
+proper values to ``/sys/module/damon_hugepage/parameters/<parameter>`` files.
+
+Below are the description of each parameter.
+
+enabled
+-------
+
+Enable or disable SAMPLE_DAMON_HUGEPAGE.
+
+You can enable SAMPLE_DAMON_HUGEPAGE by setting the value of this parameter as ``Y``.
+Setting it as ``N`` disables SAMPLE_DAMON_HUGEPAGE.  Note that SAMPLE_DAMON_HUGEPAGE
+could do no real monitoring and collapse due to the activation condition.
+
+commit_inputs
+-------------
+
+Make SAMPLE_DAMON_HUGEPAGE reads the input parameters again, except ``enabled``.
+
+Input parameters that updated while SAMPLE_DAMON_HUGEPAGE is running are
+not applied by default.  Once this parameter is set as ``Y``,
+SAMPLE_DAMON_HUGEPAGE reads values of parameters except ``enabled`` again.
+Once the re-reading is done, this parameter is set as ``N``.  If invalid
+parameters are found while the re-reading, SAMPLE_DAMON_HUGEPAGE will be
+disabled.
+
+Once ``Y`` is written to this parameter, the user must not write to any
+parameters until reading ``commit_inputs`` again returns ``N``.  If users
+violate this rule, the kernel may exhibit undefined behavior.
+
+min_age
+-------
+
+Time threshold for hot memory regions identification in microseconds.
+
+100 milliseconds by default.
+
+quota_ms
+--------
+
+Limit of time for the collapse in milliseconds.
+
+SAMPLE_DAMON_HUGEPAGE tries to use only up to this time within a time
+window (quota_reset_interval_ms) for trying collapse hot pages.  This can
+be used for limiting CPU consumption of SAMPLE_DAMON_HUGEPAGE.  If the
+value is zero, the limit is disabled.
+
+10 ms by default.
+
+quota_reset_interval_ms
+-----------------------
+
+The time/size quota charge reset interval in milliseconds.
+
+The charget reset interval for the quota of time (quota_ms) and size
+(quota_sz).  That is, SAMPLE_DAMON_HUGEPAGE does not try collapsing for
+more than quota_ms milliseconds or quota_sz bytes within
+quota_reset_interval_ms milliseconds.
+
+1 second by default.
+
+quota_sz
+--------
+
+Limit of size of memory for the reclamation in bytes.
+
+SAMPLE_DAMON_HUGEPAGE charges amount of memory which it tried to collapse
+regions into huge pages within a time window (quota_reset_interval_ms) and
+makes no more than this limit is tried. This can be used for limiting
+consumption of CPU and IO.  If this value is zero, the limit is disabled.
+
+128 MiB by default.
+
+quota_autotune_feedback
+-----------------------
+
+User-specifiable feedback for auto-tuning of the effective quota.
+
+While keeping the caps that set by other quotas, SAMPLE_DAMON_HUGEPAGE
+automatically increases and decreases the effective level of the quota
+aiming receiving this feedback of value ``10,000`` from the user.
+SAMPLE_DAMON_HUGEPAGE assumes the feedback value and the quota are positively
+proportional.  Value zero means disabling this auto-tuning feature.
+
+Disabled by default.
+
+monitored_pid
+----------------
+
+PID of the task that is going to be monitored for hot regions.
+
+quota_percentage_hugepage
+-------------------------
+
+Huge page consumption to total memory anonymous memory consumption ratio goal
+in bp ``(10,000)``. SAMPLE_DAMON_HUGEPAGE automatically increases and
+decreases page collapse aggressiveness in order to achieve the given value.
+
+sample_interval
+---------------
+
+Sampling interval for the monitoring in microseconds.
+
+The sampling interval of DAMON for the hot memory monitoring.  Please refer to
+the DAMON documentation (:doc:`usage`) for more detail.
+
+aggr_interval
+-------------
+
+Aggregation interval for the monitoring in microseconds.
+
+The aggregation interval of DAMON for the hot memory monitoring.  Please
+refer to the DAMON documentation (:doc:`usage`) for more detail.
+
+min_nr_regions
+--------------
+
+Minimum number of monitoring regions.
+
+The minimal number of monitoring regions of DAMON for the hot memory
+monitoring.  This can be used to set lower-bound of the monitoring quality.
+But, setting this too high could result in increased monitoring overhead.
+Please refer to the DAMON documentation (:doc:`usage`) for more detail.
+
+Note that this must be 3 or higher. Please refer to the :ref:`Monitoring
+<damon_design_monitoring>` section of the design document for the rationale
+behind this lower bound.
+
+max_nr_regions
+--------------
+
+Maximum number of monitoring regions.
+
+The maximum number of monitoring regions of DAMON for the cold memory
+monitoring.  This can be used to set upper-bound of the monitoring overhead.
+However, setting this too low could result in bad monitoring quality.  Please
+refer to the DAMON documentation (:doc:`usage`) for more detail.
+
+addr_unit
+---------
+
+A scale factor for memory addresses and bytes.
+
+This parameter is for setting and getting the :ref:`address unit
+<damon_design_addr_unit>` parameter of the DAMON instance for
+SAMPLE_DAMON_HUGEPAGE.
+
+``monitor_region_start`` and ``monitor_region_end`` should be provided in this
+unit.  For example, let's suppose ``addr_unit``, ``monitor_region_start`` and
+``monitor_region_end`` are set as ``1024``, ``0`` and ``10``, respectively.
+Then SAMPLE_DAMON_HUGEPAGE will work for 10 KiB length of physical address range
+that starts from address zero (``[0 * 1024, 10 * 1024)`` in bytes).
+
+``bytes_hugepage_tried_regions`` and ``bytes_hugepage_regions`` are also in
+this unit.  For example, let's suppose values of ``addr_unit``,
+``bytes_hugepage_tried_regions`` and ``bytes_hugepage_regions`` are
+``1048576``, ``42``, and ``32``, respectively.  Then it means
+SAMPLE_DAMON_HUGEPAGE tried to collapse 42 MiB memory and successfully collapse
+32 MiB memory in total.
+
+If unsure, use only the default value (``1``) and forget about this.
+
+
+kdamond_pid
+-----------
+
+PID of the DAMON thread.
+
+If SAMPLE_DAMON_HUGEPAGE is enabled, this becomes the PID of the worker thread.
+Else, -1.
+
+nr_hugepage_tried_regions
+-------------------------
+
+Number of memory regions that tried to be collapsed by SAMPLE_DAMON_HUGEPAGE.
+
+bytes_hugepage_tried_regions
+----------------------------
+
+Total bytes of memory regions that tried to be collapsed by SAMPLE_DAMON_HUGEPAGE.
+
+nr_hugepage_regions
+--------------------
+
+Number of memory regions that successfully be collapsed by SAMPLE_DAMON_HUGEPAGE.
+
+bytes_hugepage_regions
+-----------------------
+
+Total bytes of memory regions that successfully be collapsed by SAMPLE_DAMON_HUGEPAGE.
+
+nr_quota_exceeds
+----------------
+
+Number of times that the time/space quota limits have exceeded.
+
+Example
+=======
+
+Below runtime example commands make SAMPLE_DAMON_HUGEPAGE to find memory
+regions of  the task with PID 1234 that have been accessed in the last 100
+milliseconds or more and collpases those pages into huge pages. The page
+collapsing is limited to be done only up to 1 GiB per second to avoid
+SAMPLE_DAMON_HUGEPAGE consuming too much CPU time for the collapse operation. ::
+
+    # cd /sys/module/damon_hugepage/parameters
+    # echo 100000 > min_age
+    # echo $((1 * 1024 * 1024 * 1024)) > quota_sz
+    # echo 1000 > quota_reset_interval_ms
+    # echo 1234 > monitored_pid
+    # echo Y > enabled
+
+Note that this module (SAMPLE_DAMON_HUGEPAGE) cannot run simultaneously
+with other DAMON-based special-purpose modules.  Refer to
+ :ref:`DAMON design special purpose modules exclusivity
+ <damon_design_special_purpose_modules_exclusivity>` for more details.
\ No newline at end of file
-- 
2.43.0

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

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 4 potential issue(s) to consider:
- [Low] The newly added documentation file `hugepage.rst` is orphaned because it is not included in any Sphinx `toctree`.
- [Low] The documentation references an incorrect Kconfig symbol `CONFIG_DAMON_HUGEPAGE` instead of `CONFIG_SAMPLE_DAMON_HUGEPAGE`.
- [Low] Missing newline at the end of the newly added documentation file.
- [Low] Multiple spelling and grammatical errors in the newly added documentation.
--

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

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

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

[Severity: Low]
Is this new documentation file orphaned? It doesn't appear to be added to the
toctree in Documentation/admin-guide/mm/damon/index.rst.

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

[ ... ]

> +Interface: Module Parameters
> +============================
> +
> +To use this feature, you should first ensure your system is running on a kernel
> +that is built with ``CONFIG_DAMON_HUGEPAGE=y``.

[Severity: Low]
Does this reference the wrong Kconfig symbol? The module appears to be
SAMPLE_DAMON_HUGEPAGE, so should this be CONFIG_SAMPLE_DAMON_HUGEPAGE=y?

[ ... ]

> +commit_inputs
> +-------------
> +
> +Make SAMPLE_DAMON_HUGEPAGE reads the input parameters again, except ``enabled``.

[Severity: Low]
This isn't a bug, but should "reads" be "read" here?

> +
> +Input parameters that updated while SAMPLE_DAMON_HUGEPAGE is running are

[Severity: Low]
This isn't a bug, but should this be "parameters that are updated"?

[ ... ]

> +quota_reset_interval_ms
> +-----------------------
> +
> +The time/size quota charge reset interval in milliseconds.
> +
> +The charget reset interval for the quota of time (quota_ms) and size

[Severity: Low]
This isn't a bug, but there is a typo here ("charget" -> "charge").

[ ... ]

> +quota_autotune_feedback
> +-----------------------
> +
> +User-specifiable feedback for auto-tuning of the effective quota.
> +
> +While keeping the caps that set by other quotas, SAMPLE_DAMON_HUGEPAGE
> +automatically increases and decreases the effective level of the quota
> +aiming receiving this feedback of value ``10,000`` from the user.

[Severity: Low]
This isn't a bug, but should this be "aiming to receive"?

[ ... ]

> +Example
> +=======
> +
> +Below runtime example commands make SAMPLE_DAMON_HUGEPAGE to find memory
> +regions of  the task with PID 1234 that have been accessed in the last 100
> +milliseconds or more and collpases those pages into huge pages. The page

[Severity: Low]
This isn't a bug, but there is a typo here ("collpases" -> "collapses").

[ ... ]

> +Note that this module (SAMPLE_DAMON_HUGEPAGE) cannot run simultaneously
> +with other DAMON-based special-purpose modules.  Refer to
> + :ref:`DAMON design special purpose modules exclusivity
> + <damon_design_special_purpose_modules_exclusivity>` for more details.
> \ No newline at end of file

[Severity: Low]
This isn't a bug, but could we add a newline at the end of the file?

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

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

[SeongJae Park]

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

> From: Asier Gutierrez <gutierrez.asier@huawei-partners.com>
> 
> Add documentation for the DAMON-based Hugepage Management
> (SAMPLE_DAMON_HUGEPAGE) feature, which automatically manages
> huge pages by identifying hot memory regions and collapsing
> them back to regular pages. The documentation covers the
> module's features, operation, and all available module
> parameters.

For sample modules, I'd like the code to be simple enough to be able to
understand it without a dedicated documentation.  Apparntly this documentation
is made since you were following the pattern of non-sample modules like
reclaim.c and lru_sort.c.  Could you please make the sample module simpler and
drop this patch?


Thanks,
SJ

[...]

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

[Gutierrez Asier]

On 6/5/2026 4:09 AM, SeongJae Park wrote:
> On Thu, 4 Jun 2026 15:03:37 +0000 <gutierrez.asier@huawei-partners.com> wrote:
> 
>> From: Asier Gutierrez <gutierrez.asier@huawei-partners.com>
>>
>> Add documentation for the DAMON-based Hugepage Management
>> (SAMPLE_DAMON_HUGEPAGE) feature, which automatically manages
>> huge pages by identifying hot memory regions and collapsing
>> them back to regular pages. The documentation covers the
>> module's features, operation, and all available module
>> parameters.
> 
> For sample modules, I'd like the code to be simple enough to be able to
> understand it without a dedicated documentation.  Apparntly this documentation
> is made since you were following the pattern of non-sample modules like
> reclaim.c and lru_sort.c.  Could you please make the sample module simpler and
> drop this patch?

As mentioned in my reply to the cover letter, I will remove almost all
the module parameters to make it more simple.
 
> 
> Thanks,
> SJ
> 
> [...]
> 

-- 
Asier Gutierrez
Huawei

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

[SeongJae Park]

Hello Asier,


Thank you for revisioning this great patch!

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

> From: Asier Gutierrez <gutierrez.asier@huawei-partners.com>
> 
> Overview
> ========
> 
> This patch set introduces a new autotuning which allows to collapse
> hot regions into hugepages.
> 
> Motivation
> ==========
> 
> Since TLB is a bottleneck for many systems[1], a way to optimize TLB
> misses (or hits) is to use huge pages. Unfortunately, using "always"
> in THP leads to memory fragmentation and memory waste. For this reason,
> most application guides and system administrators suggest to disable THP.
> 
> Currently DAMON has DAMOS_HUGEPAGE, DAMOS_NONHUGEPAGE and DAMOS_COLLAPSE.
> However, there is no way to tune the settings. It will collapse all the
> hot regions that meet the access pattern. If the server is a bare metal
> database or big data server, this will also lead to eventual fragmentation.
> 
> Additionally, currently THP is set globally. Ideally, there should be a
> way to control which tasks can use huge pages.

We can do process level control using prctl(PR_SET_THP_DISABLE) [1], isn't it?
I think the last above sentence is better to be reworded or simply dropped.

> 
> 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_get_used_hugepage_mem_bp, is
> introduced, which checks the huge page consumption to total anonymous

In the previous revision I suggested to
s/damos_get_used_hugepage_mem_bp/damos_hugepage_mem_bp/ and you agreed.  Seems
it was forgotten?

> memory consumption. This new quota mechanism reuses current autotuning
> architecture.
> 
> A new module is introduced to demonstrate the use of huge pages

Let's clarify it is a  sample module.  That is,
s/A new module/A new sample module/ ?

> collapse autotuning. The goal is to collapse hot regions of a given
> process into huge pages. The module launches a kdamond thread for a
> certain task provided by the user through monitored_pid module argument.

Following other vaddr based sample modues' pattern, what about
s/monitored_pid/target_pid/ ?

As I also commented on the third patch of this series, apparently it is not
following the sample modules' pattern but that for non-sample modules.  Could
you please rewrite in a more simple way?

> Hugepage goal autotuning will automatically adjust the aggressiveness
> of hot region collapses.
> 
> This module also has a user autotuning knob which allows the user to
> adjust the aggressiveness of page collapsing.
> 
> Benchmarks
> ==========
> 
> Huge page collapse autotuning was tested in a physicial machine with
> MariaDB 10.5.29 and sysbench as the benchmark framework.
> 
> The hugepage module was set up in the following way:
> 
> # echo 1000 > min_age
> # echo 1000 > quota_percentage_hugepage
> # echo $(pidof mariadbd) > monitored_pid
> # echo on > enabled
> 
> The goal was to achieve 5% of the total memory used as hugepage.

Any reason to set it 5% ?

> 
> The table below shows the memory consumption over time. Gaps in the
> timestamp means that no changes in the hugepage consumption happened
> over that period of time.
> 
> +-----------+----------------+----------------+----------------------+
> | timestamp | total mem used | huge page used | percentage hugepage  |
> +-----------+----------------+----------------+----------------------+
> | 0         | 4721188        | 0              | 0%                   |
> | 28        | 4216848        | 4              | 0%                   |
> | 37        | 4189912        | 38912          | 1%                   |
> | 39        | 4195188        | 47104          | 1%                   |
> | 55        | 4111612        | 51200          | 1%                   |
> | 59        | 4137012        | 53248          | 1%                   |
> | 60        | 4137052        | 55296          | 1%                   |
> | 61        | 4156832        | 57344          | 1%                   |
> | 62        | 4136920        | 59392          | 1%                   |
> | 64        | 4109872        | 61440          | 1%                   |
> | 65        | 4119108        | 63488          | 2%                   |
> | 66        | 4145532        | 65536          | 2%                   |
> | 67        | 4134544        | 67584          | 2%                   |
> | 68        | 4158244        | 126976         | 3%                   |
> | 69        | 4124276        | 204800         | 5%                   |
> | 70        | 4100680        | 333824         | 8%                   |
> | 71        | 4095540        | 462848         | 11%                  |
> +-----------+----------------+----------------+----------------------+

What is the timestamp unit?  Second?

What is the mem used unit?  Byytes?  Kiloboytes?

I also remember you mentioned you will compare the numbers for more setups
including module disabled case (baseline) and THP disabled case.  I think "THP
disabled" case was my typo.  Maybe I wanted to say "THP enabled" case.

Is that still on your TODO list?

Given this series is adding relatively small change (assuming the sample module
will be simplified), I wouldn't strictly request all such tests.  I'm just
curious about your plan.

> 
> Performance:
> Baseline -> 18,162.45 transactions per second
> Hugepage autotune -> 18,211.82 transactions per second

So, 2.7% improvement!  I think it is not bad for this simple approach.

Could you further elaborate how the performance is measured?  From when the
transactions per second measurement is started, and when it was stopped?  Are
the numbers average?  Mean?  Or something else?

> 
> 
> Eventually, the amount of huge pages reached 20%. This is consistent
> with how quota goals autotuning work. We are more aggresive when the
> quota is less than 10%, and less aggresive when the quota is higher.
> At some point, the aggressiveness just fades and no more collapses
> occur.

Could you share more hugepage utilization change for long term that captures it
converges to 20% but after that doesn't increase more?

Also, have you tried temporal quota tuner?

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

This is a future work out of the scope of this series, right?  I think that is
better to be clarified.  In the previous revision, I was reading this as a TODO
for a future revision of this patch series.

Also, do you have specific changes you want to make to this series before it is
merged, or dropping the RFC tag?

> 
> Patches Sequence
> ================
> Patch 1 -> Introduce DAMOS_QUOTA_HUGEPAGE and autotuning
> Patch 2 -> damon_modules_new_vaddr_ctx_target
> Patch 3 -> Module that demonstrates how to use DAMOS_QUOTA_HUGEPAGE
>            and the new VADDR ctx creation
> Patch 4 -> Documentation

As I commented to each patch, patch 1 looks good except a few trivial things.
Patch 2 seems unnecessary.  I hope patch 3 to be much simplified and wrote
again following the sample modules' pattern.  Patch 4 seems too much for a
sample module.

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

Thank you for continuing this great work, Asier.

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


Thanks,
SJ

[...]

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

[Gutierrez Asier]

Hi SJ,

On 6/5/2026 4:34 AM, SeongJae Park wrote:
> Hello Asier,
> 
> 
> Thank you for revisioning this great patch!
> 
> On Thu, 4 Jun 2026 15:03:33 +0000 <gutierrez.asier@huawei-partners.com> wrote:
> 
>> From: Asier Gutierrez <gutierrez.asier@huawei-partners.com>
>>
>> Overview
>> ========
>>
>> This patch set introduces a new autotuning which allows to collapse
>> hot regions into hugepages.
>>
>> Motivation
>> ==========
>>
>> Since TLB is a bottleneck for many systems[1], a way to optimize TLB
>> misses (or hits) is to use huge pages. Unfortunately, using "always"
>> in THP leads to memory fragmentation and memory waste. For this reason,
>> most application guides and system administrators suggest to disable THP.
>>
>> Currently DAMON has DAMOS_HUGEPAGE, DAMOS_NONHUGEPAGE and DAMOS_COLLAPSE.
>> However, there is no way to tune the settings. It will collapse all the
>> hot regions that meet the access pattern. If the server is a bare metal
>> database or big data server, this will also lead to eventual fragmentation.
>>
>> Additionally, currently THP is set globally. Ideally, there should be a
>> way to control which tasks can use huge pages.
> 
> We can do process level control using prctl(PR_SET_THP_DISABLE) [1], isn't it?
> I think the last above sentence is better to be reworded or simply dropped.
Yes, although you will not disable it for all the processes except onein the system. I will reword it to make it more clear.
>>
>> 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_get_used_hugepage_mem_bp, is
>> introduced, which checks the huge page consumption to total anonymous
> 
> In the previous revision I suggested to
> s/damos_get_used_hugepage_mem_bp/damos_hugepage_mem_bp/ and you agreed.  Seems
> it was forgotten?

Actually, I changed the code to damos_hugepage_mem_bp. I forgot to update
the cover letter. Will do it for the next RFC version.

>> memory consumption. This new quota mechanism reuses current autotuning
>> architecture.
>>
>> A new module is introduced to demonstrate the use of huge pages
> 
> Let's clarify it is a  sample module.  That is,
> s/A new module/A new sample module/ ?

Right, I will update the cover letter.

>> collapse autotuning. The goal is to collapse hot regions of a given
>> process into huge pages. The module launches a kdamond thread for a
>> certain task provided by the user through monitored_pid module argument.
> 
> Following other vaddr based sample modues' pattern, what about
> s/monitored_pid/target_pid/ ?
Makes sense. I will change it.
> 
> As I also commented on the third patch of this series, apparently it is not
> following the sample modules' pattern but that for non-sample modules.  Could
> you please rewrite in a more simple way?

OK, I will remove a lot of the module parameters. I'll use the prcl.c as
an example.

>> Hugepage goal autotuning will automatically adjust the aggressiveness
>> of hot region collapses.
>>
>> This module also has a user autotuning knob which allows the user to
>> adjust the aggressiveness of page collapsing.
>>
>> Benchmarks
>> ==========
>>
>> Huge page collapse autotuning was tested in a physicial machine with
>> MariaDB 10.5.29 and sysbench as the benchmark framework.
>>
>> The hugepage module was set up in the following way:
>>
>> # echo 1000 > min_age
>> # echo 1000 > quota_percentage_hugepage
>> # echo $(pidof mariadbd) > monitored_pid
>> # echo on > enabled
>>
>> The goal was to achieve 5% of the total memory used as hugepage.
> 
> Any reason to set it 5% ?

The database was not particularly big. This means that I set the target
too high, it may never reach it. Not all the database is hot, actually.

I will make it more clear in the following cover letters

>>
>> The table below shows the memory consumption over time. Gaps in the
>> timestamp means that no changes in the hugepage consumption happened
>> over that period of time.
>>
>> +-----------+----------------+----------------+----------------------+
>> | timestamp | total mem used | huge page used | percentage hugepage  |
>> +-----------+----------------+----------------+----------------------+
>> | 0         | 4721188        | 0              | 0%                   |
>> | 28        | 4216848        | 4              | 0%                   |
>> | 37        | 4189912        | 38912          | 1%                   |
>> | 39        | 4195188        | 47104          | 1%                   |
>> | 55        | 4111612        | 51200          | 1%                   |
>> | 59        | 4137012        | 53248          | 1%                   |
>> | 60        | 4137052        | 55296          | 1%                   |
>> | 61        | 4156832        | 57344          | 1%                   |
>> | 62        | 4136920        | 59392          | 1%                   |
>> | 64        | 4109872        | 61440          | 1%                   |
>> | 65        | 4119108        | 63488          | 2%                   |
>> | 66        | 4145532        | 65536          | 2%                   |
>> | 67        | 4134544        | 67584          | 2%                   |
>> | 68        | 4158244        | 126976         | 3%                   |
>> | 69        | 4124276        | 204800         | 5%                   |
>> | 70        | 4100680        | 333824         | 8%                   |
>> | 71        | 4095540        | 462848         | 11%                  |
>> +-----------+----------------+----------------+----------------------+
> 
> What is the timestamp unit?  Second?
> 
> What is the mem used unit?  Byytes?  Kiloboytes?
> 
> I also remember you mentioned you will compare the numbers for more setups
> including module disabled case (baseline) and THP disabled case.  I think "THP
> disabled" case was my typo.  Maybe I wanted to say "THP enabled" case.
> 
> Is that still on your TODO list?
> 
> Given this series is adding relatively small change (assuming the sample module
> will be simplified), I wouldn't strictly request all such tests.  I'm just
> curious about your plan.
> 
>>
>> Performance:
>> Baseline -> 18,162.45 transactions per second
>> Hugepage autotune -> 18,211.82 transactions per second
> 
> So, 2.7% improvement!  I think it is not bad for this simple approach.
> 
> Could you further elaborate how the performance is measured?  From when the
> transactions per second measurement is started, and when it was stopped?  Are
> the numbers average?  Mean?  Or something else?
> 
>>
>>
>> Eventually, the amount of huge pages reached 20%. This is consistent
>> with how quota goals autotuning work. We are more aggresive when the
>> quota is less than 10%, and less aggresive when the quota is higher.
>> At some point, the aggressiveness just fades and no more collapses
>> occur.
> 
> Could you share more hugepage utilization change for long term that captures it
> converges to 20% but after that doesn't increase more?

Correct.

> Also, have you tried temporal quota tuner?

OK, I will give it try.

>>
>> TODO
>> ====
>> - Support page splitting for cold hugepages.
> 
> This is a future work out of the scope of this series, right?  I think that is
> better to be clarified.  In the previous revision, I was reading this as a TODO
> for a future revision of this patch series.
> 
> Also, do you have specific changes you want to make to this series before it is
> merged, or dropping the RFC tag?
> 
>>
>> Patches Sequence
>> ================
>> Patch 1 -> Introduce DAMOS_QUOTA_HUGEPAGE and autotuning
>> Patch 2 -> damon_modules_new_vaddr_ctx_target
>> Patch 3 -> Module that demonstrates how to use DAMOS_QUOTA_HUGEPAGE
>>            and the new VADDR ctx creation
>> Patch 4 -> Documentation
> 
> As I commented to each patch, patch 1 looks good except a few trivial things.
> Patch 2 seems unnecessary.  I hope patch 3 to be much simplified and wrote
> again following the sample modules' pattern.  Patch 4 seems too much for a
> sample module.
Thanks for the feedback, I will work out the patches.
>>
>> Changes from previous versions
>> ==============================
>> RFC 2[3] -> RFC 3
>>   - Module moved to samples
>>   - Change autotune to monitor total memory and hugepage
>>   - Added performnace benchmarks to the cover letter
>>   - Bail out gracefully when trying to start disable
>>     the module after the monitored task exited. This 
>>     issue was discovered by sashiko [4]
>>   - Fixed typos and added quota_sz to the documentation
>>     discovered by sashiko [5]
>> RFC 1[6] -> RFC 2
>>   - Rebased into mm-new
>>   - Use DAMOS_COLLAPSE instead of DAMOS_HUGEPAGE
>>   - Fixed an issue that returned silently an error when the PID
>>     didn't exist in the system.[7]
> 
> Thank you for continuing this great work, Asier.
> 
>>
>> [1] https://dl.acm.org/doi/pdf/10.1145/3307650.3322227
>> [2] https://lore.kernel.org/e67f05ad-dbb9-45e6-ba30-b167a99ac67d@huawei-partners.com
>> [3] https://lore.kernel.org/20260522145518.158910-1-gutierrez.asier@huawei-partners.com
>> [4] https://lore.kernel.org/20260522171210.900B11F00A3D@smtp.kernel.org
>> [5] https://lore.kernel.org/20260522171633.AAF5B1F000E9@smtp.kernel.org
>> [6] https://lore.kernel.org/20260430134139.2446417-1-gutierrez.asier@huawei-partners.com
>> [7] https://lore.kernel.org/all/20260430154338.E22E6C2BCB3@smtp.kernel.org/
> 
> 
> Thanks,
> SJ
> 
> [...]
> 

-- 
Asier Gutierrez
Huawei