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

PATCH In review [email protected] 3 participants 16 messages Jul 20 – Jul 23

Subsystems (4)

Memory management Documentation MM misc DAMON

lore

Share & tools

lore

[email protected]

author

2026-07-20 12:01 UTC #0 lore raw

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

From: Asier Gutierrez <[email protected]>

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

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

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]

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

Signature · 1 line

2.43.0

[email protected]

author

2026-07-20 12:01 UTC #1 lore raw

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

From: Asier Gutierrez <[email protected]>

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

Signed-off-by Asier Gutierrez <[email protected]>

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

include/linux/damon.h +2 -0

index 327f534696aa..0d0b7bb233b7 100644
@@ -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,
 };

mm/damon/core.c +21 -0

index 603b102ff80f..73aaee43c6f7 100644
@@ -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;
 	}

Signature · 1 line

2.43.0

[email protected]

AI review

2026-07-20 12:17 UTC #2 lore raw

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

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

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

Quoted 3 lines

include/linux/damon.h +0 -0

[ ... ]

include/linux/damon.h enum damos_quota_goal_metric { · line 171

Quoted 5 lines

include/linux/damon.h +1 -0

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

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

Quoted 8 lines

include/linux/damon.h +0 -0

 	NR_DAMOS_QUOTA_GOAL_METRICS,
 };

mm/damon/core.c +0 -0

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

Quoted 7 lines

mm/damon/core.c +5 -0

 }
 
+static unsigned int damos_hugepage_mem_bp(void)
+{
+	unsigned long thp, total;
+
+	thp = global_node_page_state(NR_ANON_THPS) +

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

Quoted 10 lines

mm/damon/core.c +10 -0

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

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

Quoted 1 line

mm/damon/core.c +1 -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?

Quoted 1 line

mm/damon/core.c +1 -0
+}

Signature · 1 line

Sashiko AI review · https://sashiko.dev/#/patchset/[email protected]?part=1

SJ Park

maintainer

2026-07-21 03:47 UTC #3 lore raw

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

Quoted 36 lines · On Mon, 20 Jul 2026 12:16:57 +0000 [email protected] 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 <[email protected]>
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/[email protected]/ open here
Quoted 3 lines
include/linux/damon.h +0 -0
[ ... ]
include/linux/damon.h enum damos_quota_goal_metric { · line 171
Quoted 5 lines
include/linux/damon.h +1 -0
@@ -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?

Quoted 7 lines

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.

Quoted 13 lines

mm/damon/core.c static unsigned int damos_get_in_active_mem_bp(bool active_ratio) · line 3007
Quoted 9 lines
include/linux/damon.h +0 -0
 	NR_DAMOS_QUOTA_GOAL_METRICS,
 };
 
mm/damon/core.c +0 -0
@@ -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?

Quoted 7 lines

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.

Quoted 22 lines

Quoted 8 lines

mm/damon/core.c +5 -0

 }
 
+static unsigned int damos_hugepage_mem_bp(void)
+{
+	unsigned long thp, total;
+
+	thp = global_node_page_state(NR_ANON_THPS) +

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

Quoted 10 lines

mm/damon/core.c +10 -0

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

Quoted 8 lines

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.

Quoted 6 lines

mm/damon/core.c static unsigned int damos_get_in_active_mem_bp(bool active_ratio) · line 3022
Quoted 2 lines
mm/damon/core.c +1 -0
+	return mult_frac(thp, 10000, total);
[Severity: Medium]
Will this overflow on 32-bit architectures?

Quoted 7 lines

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.

Quoted 6 lines

Quoted 2 lines
mm/damon/core.c +1 -0
+}
Signature · 1 line
Sashiko AI review · https://sashiko.dev/#/patchset/[email protected]?part=1

Thanks,
SJ

[email protected]

author

2026-07-20 12:01 UTC #4 lore raw

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

In reply to [email protected]

From: Asier Gutierrez <[email protected]>

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

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

Signed-off-by Asier Gutierrez <[email protected]>

Reviewed-by SeongJae Park <[email protected]>

