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

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

[gutierrez.asier]

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

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

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

Selective huge page collapse per process is possible using prctl and a 
launcher. However, this does not solve the issue with hot region detection.
Additionally, it the sysadmin should create a launcher that uses PRCTL to
enable THP for a particular process.

We can use the DAMON support for DAMOS_HUGEPAGE and DAMOS_COLLAPSE, to
target a certain process. DAMOS_COLLAPSE can also target the hot regions in
that process.

Still, there is an issue with the amount of huge page consumption. Since
huge pages can lead to memory fragmentation and waste, there should be a
way to limit the amount of huge page consumption. There is hugetlbfs, but
it requires changes to the application code or the use of libhugetlbfs.

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.

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

In order to test this new mechanism, a sample module[3] was created, but
not included in this patch series. To demonstrate the tool, damo user
space tool was modified[4], which sets up huge pages collapse autotuning.

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

Damo user space tool was forked and hugepage_mem_bp support added[4].

DAMON was lauched using this command line:

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

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

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

hugepage_mem_bp: 1000
goal tuner: temporal

+-----------+----------------+----------------+----------------------+
| timestamp | total mem used | huge page used | percentage hugepage  |
+-----------+----------------+----------------+----------------------+
| 0         | 16945.04297    | 0              | 0                    |
| 7         | 17008.69531    | 74             | 0.435071583          |
| 8         | 17036.40234    | 194            | 1.138738074          |
| 9         | 17017.01563    | 314            | 1.845211916          |
| 10        | 17029.67969    | 434            | 2.548491856          |
| 61        | 17111.30859    | 584            | 3.412947623          |
| 120       | 17071.05859    | 694            | 4.065360072          |
| 180       | 17133.88281    | 804            | 4.692456513          |
| 203       | 17088.16406    | 916            | 5.360435426          |
| 204       | 17126.34766    | 1046           | 6.107548562          |
| 205       | 17093.84375    | 1176           | 6.879669764          |
| 206       | 17142.77734    | 1298           | 7.571701913          |
| 209       | 17149.17969    | 1686           | 9.831374041          |
| 210       | 17097.30859    | 1754           | 10.25892462          |
+-----------+----------------+----------------+----------------------+

hugepage_mem_bp: 1000
goal tuner: consistent

+-----------+----------------+----------------+----------------------+
| timestamp | total mem used | huge page used | percentage hugepage  |
+-----------+----------------+----------------+----------------------+
| 0         | 16955.24609    | 0              | 0                    |
| 34        | 17039.71875    | 106            | 0.622075995          |
| 78        | 17009.47656    | 554            | 3.257007927          |
| 90        | 17048.92188    | 596            | 3.495822225          |
| 150       | 17092.90625    | 706            | 4.130368409          |
| 180       | 17053.08984    | 764            | 4.480126517          |
| 233       | 17100.50391    | 1496           | 8.748280216          |
| 239       | 17098.89063    | 2216           | 12.95990511          |
| 240       | 17135.44531    | 2334           | 13.62088908          |
| 245       | 17132.55078    | 2932           | 17.11362212          |
| 246       | 17117.95313    | 3052           | 17.82923448          |
| 250       | 17163.12109    | 3532           | 20.57900763          |
+-----------+----------------+----------------+----------------------+

hugepage_mem_bp: 2500
goal tuner: temporal

+-----------+----------------+----------------+----------------------+
| timestamp | total mem used | huge page used | percentage hugepage  |
+-----------+----------------+----------------+----------------------+
| 0         | 17010.31641    | 0              | 0                    |
| 9         | 17063.6875     | 50             | 0.2930199            |
| 10        | 17051.75781    | 170            | 0.996964664          |
| 60        | 17133.85547    | 572            | 3.338419663          |
| 90        | 17192.07813    | 626            | 3.641211932          |
| 120       | 17221.44531    | 682            | 3.960178647          |
| 181       | 17199.76172    | 790            | 4.593086886          |
| 208       | 17222.77734    | 1206           | 7.002354939          |
| 214       | 17245.17969    | 1904           | 11.04076637          |
| 215       | 17240.45703    | 2024           | 11.73982799          |
| 220       | 17234.79688    | 2624           | 15.22501262          |
| 228       | 17222.83594    | 3584           | 20.80958103          |
| 231       | 17247.55469    | 3944           | 22.86700968          |
| 235       | 17229.37109    | 4424           | 25.67708349          |
+-----------+----------------+----------------+----------------------+

hugepage_mem_bp: 1000
goal tuner: consist

