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

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

[gutierrez.asier]

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

Overview
========

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

Motivation
==========

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

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

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

Solution
========

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

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

In order to test this new mechanism, a sample module[3] was created, but
not included in this patch series, which demonstrates the use of 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 -> Module that demonstrates how to use
           DAMOS_QUOTA_HUGEPAGE_MEM_BP and DAMOS_QUOTA_GOAL_TUNER_TEMPORAL
Patch 3 -> Document hugepage_mem_bp parameter

Changes from previous versions
==============================
v1[6] -> v2
  - Rebased onto updated mm-new
  - Removed the sample module altogether, since it will
    increase maintenance costs[7]
  - Document hugepage_mem_bp in design.rst

RFC 4[8] -> 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[9] -> 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[10] -> 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 [11]
  - Fixed typos and added quota_sz to the documentation
    discovered by sashiko [12]

RFC 1[13] -> 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.[14]

[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/20260616150316.580819-1-gutierrez.asier@huawei-partners.com
[7] https://lore.kernel.org/20260618150806.4633-1-sj@kernel.org
[8] https://lore.kernel.org/20260611150244.3454699-1-gutierrez.asier@huawei-partners.com
[9] https://lore.kernel.org/20260604150338.501128-1-gutierrez.asier@huawei-partners.com
[10] https://lore.kernel.org/20260522145518.158910-1-gutierrez.asier@huawei-partners.com
[11] https://lore.kernel.org/20260522171210.900B11F00A3D@smtp.kernel.org
[12] https://lore.kernel.org/20260522171633.AAF5B1F000E9@smtp.kernel.org
[13] https://lore.kernel.org/20260430134139.2446417-1-gutierrez.asier@huawei-partners.com
[14] 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                   | 14 ++++++++++++++
 mm/damon/sysfs-schemes.c          |  4 ++++
 4 files changed, 22 insertions(+)

-- 
2.43.0

[RESEND PATCH v2 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.

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

diff --git a/include/linux/damon.h b/include/linux/damon.h
index f69442a9d431..a36be33a6da4 100644
--- a/include/linux/damon.h
+++ b/include/linux/damon.h
@@ -151,6 +151,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.
@@ -165,6 +166,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 6c4215cc809e..d1f0af4f02b1 100644
--- a/mm/damon/core.c
+++ b/mm/damon/core.c
@@ -3004,6 +3004,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)
 {
@@ -3035,6 +3046,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

Re: [RESEND PATCH v2 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] Calculation of the huge page memory ratio in `damos_hugepage_mem_bp()` can trigger a divide-by-zero kernel panic if the calculated total memory evaluates to zero.
- [Medium] The new metric `DAMOS_QUOTA_HUGEPAGE_MEM_BP` is not exposed to the DAMON sysfs interface, making it unconfigurable from userspace.

Pre-existing issues:
- [High] Preexisting division by zero vulnerability in `damos_get_in_active_mem_bp()` when LRU memory is empty.
- [High] A user-controlled target_value of 0 will cause a divide-by-zero panic during quota scoring.
--

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

mm/damon: Introduce DAMOS_QUOTA_HUGEPAGE auto tuning

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.

> diff --git a/include/linux/damon.h b/include/linux/damon.h
> index 02ac34537df9a..6f87ec40db8ca 100644
> --- a/include/linux/damon.h
> +++ b/include/linux/damon.h
> @@ -162,6 +162,7 @@ enum damos_action {
>   * @DAMOS_QUOTA_INACTIVE_MEM_BP:	Inactive to total LRU memory ratio.
>   * @DAMOS_QUOTA_NODE_ELIGIBLE_MEM_BP:	Scheme-eligible memory ratio of a
>   *					node in basis points (0-10000).
> + * @DAMOS_QUOTA_HUGEPAGE_MEM_BP:	Huge page to total used memory ratio.

[Severity: Medium]
Will this new metric be configurable from userspace?

It looks like damos_sysfs_qgoal_metric_names[] in mm/damon/sysfs-schemes.c
was not updated, which might cause target_metric_store() to return -EINVAL
when trying to configure this metric via sysfs.

[ ... ]

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

[Severity: High]
This isn't a bug introduced by this patch, but can total be zero here?

If the system has exactly 0 active and 0 inactive LRU pages (which could
happen if all memory is locked, used strictly by slab, or on tiny setups),
total would be 0. This might cause a divide-by-zero panic in mult_frac().

>  
> +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]
Could total evaluate to zero here?

Due to per-CPU drift in the vm_stat counters (global_zone_page_state),
NR_FREE_PAGES could momentarily equal totalram_pages(). Passing total == 0
to mult_frac() will trigger a divide-by-zero kernel panic when the schema
is evaluated. Should we add a check for !total before calculating the
fraction?

[ ... ]

[Severity: High]
This is a pre-existing issue, but I noticed another potential
divide-by-zero related to these quota goals.

In mm/damon/sysfs-schemes.c:target_value_store(), user input is parsed via
kstrtoul() directly into goal->target_value without validating that it is
non-zero:

    int err = kstrtoul(buf, 0, &goal->target_value);
    return err ? err : count;

Later, when the DAMON thread evaluates the quota score,
mm/damon/core.c:damos_quota_score() does:

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

Could a user writing 0 to the target_value sysfs file cause a predictable
and immediate system crash here?

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

[RESEND PATCH v2 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 329cfd0bbe9f..4b5429a5b415 100644
--- a/mm/damon/sysfs-schemes.c
+++ b/mm/damon/sysfs-schemes.c
@@ -1267,6 +1267,10 @@ struct damos_sysfs_qgoal_metric_name damos_sysfs_qgoal_metric_names[] = {
 		.metric = DAMOS_QUOTA_NODE_ELIGIBLE_MEM_BP,
 		.name = "node_eligible_mem_bp",
 	},
+	{
+		.metric = DAMOS_QUOTA_HUGEPAGE_MEM_BP,
+		.name = "hugepage_mem_bp",
+	},
 };
 
 static ssize_t target_metric_show(struct kobject *kobj,
-- 
2.43.0

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

[gutierrez.asier]

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

Document huge_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 2da7ca0d3d17..34d940a13a85 100644
--- a/Documentation/mm/damon/design.rst
+++ b/Documentation/mm/damon/design.rst
@@ -686,6 +686,8 @@ mechanism tries to make ``current_value`` of ``target_metric`` be same to
   (1/10,000).
 - ``inactive_mem_bp``: Inactive to active + inactive (LRU) memory size ratio 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 only ``node_mem_used_bp``,
 ``node_mem_free_bp``, ``node_memcg_used_bp`` and ``node_memcg_free_bp`` to
-- 
2.43.0

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

[sashiko-bot]

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

New issues:
- [High] Potential division by zero in `damos_hugepage_mem_bp()` when computing the hugepage memory ratio due to an unvalidated denominator.
- [Low] Inaccurate metric name in the commit message.

Pre-existing issues:
- [High] Potential division by zero in `damos_get_in_active_mem_bp()` when calculating the active/inactive memory ratio.
- [High] Potential division by zero in `damos_get_node_mem_bp()` and `damos_get_node_memcg_used_bp()` when a NUMA node's managed pages evaluate to 0.
--

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

Docs/mm/damon/design: Document hugepage_mem_bp target metric

This commit documents the hugepage_mem_bp metric exposed by sysfs for
DAMON quota goals. It updates the design documentation to include the new
ratio of huge pages to total used memory.

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

[Severity: Low]
This isn't a bug, but is the metric name in the commit message accurate?
The code and the subject line refer to hugepage_mem_bp, but the commit
description refers to huge_mem_bp.

[ ... ]

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

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

If the sum of active and inactive LRU pages is zero (e.g., in highly
constrained environments or due to negative per-CPU counter drift), total
evaluates to 0.

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

Passing total to mult_frac() without validating if it is non-zero
can crash the kernel via a division 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]
Does this code risk a division by zero panic?

The calculation unconditionally passes total as the denominator to
mult_frac() without validating it. 

Because global_zone_page_state() reads from atomic per-CPU counters without
strict synchronization, it can temporarily drift. If this per-CPU drift causes
NR_FREE_PAGES to equal totalram_pages(), total will evaluate exactly to 0,
crashing the kernel when the quota goal is evaluated.

> +}

[ ... ]

While reviewing the DAMON quota calculations in mm/damon/core.c, I noticed
some pre-existing regressions in related functions:

[Severity: High]
This isn't a bug introduced by this patch, but are damos_get_node_mem_bp()
and damos_get_node_memcg_used_bp() susceptible to a division by zero?

In both functions, if a NUMA node has N_MEMORY set while all its memory is
reserved (meaning zone_managed_pages is 0), si_meminfo_node() sets i.totalram
to 0.

mm/damon/core.c:damos_get_node_mem_bp() {
    ...
    si_meminfo_node(&i, goal->nid);
    if (goal->metric == DAMOS_QUOTA_NODE_MEM_USED_BP)
        numerator = i.totalram - i.freeram;
    else
        numerator = i.freeram;
    return mult_frac(numerator, 10000, i.totalram);
}

mm/damon/core.c:damos_get_node_memcg_used_bp() {
    ...
    si_meminfo_node(&i, goal->nid);
    ...
    return mult_frac(numerator, 10000, i.totalram);
}

Passing i.totalram as the denominator to mult_frac() without checking if it
is zero will trigger a division by zero panic. Users configuring DAMOS with
node-specific metrics on a node with zero managed pages can reliably trigger
this.

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

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

[SJ Park]

Hello Asier,

On Tue, 14 Jul 2026 15:01:13 +0000 <gutierrez.asier@huawei-partners.com> wrote:

> From: Asier Gutierrez <gutierrez.asier@huawei-partners.com>
> 
> Overview
> ========
> 
> This patch set introduces a new autotuning which allows to collapse
> hot regions into hugepages.

I sincerely appreciate your continued work on this.  But, I have to say I'm
holding review of this series for below reason...

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

You told me [1] you will rephrase the above.  But I show no change from the
previous version.

Asier, this is a repeated pattern that makes me reviewing this series very
difficult and tiresome.  I don't really want to waste our time on repeating
same words.  I know you did this great job so far and you can make it well
completed.  Could you please thoroughly and carefully review "all" previous
discussions, address all the comments and resend the new version?

Particularly, please note that I also asked [2] you a question about Sashiko
review, and I'm still waiting for your answer.  If you don't have a very good
and confident answer, I'd recommend simply adding the zero-case check.

To avoid wasting our time repeating same words, I skip reviewing the remainder
of this version of the series.  I will review the next version.

[1] https://lore.kernel.org/b786294f-0ba5-4b05-b956-d902c358dd88@huawei-partners.com
[2] https://lore.kernel.org/20260617041515.98906-1-sj@kernel.org


Thanks,
SJ

[...]