---
 mm/damon/sysfs-schemes.c | 4 ++++
 1 file changed, 4 insertions(+)

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

index 32f495a96b17..d9b81d7b5910 100644
@@ -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,

Signature · 1 line

2.43.0

[email protected]

AI review

2026-07-20 12:15 UTC #5 lore raw

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

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…

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

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.

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

Quoted 13 lines

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

index 32f495a96b17a..d9b81d7b5910e 100644
@@ -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.

Signature · 1 line

Sashiko AI review · https://sashiko.dev/#/patchset/[email protected]?part=2

SJ Park

maintainer

2026-07-21 03:50 UTC #6 lore raw

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

Quoted 41 lines · On Mon, 20 Jul 2026 12:15:38 +0000 [email protected] 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 <[email protected]>
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.
mm/damon/sysfs-schemes.c struct damos_sysfs_qgoal_metric_name damos_sysfs_qgoal_metric_names[] = { · line 1276
Quoted 13 lines
mm/damon/sysfs-schemes.c +4 -0
index 32f495a96b17a..d9b81d7b5910e 100644
@@ -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);

Quoted 8 lines

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.

Quoted 8 lines

[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:

Quoted 6 lines

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.

Quoted 8 lines

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

Quoted 4 lines

Signature · 2 lines

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/[email protected]?part=2

Thanks,
SJ

[email protected]

author

2026-07-20 12:01 UTC #7 lore raw

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

In reply to [email protected]

From: Asier Gutierrez <[email protected]>

Document hugepage_mem_bp metric exposed by sysfs.

Signed-off-by Asier Gutierrez <[email protected]>

---
 Documentation/mm/damon/design.rst | 2 ++
 1 file changed, 2 insertions(+)

Documentation/mm/damon/design.rst +2 -0

index aed6cb1cf483..a8c163475ef2 100644
@@ -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

Signature · 1 line

2.43.0

[email protected]

AI review

2026-07-20 12:17 UTC #8 lore raw

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

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

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

Document hugepage_mem_bp metric exposed by sysfs.

Quoted 6 lines

mm/damon/core.c +0 -0

index e0122376f43d4..e38f2ddebb341 100644
@@ -3007,6 +3007,24 @@ static unsigned int damos_get_in_active_mem_bp(bool active_ratio)
 	return mult_frac(inactive, 10000, total);

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

Quoted 10 lines

mm/damon/core.c +8 -0

 }
 