+-----------+----------------+----------------+----------------------+
| timestamp | total mem used | huge page used | percentage hugepage  |
+-----------+----------------+----------------+----------------------+
| 0         | 17125.85156    | 0              | 0                    |
| 38        | 17081.23438    | 76             | 0.444932716          |
| 39        | 17133.11719    | 196            | 1.143983304          |
| 40        | 17119.83984    | 316            | 1.84581166           |
| 60        | 17109.72656    | 554            | 3.237924335          |
| 90        | 17164.11328    | 628            | 3.65879664           |
| 180       | 17177.66016    | 792            | 4.610639591          |
| 220       | 17180.86719    | 1378           | 8.020549749          |
| 226       | 17187.82031    | 1980           | 11.51978531          |
| 233       | 17143.48438    | 2818           | 16.4377319           |
| 240       | 17137.38281    | 3656           | 21.33347921          |
| 250       | 17175.5        | 4856           | 28.27283049          |
| 260       | 17199.66406    | 6056           | 35.20999002          |
| 270       | 17203.98438    | 7254           | 42.16465118          |
| 275       | 17207.21875    | 7762           | 45.10897498          |
+-----------+----------------+----------------+----------------------+

More detailed tables are provided here[5]

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

Patches Sequence
================
Patch 1 -> Introduce DAMOS_QUOTA_HUGEPAGE_MEM_BP and autotuning
Patch 2 -> sysfs support for the new quota goal
Patch 3 -> Document hugepage_mem_bp parameter

Changes from previous versions
==============================
v2[6] -> v3
  - Reworked the cover letter to make more clean the intents,
    design choices and results.
  - Added a guard in damos_hugepage_mem_bp in order to avoid
    potential division by 0.[7]
  - Fixed a typo in the documentation.
v1[8] -> v2
  - Rebased onto updated mm-new
  - Removed the sample module altogether, since it will
    increase maintenance costs[9]
  - Document hugepage_mem_bp in design.rst

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

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

RFC 2[12] -> 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 [13]
  - Fixed typos and added quota_sz to the documentation
    discovered by sashiko [14]

RFC 1[15] -> 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.[16]

[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/20260616150316.580819-3-gutierrez.asier@huawei-partners.com
[4] https://github.com/asierHuawei/damo/commit/79ae1a4ab1c012a7161db85a000d14f08fa36736
[5] https://lore.kernel.org/all/03f678dd-9ef3-4b97-b753-c2e4554c5159@huawei-partners.com/
[6] https://lore.kernel.org/all/20260714150116.382521-1-gutierrez.asier@huawei-partners.com
[7] https://lore.kernel.org/all/20260715151615.99767-1-sj@kernel.org/
[8] https://lore.kernel.org/20260616150316.580819-1-gutierrez.asier@huawei-partners.com
[9] https://lore.kernel.org/20260618150806.4633-1-sj@kernel.org
[10] https://lore.kernel.org/20260611150244.3454699-1-gutierrez.asier@huawei-partners.com
[11] https://lore.kernel.org/20260604150338.501128-1-gutierrez.asier@huawei-partners.com
[12] https://lore.kernel.org/20260522145518.158910-1-gutierrez.asier@huawei-partners.com
[13] https://lore.kernel.org/20260522171210.900B11F00A3D@smtp.kernel.org
[14] https://lore.kernel.org/20260522171633.AAF5B1F000E9@smtp.kernel.org
[15] https://lore.kernel.org/20260430134139.2446417-1-gutierrez.asier@huawei-partners.com
[16] https://lore.kernel.org/all/20260430154338.E22E6C2BCB3@smtp.kernel.org/

Asier Gutierrez (3):
  mm/damon: Introduce DAMOS_QUOTA_HUGEPAGE auto tuning
  mm/damon/sysfs: support hugepage_mem_bp quota goal metric
  Docs/mm/damon/design: Document hugepage_mem_bp target metric

 Documentation/mm/damon/design.rst |  2 ++
 include/linux/damon.h             |  2 ++
 mm/damon/core.c                   | 21 +++++++++++++++++++++
 mm/damon/sysfs-schemes.c          |  4 ++++
 4 files changed, 29 insertions(+)

-- 
2.43.0

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

[gutierrez.asier]

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

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

Vmstat may lag, which in some cases may lead to NR_FREE_PAGES
being equal to the amount of RAM in the system. A guard is added
to avoid the extremely unlikely case of a division by 0.[1] In that
we return INT_MAX, which should be enough not to apply any DAMOS
action until the NR_FREE_PAGES is updated.

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

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

diff --git a/include/linux/damon.h b/include/linux/damon.h
index 327f534696aa..0d0b7bb233b7 100644
--- a/include/linux/damon.h
+++ b/include/linux/damon.h
@@ -153,6 +153,7 @@ enum damos_action {
  * @DAMOS_QUOTA_INACTIVE_MEM_BP:	Inactive to total LRU memory ratio.
  * @DAMOS_QUOTA_NODE_ELIGIBLE_MEM_BP:	Scheme-eligible memory ratio of a
  *					node in basis points (0-10000).
+ * @DAMOS_QUOTA_HUGEPAGE_MEM_BP:	Huge page to total used memory ratio.
  * @NR_DAMOS_QUOTA_GOAL_METRICS:	Number of DAMOS quota goal metrics.
  *
  * Metrics equal to larger than @NR_DAMOS_QUOTA_GOAL_METRICS are unsupported.
@@ -167,6 +168,7 @@ enum damos_quota_goal_metric {
 	DAMOS_QUOTA_ACTIVE_MEM_BP,
 	DAMOS_QUOTA_INACTIVE_MEM_BP,
 	DAMOS_QUOTA_NODE_ELIGIBLE_MEM_BP,
+	DAMOS_QUOTA_HUGEPAGE_MEM_BP,
 	NR_DAMOS_QUOTA_GOAL_METRICS,
 };
 
diff --git a/mm/damon/core.c b/mm/damon/core.c
index 603b102ff80f..73aaee43c6f7 100644
--- a/mm/damon/core.c
+++ b/mm/damon/core.c
@@ -3004,6 +3004,24 @@ 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);
+
+	/*
+	 * vmstat may lag in idle systems and lead to free pages equaling to
+	 * the total RAM in the system.
+	 */
+	if (!total)
+		return INT_MAX;
+	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)
 {
@@ -3035,6 +3053,9 @@ static void damos_set_quota_goal_current_value(struct damon_ctx *c,
 		goal->current_value = damos_get_node_eligible_mem_bp(c, s,
 				goal->nid);
 		break;
+	case DAMOS_QUOTA_HUGEPAGE_MEM_BP:
+		goal->current_value = damos_hugepage_mem_bp();
+		break;
 	default:
 		break;
 	}
-- 
2.43.0

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

[gutierrez.asier]

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

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

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

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

diff --git a/mm/damon/sysfs-schemes.c b/mm/damon/sysfs-schemes.c
index 32f495a96b17..d9b81d7b5910 100644
--- a/mm/damon/sysfs-schemes.c
+++ b/mm/damon/sysfs-schemes.c
@@ -1269,6 +1269,10 @@ struct damos_sysfs_qgoal_metric_name damos_sysfs_qgoal_metric_names[] = {
 		.metric = DAMOS_QUOTA_NODE_ELIGIBLE_MEM_BP,
 		.name = "node_eligible_mem_bp",
 	},
+	{
+		.metric = DAMOS_QUOTA_HUGEPAGE_MEM_BP,
+		.name = "hugepage_mem_bp",
+	},
 };
 
 static ssize_t target_metric_show(struct kobject *kobj,
-- 
2.43.0

[PATCH v3 3/3] Docs/mm/damon/design: Document hugepage_mem_bp target metric

[gutierrez.asier]

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

Document hugepage_mem_bp metric exposed by sysfs.

Signed-off-by: Asier Gutierrez <gutierrez.asier@huawei-partners.com>
---
 Documentation/mm/damon/design.rst | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/Documentation/mm/damon/design.rst b/Documentation/mm/damon/design.rst
index aed6cb1cf483..a8c163475ef2 100644
--- a/Documentation/mm/damon/design.rst
+++ b/Documentation/mm/damon/design.rst
@@ -713,6 +713,8 @@ mechanism tries to make ``current_value`` of ``target_metric`` be same to
   bp (1/10,000).
 - ``node_eligible_mem_bp``: Scheme target access pattern-eligible memory ratio
   of a node in bp (1/10,000).
+- ``hugepage_mem_bp``: Total huge page to total used memory ratio in bp
+  (1/10,000).
 
 ``nid`` is optionally required for ``node_mem_used_bp``, ``node_mem_free_bp``,
 ``node_memcg_used_bp``, ``node_memcg_free_bp`` and ``node_eligible_mem_bp`` to
-- 
2.43.0

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

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 3 potential issue(s) to consider:
- [High] Integer underflow when computing 'total' in `damos_hugepage_mem_bp` causes DAMON to become maximally aggressive on highly idle systems.
- [Medium] The new `hugepage_mem_bp` sysfs metric is missing from the DAMON sysfs selftest script.
- [Low] Missing documentation for the `hugepage_mem_bp` metric in the DAMON design guide.
--

--- Patch [2]: [PATCH v3 2/3] mm/damon/sysfs: support hugepage_mem_bp quota goal metric ---
commit 304fd61bee6da0356569e9c8297451d15a43e10f
Author: Asier Gutierrez <gutierrez.asier@huawei-partners.com>

mm/damon/sysfs: support hugepage_mem_bp quota goal metric

This commit exposes the new DAMOS_QUOTA_HUGEPAGE_MEM_BP autotune policy
metric through the DAMON sysfs interface. It adds "hugepage_mem_bp" to
the sysfs-schemes interface.

> diff --git a/mm/damon/sysfs-schemes.c b/mm/damon/sysfs-schemes.c
> index 32f495a96b17a..d9b81d7b5910e 100644
> --- a/mm/damon/sysfs-schemes.c
> +++ b/mm/damon/sysfs-schemes.c
> @@ -1269,6 +1269,10 @@ struct damos_sysfs_qgoal_metric_name damos_sysfs_qgoal_metric_names[] = {
>  		.metric = DAMOS_QUOTA_NODE_ELIGIBLE_MEM_BP,
>  		.name = "node_eligible_mem_bp",
>  	},
> +	{
> +		.metric = DAMOS_QUOTA_HUGEPAGE_MEM_BP,
> +		.name = "hugepage_mem_bp",
> +	},
>  };