+static unsigned int damos_hugepage_mem_bp(void)
+{
+	unsigned long thp, total;
+
+	thp = global_node_page_state(NR_ANON_THPS) +
+				global_node_page_state(NR_SHMEM_THPS) +
+				global_node_page_state(NR_FILE_THPS);
+	total = totalram_pages() - global_zone_page_state(NR_FREE_PAGES);

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

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

Quoted 7 lines

mm/damon/core.c +7 -0

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

Quoted 2 lines

mm/damon/core.c +2 -0

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

[ ... ]

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

Quoted 13 lines

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

index 32f495a96b17a..d9b81d7b5910e 100644
@@ -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.

Signature · 1 line

Sashiko AI review · https://sashiko.dev/#/patchset/[email protected]?part=3

SJ Park

maintainer

2026-07-21 03:52 UTC #9 lore raw

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

Quoted 4 lines · On Mon, 20 Jul 2026 12:17:23 +0000 [email protected] 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

[...]

SJ Park

maintainer Reviewed-by on the v3 series

2026-07-21 03:58 UTC #10 lore raw

In reply to [email protected]

Hello Asier,

Quoted 6 lines · On Mon, 20 Jul 2026 12:01:37 +0000 <[email protected]> wrote:

From: Asier Gutierrez <[email protected]>
Overview
========
This patch set introduces a new autotuning which allows to collapse hot regions into hugepages.

Thank you for making this series well done like this!

[...]

Quoted 5 lines

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

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

[...]

Gutierrez Asier

author

2026-07-21 12:58 UTC #11 lore raw

Hi SJ,

Quoted 33 lines · SJ Park

Hello Asier,
Quoted 6 lines · On Mon, 20 Jul 2026 12:01:37 +0000 <[email protected]> wrote:
From: Asier Gutierrez <[email protected]>
Overview
========
This patch set introduces a new autotuning which allows to collapse hot regions into hugepages.
Thank you for making this series well done like this!
[...]
Quoted 5 lines
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 <[email protected]>
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.

Quoted 7 lines

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

Signature · 2 lines

Asier Gutierrez
Huawei

SJ Park

maintainer

2026-07-21 14:04 UTC #12 lore raw

Quoted 42 lines · On Tue, 21 Jul 2026 15:58:13 +0300 Gutierrez Asier…

Hi SJ,
Quoted 39 lines · SJ Park
Hello Asier,
Quoted 6 lines · On Mon, 20 Jul 2026 12:01:37 +0000 <[email protected]> wrote:
From: Asier Gutierrez <[email protected]>
Overview
========
This patch set introduces a new autotuning which allows to collapse hot regions into hugepages.
Thank you for making this series well done like this!
[...]
Quoted 5 lines
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 <[email protected]>
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

Quoted 6 lines

Quoted 1 line
[...]
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

[...]

SJ Park

maintainer

2026-07-22 13:45 UTC #13 lore raw

In reply to SJ Park

Quoted 24 lines · On Mon, 20 Jul 2026 20:58:47 -0700 SJ Park <[email protected]> wrote:

Hello Asier,
Quoted 6 lines · On Mon, 20 Jul 2026 12:01:37 +0000 <[email protected]> wrote:
From: Asier Gutierrez <[email protected]>
Overview
========
This patch set introduces a new autotuning which allows to collapse hot regions into hugepages.
Thank you for making this series well done like this!
[...]
Quoted 5 lines
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,

Quoted 8 lines

Reviewed-by SJ Park <[email protected]>
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.

We (mm community) now want to focus on making mm.git more stabilized and therefore ready for the next merge window, rather than adding more changes that are not really urgent. I agree and want to help [1] that. For the reason, unless Andre pick this first, I will request adding this to mm.git only after next -rc1 release. Let me know if you think this is really urgent.

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

Thanks,
SJ

[...]

Gutierrez Asier

author

2026-07-22 13:51 UTC #14 lore raw

Hi SJ,

Quoted 41 lines · SJ Park

Quoted 24 lines · On Mon, 20 Jul 2026 20:58:47 -0700 SJ Park <[email protected]> wrote:
Hello Asier,
Quoted 6 lines · On Mon, 20 Jul 2026 12:01:37 +0000 <[email protected]> wrote:
From: Asier Gutierrez <[email protected]>
Overview
========
This patch set introduces a new autotuning which allows to collapse hot regions into hugepages.
Thank you for making this series well done like this!
[...]
Quoted 5 lines
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,
Quoted 8 lines
Reviewed-by SJ Park <[email protected]>
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.
We (mm community) now want to focus on making mm.git more stabilized and therefore ready for the next merge window, rather than adding more changes that are not really urgent. I agree and want to help [1] that. For the reason, unless Andre pick this first, I will request adding this to mm.git only after next -rc1 release. Let me know if you think this is really urgent.

Quoted 8 lines

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

No problem at all. I am fine with it.

Signature · 2 lines

Asier Gutierrez
Huawei

SJ Park

maintainer

2026-07-23 00:29 UTC #15 lore raw

Quoted 3 lines · On Wed, 22 Jul 2026 16:51:22 +0300 Gutierrez Asier…

Hi SJ,
On 7/22/2026 4:45 PM, SJ Park wrote:

[...]

Quoted 9 lines

Quoted 9 lines
We (mm community) now want to focus on making mm.git more stabilized and therefore ready for the next merge window, rather than adding more changes that are not really urgent. I agree and want to help [1] that. For the reason, unless Andre pick this first, I will request adding this to mm.git only after next -rc1 release. Let me know if you think this is really urgent.
[1] https://lore.kernel.org/[email protected]

Quoted 7 lines

Quoted 5 lines
Thanks,
SJ
[...]
No problem at all. I am fine with it.

Thank you for confirming, Asier!

Thanks,
SJ

[...]