[Severity: High]
While this patch exposes the new metric, is there a potential integer
underflow in the underlying implementation of damos_hugepage_mem_bp() in
mm/damon/core.c?

Due to per-CPU vmstat counter drift, pending positive deltas from freed
memory can cause the global NR_FREE_PAGES count to temporarily exceed the
fixed totalram_pages(). In damos_hugepage_mem_bp(), total is computed as:

    total = totalram_pages() - global_zone_page_state(NR_FREE_PAGES);

On a highly idle system, this could cause the unsigned subtraction to
underflow, resulting in a value near ULONG_MAX. The subsequent !total check
would fail, and mult_frac(thp, 10000, total) would evaluate to 0 due to the
enormous denominator.

Would this score of 0 lead damon_feed_loop_next_input() to perceive a maximal
divergence from the goal, forcing the scheme to maximize its quota
aggressiveness instead of minimizing it?

[Severity: Medium]
Should tools/testing/selftests/damon/sysfs.sh be updated to include the new
metric?

The test_goal() function validates writes to target_metric for all existing
metrics:

    ensure_write_succ "$fpath" "active_mem_bp" "valid input"
    ensure_write_succ "$fpath" "inactive_mem_bp" "valid input"
    ensure_write_succ "$fpath" "node_eligible_mem_bp" "valid input"

Could hugepage_mem_bp be added to this sequence to ensure the sysfs interface
is regression tested?

[Severity: Low]
Does this new metric need to be documented in
Documentation/mm/damon/design.rst?

The documentation lists all available target_metric values, such as
inactive_mem_bp and node_eligible_mem_bp, but it appears hugepage_mem_bp
is missing.

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

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

[sashiko-bot]

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

New issues:
- [High] Unsigned underflow in `total` bypasses the division-by-zero guard, causing `damos_hugepage_mem_bp` to return 0 instead of the intended safeguard `INT_MAX`.
- [Medium] The new `DAMOS_QUOTA_HUGEPAGE_MEM_BP` metric is missing from the sysfs parser mapping array, rendering the feature completely inaccessible to userspace.
- [Medium] 32-bit integer overflow in `mult_frac()` yields drastically incorrect ratios when the number of huge pages exceeds ~1.7GB.

Pre-existing issues:
- [High] Preexisting division by zero in `damos_get_in_active_mem_bp` when LRU lists are empty.
--

--- Patch [1]: [PATCH v3 1/3] mm/damon: Introduce DAMOS_QUOTA_HUGEPAGE auto tuning ---
commit 8d24f093924a5075fd67c8f7808eada2166af60d
Author: Asier Gutierrez <gutierrez.asier@huawei-partners.com>

mm/damon: Introduce DAMOS_QUOTA_HUGEPAGE auto tuning

Introduce DAMOS_QUOTA_HUGEPAGE_MEM_BP auto tuning and add a new DAMOS
quota goal metric to measure huge page consumption. Add a guard to avoid
division by 0 when vmstat lags.

Link: https://lore.kernel.org/all/20260715151615.99767-1-sj@kernel.org/

> diff --git a/include/linux/damon.h b/include/linux/damon.h
> --- a/include/linux/damon.h
> +++ b/include/linux/damon.h
[ ... ]
> @@ -167,6 +168,7 @@ enum damos_quota_goal_metric {
>  	DAMOS_QUOTA_ACTIVE_MEM_BP,
>  	DAMOS_QUOTA_INACTIVE_MEM_BP,
>  	DAMOS_QUOTA_NODE_ELIGIBLE_MEM_BP,
> +	DAMOS_QUOTA_HUGEPAGE_MEM_BP,

[Severity: Medium]
Is this feature accessible from userspace?

If a user writes hugepage_mem_bp to the target_metric sysfs file,
target_metric_store() iterates over the damos_sysfs_qgoal_metric_names
array to find a match.

Because DAMOS_QUOTA_HUGEPAGE_MEM_BP is missing from that array in
mm/damon/sysfs-schemes.c, will the kernel always reject the user's input
with -EINVAL?

>  	NR_DAMOS_QUOTA_GOAL_METRICS,
>  };
>  
> diff --git a/mm/damon/core.c b/mm/damon/core.c
> --- a/mm/damon/core.c
> +++ b/mm/damon/core.c
> @@ -3007,6 +3007,24 @@ 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 divide by zero?

In damos_get_in_active_mem_bp(), total is used as the divisor without a zero
check. If all memory is forced onto the unevictable list (e.g. via
mlockall()), or if the system is completely idle with only kernel allocations,
active + inactive can be zero.

If DAMOS_QUOTA_ACTIVE_MEM_BP is used in such a state, would mult_frac()
trigger a hardware divide-by-zero exception and panic the system?

>  }
>  
> +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);
> +
> +	/*
> +	 * vmstat may lag in idle systems and lead to free pages equaling to
> +	 * the total RAM in the system.
> +	 */
> +	if (!total)
> +		return INT_MAX;

[Severity: High]
Can total underflow here?

Because global_zone_page_state(NR_FREE_PAGES) relies on vmstat, which uses
per-CPU caching, the global NR_FREE_PAGES counter can temporarily exceed
totalram_pages() if some CPUs have flushed frees while others have pending
allocations.

If this happens, total (which is unsigned long) underflows to a value near
ULONG_MAX. Could this bypass the !total guard and pass a massive integer
to mult_frac(), which then incorrectly returns 0?

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

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

mult_frac() evaluates the intermediate multiplication using the types of its
arguments. Since thp is an unsigned long, evaluating thp * 10000 uses 32-bit
arithmetic on 32-bit systems like ARM LPAE.

If the system has more than 429,496 base pages of THP (approximately 1.7GB),
will this silently wrap around and yield drastically incorrect quota goal
ratios?

> +}

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

Re: [PATCH v3 3/3] Docs/mm/damon/design: Document hugepage_mem_bp target metric

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 3 potential issue(s) to consider:
- [High] Underflow in total used memory calculation causes division by a huge number, breaking the intended safeguard and leading to aggressive DAMOS actions.
- [Low] Returning INT_MAX from damos_hugepage_mem_bp() causes an integer overflow when computing the quota score on 32-bit architectures.
- [Low] The newly added 'hugepage_mem_bp' sysfs metric is missing from the automated sysfs selftests.
--

--- Patch [3]: [PATCH v3 3/3] Docs/mm/damon/design: Document hugepage_mem_bp target metric ---
commit 8b5f375e8a76a103dce1c4b0a9e133966c306366
Author: Asier Gutierrez <gutierrez.asier@huawei-partners.com>

Docs/mm/damon/design: Document hugepage_mem_bp target metric
    
Document hugepage_mem_bp metric exposed by sysfs.

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

[Severity: High]
Does this calculation handle vmstat drift correctly when free pages temporarily
exceed total RAM?

Due to per-CPU negative deltas on mostly idle systems,
global_zone_page_state(NR_FREE_PAGES) can temporarily exceed totalram_pages().
If this happens, the unsigned subtraction will underflow to a massive value
instead of zero.

This would bypass the !total check and cause mult_frac() to divide by the
massive value, resulting in 0. Could this false 0% hugepage usage cause DAMOS
to aggressively apply actions when it should be pausing them?

> +
> +	/*
> +	 * vmstat may lag in idle systems and lead to free pages equaling to
> +	 * the total RAM in the system.
> +	 */
> +	if (!total)
> +		return INT_MAX;

[Severity: Low]
Can returning INT_MAX here cause an integer overflow in damos_quota_score()?

If total is exactly 0, returning INT_MAX means it will be multiplied by 10000
in damos_quota_score():

    score = mult_frac(goal->current_value, 10000, goal->target_value);

On 32-bit architectures, INT_MAX * 10000 will overflow. While the wrapped value
might remain large enough to suppress DAMOS actions in practice, it breaks the
10000 basis point scale. Should a smaller maximum value be returned here to
avoid the overflow?

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

[ ... ]

> diff --git a/mm/damon/sysfs-schemes.c b/mm/damon/sysfs-schemes.c
> index 32f495a96b17a..d9b81d7b5910e 100644
> --- a/mm/damon/sysfs-schemes.c
> +++ b/mm/damon/sysfs-schemes.c
> @@ -1269,6 +1269,10 @@ struct damos_sysfs_qgoal_metric_name damos_sysfs_qgoal_metric_names[] = {
>  		.metric = DAMOS_QUOTA_NODE_ELIGIBLE_MEM_BP,
>  		.name = "node_eligible_mem_bp",
>  	},
> +	{
> +		.metric = DAMOS_QUOTA_HUGEPAGE_MEM_BP,
> +		.name = "hugepage_mem_bp",
> +	},
>  };

[Severity: Low]
Is hugepage_mem_bp missing from the automated sysfs selftests?

The tools/testing/selftests/damon/sysfs.sh script explicitly tests the other
valid target_metric strings:

    ensure_write_succ "$fpath" "active_mem_bp" "valid input"
    ensure_write_succ "$fpath" "inactive_mem_bp" "valid input"
    ensure_write_succ "$fpath" "node_eligible_mem_bp" "valid input"
    ensure_write_fail "$fpath" "foo" "invalid input"

Without an entry for hugepage_mem_bp, the new sysfs interface won't be verified
by the kselftests CI framework.

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

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

[SJ Park]

On Mon, 20 Jul 2026 12:16:57 +0000 sashiko-bot@kernel.org wrote:

> Thank you for your contribution! Sashiko AI review found 4 potential issue(s) to consider:
> 
> New issues:
> - [High] Unsigned underflow in `total` bypasses the division-by-zero guard, causing `damos_hugepage_mem_bp` to return 0 instead of the intended safeguard `INT_MAX`.
> - [Medium] The new `DAMOS_QUOTA_HUGEPAGE_MEM_BP` metric is missing from the sysfs parser mapping array, rendering the feature completely inaccessible to userspace.
> - [Medium] 32-bit integer overflow in `mult_frac()` yields drastically incorrect ratios when the number of huge pages exceeds ~1.7GB.
> 
> Pre-existing issues:
> - [High] Preexisting division by zero in `damos_get_in_active_mem_bp` when LRU lists are empty.
> --
> 
> --- Patch [1]: [PATCH v3 1/3] mm/damon: Introduce DAMOS_QUOTA_HUGEPAGE auto tuning ---
> commit 8d24f093924a5075fd67c8f7808eada2166af60d
> Author: Asier Gutierrez <gutierrez.asier@huawei-partners.com>
> 
> mm/damon: Introduce DAMOS_QUOTA_HUGEPAGE auto tuning
> 
> Introduce DAMOS_QUOTA_HUGEPAGE_MEM_BP auto tuning and add a new DAMOS
> quota goal metric to measure huge page consumption. Add a guard to avoid
> division by 0 when vmstat lags.
> 
> Link: https://lore.kernel.org/all/20260715151615.99767-1-sj@kernel.org/
> 
> > diff --git a/include/linux/damon.h b/include/linux/damon.h
> > --- a/include/linux/damon.h
> > +++ b/include/linux/damon.h
> [ ... ]
> > @@ -167,6 +168,7 @@ enum damos_quota_goal_metric {
> >  	DAMOS_QUOTA_ACTIVE_MEM_BP,
> >  	DAMOS_QUOTA_INACTIVE_MEM_BP,
> >  	DAMOS_QUOTA_NODE_ELIGIBLE_MEM_BP,
> > +	DAMOS_QUOTA_HUGEPAGE_MEM_BP,
> 
> [Severity: Medium]
> Is this feature accessible from userspace?
> 
> If a user writes hugepage_mem_bp to the target_metric sysfs file,
> target_metric_store() iterates over the damos_sysfs_qgoal_metric_names
> array to find a match.
> 
> Because DAMOS_QUOTA_HUGEPAGE_MEM_BP is missing from that array in
> mm/damon/sysfs-schemes.c, will the kernel always reject the user's input
> with -EINVAL?

No issue.  The next patch will make it accessible.

> 
> >  	NR_DAMOS_QUOTA_GOAL_METRICS,
> >  };
> >  
> > diff --git a/mm/damon/core.c b/mm/damon/core.c
> > --- a/mm/damon/core.c
> > +++ b/mm/damon/core.c
> > @@ -3007,6 +3007,24 @@ 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 divide by zero?
> 
> In damos_get_in_active_mem_bp(), total is used as the divisor without a zero
> check. If all memory is forced onto the unevictable list (e.g. via
> mlockall()), or if the system is completely idle with only kernel allocations,
> active + inactive can be zero.
> 
> If DAMOS_QUOTA_ACTIVE_MEM_BP is used in such a state, would mult_frac()
> trigger a hardware divide-by-zero exception and panic the system?

No blocker of this patch.

I will work on this.

> 
> >  }
> >  
> > +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);
> > +
> > +	/*
> > +	 * vmstat may lag in idle systems and lead to free pages equaling to
> > +	 * the total RAM in the system.
> > +	 */
> > +	if (!total)
> > +		return INT_MAX;
> 
> [Severity: High]
> Can total underflow here?
> 
> Because global_zone_page_state(NR_FREE_PAGES) relies on vmstat, which uses
> per-CPU caching, the global NR_FREE_PAGES counter can temporarily exceed
> totalram_pages() if some CPUs have flushed frees while others have pending
> allocations.
> 
> If this happens, total (which is unsigned long) underflows to a value near
> ULONG_MAX. Could this bypass the !total guard and pass a massive integer
> to mult_frac(), which then incorrectly returns 0?

Maybe better to address correctly.  But the user impact is too trivial to block
this patch.  No blocker in my opinion.

> 
> > +	return mult_frac(thp, 10000, total);
> 
> [Severity: Medium]
> Will this overflow on 32-bit architectures?
> 
> mult_frac() evaluates the intermediate multiplication using the types of its
> arguments. Since thp is an unsigned long, evaluating thp * 10000 uses 32-bit
> arithmetic on 32-bit systems like ARM LPAE.
> 
> If the system has more than 429,496 base pages of THP (approximately 1.7GB),
> will this silently wrap around and yield drastically incorrect quota goal
> ratios?

No blocker.  Known low priority issue.

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


Thanks,
SJ

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

[SJ Park]

On Mon, 20 Jul 2026 12:15:38 +0000 sashiko-bot@kernel.org wrote:

> Thank you for your contribution! Sashiko AI review found 3 potential issue(s) to consider:
> - [High] Integer underflow when computing 'total' in `damos_hugepage_mem_bp` causes DAMON to become maximally aggressive on highly idle systems.
> - [Medium] The new `hugepage_mem_bp` sysfs metric is missing from the DAMON sysfs selftest script.
> - [Low] Missing documentation for the `hugepage_mem_bp` metric in the DAMON design guide.
> --
> 
> --- Patch [2]: [PATCH v3 2/3] mm/damon/sysfs: support hugepage_mem_bp quota goal metric ---
> commit 304fd61bee6da0356569e9c8297451d15a43e10f
> Author: Asier Gutierrez <gutierrez.asier@huawei-partners.com>
> 
> mm/damon/sysfs: support hugepage_mem_bp quota goal metric
> 
> This commit exposes the new DAMOS_QUOTA_HUGEPAGE_MEM_BP autotune policy
> metric through the DAMON sysfs interface. It adds "hugepage_mem_bp" to
> the sysfs-schemes interface.
> 
> > diff --git a/mm/damon/sysfs-schemes.c b/mm/damon/sysfs-schemes.c
> > index 32f495a96b17a..d9b81d7b5910e 100644
> > --- a/mm/damon/sysfs-schemes.c
> > +++ b/mm/damon/sysfs-schemes.c
> > @@ -1269,6 +1269,10 @@ struct damos_sysfs_qgoal_metric_name damos_sysfs_qgoal_metric_names[] = {
> >  		.metric = DAMOS_QUOTA_NODE_ELIGIBLE_MEM_BP,
> >  		.name = "node_eligible_mem_bp",
> >  	},
> > +	{
> > +		.metric = DAMOS_QUOTA_HUGEPAGE_MEM_BP,
> > +		.name = "hugepage_mem_bp",
> > +	},
> >  };
> 
> [Severity: High]
> While this patch exposes the new metric, is there a potential integer
> underflow in the underlying implementation of damos_hugepage_mem_bp() in
> mm/damon/core.c?
> 
> Due to per-CPU vmstat counter drift, pending positive deltas from freed
> memory can cause the global NR_FREE_PAGES count to temporarily exceed the
> fixed totalram_pages(). In damos_hugepage_mem_bp(), total is computed as:
> 
>     total = totalram_pages() - global_zone_page_state(NR_FREE_PAGES);
> 
> On a highly idle system, this could cause the unsigned subtraction to
> underflow, resulting in a value near ULONG_MAX. The subsequent !total check
> would fail, and mult_frac(thp, 10000, total) would evaluate to 0 due to the
> enormous denominator.
> 
> Would this score of 0 lead damon_feed_loop_next_input() to perceive a maximal
> divergence from the goal, forcing the scheme to maximize its quota
> aggressiveness instead of minimizing it?

As I replied to the same report, the user impact is trivial.  No blocker.

> 
> [Severity: Medium]
> Should tools/testing/selftests/damon/sysfs.sh be updated to include the new
> metric?
> 
> The test_goal() function validates writes to target_metric for all existing
> metrics:
> 
>     ensure_write_succ "$fpath" "active_mem_bp" "valid input"
>     ensure_write_succ "$fpath" "inactive_mem_bp" "valid input"
>     ensure_write_succ "$fpath" "node_eligible_mem_bp" "valid input"
> 
> Could hugepage_mem_bp be added to this sequence to ensure the sysfs interface
> is regression tested?

Definitely better to do this.  No blocker, though.  I will do this unless
someone steps up earlier.

> 
> [Severity: Low]
> Does this new metric need to be documented in
> Documentation/mm/damon/design.rst?
> 
> The documentation lists all available target_metric values, such as
> inactive_mem_bp and node_eligible_mem_bp, but it appears hugepage_mem_bp
> is missing.

No blocker.  The next patch of this series does that.

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


Thanks,
SJ

Re: [PATCH v3 3/3] Docs/mm/damon/design: Document hugepage_mem_bp target metric

[SJ Park]

On Mon, 20 Jul 2026 12:17:23 +0000 sashiko-bot@kernel.org wrote:

> Thank you for your contribution! Sashiko AI review found 3 potential issue(s) to consider:
> - [High] Underflow in total used memory calculation causes division by a huge number, breaking the intended safeguard and leading to aggressive DAMOS actions.
> - [Low] Returning INT_MAX from damos_hugepage_mem_bp() causes an integer overflow when computing the quota score on 32-bit architectures.
> - [Low] The newly added 'hugepage_mem_bp' sysfs metric is missing from the automated sysfs selftests.

All the issues are duplicates of previously reported ones.  No one is a
blocker.


Thanks,
SJ

[...]

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

[SJ Park]

Hello Asier,

On Mon, 20 Jul 2026 12:01:37 +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.

Thank you for making this series well done like this!

[...]
> Patches Sequence
> ================
> Patch 1 -> Introduce DAMOS_QUOTA_HUGEPAGE_MEM_BP and autotuning
> Patch 2 -> sysfs support for the new quota goal
> Patch 3 -> Document hugepage_mem_bp parameter

I'd prefer handling 'total' underflow and returning 10,000 instead of INT_MAX
from damos_hugepage_mem_bp() corner cases.  But definitely that is no blocker.
For the series,

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

This series is applied to damon/next [1] tree.  If this series is not added to
mm.git in short term (~3 days?), I will ask mm.git maintainer (Andrew Morton)
to pick this.  In the case, I will update patch 1 to do what I mentioned as
preferred change if you don't mind.  So, no action from your side is needed for
now.  If it seems I also forgot doing that or you cannot wait for my action,
please feel free to directly ask that to Andrew.

[1] https://origin.kernel.org/doc/html/latest/mm/damon/maintainer-profile.html#scm-trees


Thanks,
SJ

[...]

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

[Gutierrez Asier]

Hi SJ,

On 7/21/2026 6:58 AM, SJ Park wrote:
> Hello Asier,
> 
> On Mon, 20 Jul 2026 12:01:37 +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.
> 
> Thank you for making this series well done like this!
> 
> [...]
>> Patches Sequence
>> ================
>> Patch 1 -> Introduce DAMOS_QUOTA_HUGEPAGE_MEM_BP and autotuning
>> Patch 2 -> sysfs support for the new quota goal
>> Patch 3 -> Document hugepage_mem_bp parameter
> 
> I'd prefer handling 'total' underflow and returning 10,000 instead of INT_MAX
> from damos_hugepage_mem_bp() corner cases.  But definitely that is no blocker.
> For the series,
> 
> Reviewed-by: SJ Park <sj@kernel.org>
> 
> This series is applied to damon/next [1] tree.  If this series is not added to
> mm.git in short term (~3 days?), I will ask mm.git maintainer (Andrew Morton)
> to pick this.  In the case, I will update patch 1 to do what I mentioned as
> preferred change if you don't mind.  So, no action from your side is needed for
> now.  If it seems I also forgot doing that or you cannot wait for my action,
> please feel free to directly ask that to Andrew.
> 
> [1] https://origin.kernel.org/doc/html/latest/mm/damon/maintainer-profile.html#scm-trees
> 
> 
> Thanks,
> SJ
> 
> [...]

Thanks a lot for your patience and help with the patch series.

I will work on the suggested minor changes once the this patch set
lands into mm-next, if you don't mind.

-- 
Asier Gutierrez
Huawei

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

[SJ Park]

On Tue, 21 Jul 2026 15:58:13 +0300 Gutierrez Asier <gutierrez.asier@huawei-partners.com> wrote:

> Hi SJ,
> 
> On 7/21/2026 6:58 AM, SJ Park wrote:
> > Hello Asier,
> > 
> > On Mon, 20 Jul 2026 12:01:37 +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.
> > 
> > Thank you for making this series well done like this!
> > 
> > [...]
> >> Patches Sequence
> >> ================
> >> Patch 1 -> Introduce DAMOS_QUOTA_HUGEPAGE_MEM_BP and autotuning
> >> Patch 2 -> sysfs support for the new quota goal
> >> Patch 3 -> Document hugepage_mem_bp parameter
> > 
> > I'd prefer handling 'total' underflow and returning 10,000 instead of INT_MAX
> > from damos_hugepage_mem_bp() corner cases.  But definitely that is no blocker.
> > For the series,
> > 
> > Reviewed-by: SJ Park <sj@kernel.org>
> > 
> > This series is applied to damon/next [1] tree.  If this series is not added to
> > mm.git in short term (~3 days?), I will ask mm.git maintainer (Andrew Morton)
> > to pick this.  In the case, I will update patch 1 to do what I mentioned as
> > preferred change if you don't mind.  So, no action from your side is needed for
> > now.  If it seems I also forgot doing that or you cannot wait for my action,
> > please feel free to directly ask that to Andrew.
> > 
> > [1] https://origin.kernel.org/doc/html/latest/mm/damon/maintainer-profile.html#scm-trees
> > 
> > 
> > Thanks,
> > SJ
> > 
> > [...]
> 
> Thanks a lot for your patience and help with the patch series.
> 
> I will work on the suggested minor changes once the this patch set
> lands into mm-next, if you don't mind.

As the change is so minor, let's do so as a followup if Andrew picks this
as-is.  If not and if you or I do resend this series, let's do that as a part
of the resend.


Thanks,
SJ

[...]