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

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [High] Unbounded metric calculation due to vmstat drift can destabilize quota tuning.
- [High] Silent 32-bit integer overflow in mult_frac() during memory ratio calculation. --

commit 59f2c739bce03363ce501965d6708d807908af18

Author: Asier Gutierrez <[email protected]>
Date:   Mon Aug 31 14:47:28 2026 +0000

mm/damon: Introduce DAMOS_QUOTA_HUGEPAGE auto tuning

This commit introduces a new DAMOS quota goal metric, DAMOS_QUOTA_HUGEPAGE_MEM_BP, to auto-tune quotas based on the ratio of huge page consumption to total memory consumption. It includes a fallback mechanism for situations where vmstat counters drift and report more free pages than total RAM.

Link https://lore.kernel.org/all/[email protected]/ open here

[ ... ]

Quoted 4 lines

mm/damon/core.c +0 -0

index 644daf5a16560..9c0e42a1d2cfc 100644

[ ... ]

Quoted 8 lines

mm/damon/core.c +4 -0

@@ -3007,6 +3007,22 @@ 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_pages, free_pages;
+

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

Quoted 10 lines

mm/damon/core.c +10 -0

+	total_pages = totalram_pages();
+	free_pages = global_zone_page_state(NR_FREE_PAGES);
+
+	if (total_pages <= free_pages)
+		return 10000;
+
+	thp = global_node_page_state(NR_ANON_THPS) +
+				global_node_page_state(NR_SHMEM_THPS) +
+				global_node_page_state(NR_FILE_THPS);
+	return mult_frac(thp, 10000, total_pages - free_pages);

[Severity: High]
Could the independent vmstat counters drift enough to produce an out-of-bounds ratio here?

Because NR_ANON_THPS, NR_SHMEM_THPS, NR_FILE_THPS, and NR_FREE_PAGES are updated asynchronously across CPUs, they can drift in opposite directions. On systems with high core counts, if the system's actual used memory is low but the thp stat artificially drifts higher than the calculated used memory (or used memory drifts toward zero), the calculated ratio could vastly exceed 10,000 (100%).

Would this cause the DAMOS auto-tuning PID controller to calculate an exponentially inflated goal score, ultimately crushing the tuning quota to zero and paralyzing DAMON's actions?

[Severity: High]
Can this calculation silently overflow on 32-bit architectures?

The mult_frac macro evaluates an intermediate multiplication that retains the 32-bit type of x. Both thp and total_pages are declared as unsigned long.

On 32-bit architectures like ARM32 with LPAE (which supports Transparent Hugepages and up to 1TB RAM), unsigned long is 32 bits. If THP consumption exceeds 429,496 base pages (around 1.71 GB), the intermediate calculation (thp * 10000) will wrap around U32_MAX.

For example, 2GB of THP on a 3GB system might falsely report a 9.4% ratio instead of 66.6%. Will this cause DAMON to mis-tune memory limits due to a highly truncated quota goal metric?

Quoted 3 lines

mm/damon/core.c +2 -0

+}
+

Signature · 1 line

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

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.

Hi SJ and Asier,

Thanks for working on this and for providing the server results. I have two questions about what hugepage_mem_bp is intended to represent.

Quoted 3 lines

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.

First, NR_ANON_THPS tracks anonymous PMD mappings, while NR_SHMEM_THPS and NR_FILE_THPS track PMD-mappable page-cache folios. Therefore, splitting only an anonymous PMD mapping can change hugepage_mem_bp without physically splitting the folio. Is the intended metric PMD-mapped memory or physical large-folio memory? Clarifying this and adding a mapping-only test may help.

Second, the metric is global while a DAMOS scheme can target one process.

THPs from other processes or NUMA nodes can satisfy the target or dilute the monitored process's changes. Is this intentional?

If so, documenting the
scope and testing a background THP workload may be useful.

The temporal results approach the 10% and 25% targets, while the consistent results overshoot the 10% target to about 20% and 45%. I would describe this as control-response data. TPS, latency, TLB, fragmentation and collapse CPU data could further show the workload benefit and cost.

If I have misunderstood any of this, please feel free to ignore these comments and correct me.

The enum, quota-goal wiring and sysfs exposure otherwise look consistent with the existing DAMOS autotuning framework. I consider the points above follow-up questions about semantics and evaluation, rather than blockers for this series.

For the series:

Reviewed-by Lian Wang <[email protected]>

Please feel free to Cc me on related follow-up patches. I am happy to help review the code. Besides my own DAMON work, I have recently been reviewing and learning from other DAMON and MM work, and I would be glad to continue.

Seems using MTHP_STAT_NR_ANON that is exposed as 'nr_anon' can be used?

I'm curious if you and general reviewers need or prefer to directly be Cc-ed. I was naively thinking people can search and review DAMON patches by subscribing to the mailing list or using the archives via lore.kernel.org like tools.

Hi SJ,

Quoted 1 line

Seems using MTHP_STAT_NR_ANON that is exposed as 'nr_anon' can be used?

Thank you for the suggestion. I will study MTHP_STAT_NR_ANON and nr_anon further, and document what I find. We can continue discussing it by email, and I will be happy to review any follow-up or updated patches.

Quoted 4 lines

I'm curious if you and general reviewers need or prefer to directly be Cc-ed. I was naively thinking people can search and review DAMON patches by subscribing to the mailing list or using the archives via lore.kernel.org like tools.

I subscribe to many mailing lists, including linux-mm and DAMON, and I also follow patches through lore. Direct Cc is not required, but I appreciate it for DAMON-related patches. Because I care deeply about DAMON, directly Cc-ed messages are filtered into my important mailbox, so I can archive and review them quickly.

I am very happy to contribute to DAMON, and I look forward to continuing our discussions and reviews by email.

Quoted 13 lines · On Wed, 2 Sep 2026 09:56:01 +0800 Lian Wang <[email protected]…

Hi SJ,

Quoted 1 line

Seems using MTHP_STAT_NR_ANON that is exposed as 'nr_anon' can be used?

Thank you for the suggestion. I will study MTHP_STAT_NR_ANON and nr_anon further, and document what I find. We can continue discussing it by email, and I will be happy to review any follow-up or updated patches.

Quoted 4 lines

I'm curious if you and general reviewers need or prefer to directly be Cc-ed. I was naively thinking people can search and review DAMON patches by subscribing to the mailing list or using the archives via lore.kernel.org like tools.

Quoted 5 lines

I subscribe to many mailing lists, including linux-mm and DAMON, and I also follow patches through lore. Direct Cc is not required, but I appreciate it for DAMON-related patches. Because I care deeply about DAMON, directly Cc-ed messages are filtered into my important mailbox, so I can archive and review them quickly.

Thank you so much for your interest in DAMON, Lian. But, the problem is that my memory is so bad. :'(

I am maintaing mm patches review status dashboard for people who want to find patches that waiting for their review. It also provides the review status for each sub-mm components [2] including DAMON [3]. Maybe finding patches that waiting for your review from the dashboard is also a way for you?

If having the mail directly in your important mailbox is what you need, I believe adding mails filtering rule for DAMON patches wouldn't be that difficult. If you use hkml, it could also help you monitoring [4] those.

Yet another systematic and long term solution that I could suggest is keep reviewing and posting DAMON patches one by one, build more tracked records and trusts, eventually adding your name as DAMON reviewer or maintainer on the MAINTAINERS file. All patches sent with get_maintainers.pl will automatically Cc you. It would take time and require patience, though, of course.

Quoted 4 lines

I am very happy to contribute to DAMON, and I look forward to continuing our discussions and reviews by email.

I really appreciate your interest and contributions to DAMON. I hope it to be continued long term!

[1] https://github.com/sjp38/mm_git_dashboard
[2] https://github.com/sjp38/mm_git_dashboard/tree/master/summary/subsystem
[3] https://github.com/sjp38/mm_git_dashboard/tree/master/summary/subsystem/DAMON
[4] https://github.com/sjp38/hackermail/blob/master/USAGE.md#monitoring-mails

Thanks,
SJ

[...]

Hi Lian,

Quoted 9 lines · On Tue, 1 Sep 2026 14:58:35 +0800 Lian Wang <[email protected]> wrote:

Hi SJ and Asier,

Thanks for working on this and for providing the server results. I have two questions about what hugepage_mem_bp is intended to represent.

Quoted 3 lines

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.

Quoted 5 lines

First, NR_ANON_THPS tracks anonymous PMD mappings, while NR_SHMEM_THPS and NR_FILE_THPS track PMD-mappable page-cache folios. Therefore, splitting only an anonymous PMD mapping can change hugepage_mem_bp without physically splitting the folio. Is the intended metric PMD-mapped memory or physical large-folio memory? Clarifying this and adding a mapping-only test may help.

Good point. I was just missing this. So, hugepage_mem_bp is not accounting anon mTHPs, right? Since hugepage_mem_bp is for general hugepages, I think this is better to be improved. Seems using MTHP_STAT_NR_ANON that is exposed as 'nr_anon' can be used? Because this is an improvement rather than a fix of a bug, I think doing this as either a followup or new version of this series are ok. Asier, what do you think?

Quoted 1 line

Second, the metric is global while a DAMOS scheme can target one process.

Actually it can target multiple processes if those are in single DAMON context.

Quoted 2 lines

THPs from other processes or NUMA nodes can satisfy the target or dilute the monitored process's changes. Is this intentional?

I think it is intentional. The user should have the control on collapsing hugepages, or believe the uncontrolled collapse mechanisms.

Quoted 2 lines

If so, documenting the
scope and testing a background THP workload may be useful.

More documentation and testing are always welcome :)

Quoted 1 line

Quoted 4 lines

The temporal results approach the 10% and 25% targets, while the consistent results overshoot the 10% target to about 20% and 45%. I would describe this as control-response data. TPS, latency, TLB, fragmentation and collapse CPU data could further show the workload benefit and cost.

Yes, those would be helpful. That's not mandatory for this simple change in my opinion, though. I would let Asier decide whether and when to make and share such data.

Quoted 2 lines

If I have misunderstood any of this, please feel free to ignore these comments and correct me.

Your comments are very helpful, thank you for your review and comments, Lian.

Quoted 5 lines

The enum, quota-goal wiring and sysfs exposure otherwise look consistent with the existing DAMOS autotuning framework. I consider the points above follow-up questions about semantics and evaluation, rather than blockers for this series.

I agree.

Quoted 4 lines

For the series:

Reviewed-by Lian Wang <[email protected]>

Thank you!

Quoted 4 lines

Please feel free to Cc me on related follow-up patches. I am happy to help review the code. Besides my own DAMON work, I have recently been reviewing and learning from other DAMON and MM work, and I would be glad to continue.

I'm curious if you and general reviewers need or prefer to directly be Cc-ed. I was naively thinking people can search and review DAMON patches by subscribing to the mailing list or using the archives via lore.kernel.org like tools.

Thanks,
SJ

[...]

Hi SJ and Lian,

Quoted 4 lines · SJ Park

Hi Lian,

On Tue, 1 Sep 2026 14:58:35 +0800 Lian Wang <[email protected]> wrote:

Quoted 16 lines

Quoted 1 line

Second, the metric is global while a DAMOS scheme can target one process.

Actually it can target multiple processes if those are in single DAMON context.

Quoted 2 lines

THPs from other processes or NUMA nodes can satisfy the target or dilute the monitored process's changes. Is this intentional?

I think it is intentional. The user should have the control on collapsing hugepages, or believe the uncontrolled collapse mechanisms.

Quoted 2 lines

If so, documenting the
scope and testing a background THP workload may be useful.

More documentation and testing are always welcome :)

Quoted 1 line

Quoted 8 lines

Quoted 4 lines

The temporal results approach the 10% and 25% targets, while the consistent results overshoot the 10% target to about 20% and 45%. I would describe this as control-response data. TPS, latency, TLB, fragmentation and collapse CPU data could further show the workload benefit and cost.

Yes, those would be helpful. That's not mandatory for this simple change in my opinion, though. I would let Asier decide whether and when to make and share such data.

The idea of this patch was to introduce auto tuning. I think I submitted thebenchmark results when I sent the DAMOS_COLLAPSE feature.

Anyway, it shouldn't take long for me to get more data. I think it may be useful for people to know the actual results in real application.

SJ, what's the best place to publish all those data? I believe you have more experience sharing this data and which platform is the most useful one.>>

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] The new hugepage_mem_bp metric is missing from the sysfs selftests. --

commit a2c5ad81dadcc820e74efd9d73c1f576bbe76457
Author: Asier Gutierrez <[email protected]>

mm/damon/sysfs: support hugepage_mem_bp quota goal metric

This commit introduces the new DAMOS_QUOTA_HUGEPAGE_MEM_BP autotune policy metric. It also exposes this metric to userspace through the sysfs-schemes interface by adding "hugepage_mem_bp" to the list of recognized metrics.

Quoted 4 lines

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

index 32f495a96b17a..d9b81d7b5910e 100644

[ ... ]

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

Quoted 8 lines

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

@@ -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: Medium]
Should the new hugepage_mem_bp metric be added to the DAMON sysfs kselftest?

Looking at tools/testing/selftests/damon/sysfs.sh in test_goal(), it explicitly validates all supported metric strings by writing them to the sysfs node:

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

Without adding hugepage_mem_bp to this selftest script, the new sysfs metric is left without automated test coverage.

Quoted 4 lines

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

 };
 
 static ssize_t target_metric_show(struct kobject *kobj,

Signature · 1 line

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

From: Asier Gutierrez <[email protected]>

Document hugepage_mem_bp metric exposed by sysfs.

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

Reviewed-by SJ Park <[email protected]>

Signed-off-by SJ Park <[email protected]>

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

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

index aed6cb1cf4831..a8c163475ef2b 100644

Hi,

Quoted 22 lines · SJ Park

From: Asier Gutierrez <[email protected]>

Document hugepage_mem_bp metric exposed by sysfs.

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

Reviewed-by SJ Park <[email protected]>

Signed-off-by SJ Park <[email protected]>

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

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

index aed6cb1cf4831..a8c163475ef2b 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).
 

Documentation/mm/damon/design.rst mechanism tries to make ``current_value`` of ``target_metric`` be same to · line 720

Quoted 2 lines

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

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

I've looked thru the entire design.rst file and cannot find anything telling me (or anyone) what "bp" means. Explain??

Quoted 25 lines · Randy Dunlap

Hi,

Quoted 22 lines · SJ Park

From: Asier Gutierrez <[email protected]>

Document hugepage_mem_bp metric exposed by sysfs.

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

Reviewed-by SJ Park <[email protected]>

Signed-off-by SJ Park <[email protected]>

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

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

index aed6cb1cf4831..a8c163475ef2b 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).
 

Quoted 5 lines

Documentation/mm/damon/design.rst mechanism tries to make ``current_value`` of ``target_metric`` be same to · line 720

Quoted 2 lines

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

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

I've looked thru the entire design.rst file and cannot find anything telling me (or anyone) what "bp" means. Explain??

OK, I found it on the internet. I still think that it would be a good idea to say "basis point" one time (the first time that it is used).

Signature · 2 lines

-- 
~Randy

On Mon, 31 Aug 2026 13:00:26 -0700 Randy Dunlap <[email protected]> wrote:

Quoted 29 lines · Randy Dunlap

Quoted 25 lines

Hi,

Quoted 22 lines · SJ Park

From: Asier Gutierrez <[email protected]>

Document hugepage_mem_bp metric exposed by sysfs.

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

Reviewed-by SJ Park <[email protected]>

Signed-off-by SJ Park <[email protected]>

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

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

index aed6cb1cf4831..a8c163475ef2b 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).
 

Quoted 8 lines

Quoted 5 lines

Documentation/mm/damon/design.rst mechanism tries to make ``current_value`` of ``target_metric`` be same to · line 720

Quoted 2 lines

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

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

I've looked thru the entire design.rst file and cannot find anything telling me (or anyone) what "bp" means. Explain??

OK, I found it on the internet. I still think that it would be a good idea to say "basis point" one time (the first time that it is used).

You are right, and I agree. I will add that clarification before the next merge window.

Quoted 2 lines

Quoted 2 lines

Signature · 1 line

~Randy

Thanks,
SJ

Quoted 1 line · SJ Park

On Mon, 31 Aug 2026 13:00:26 -0700 Randy Dunlap <[email protected]> wrote:

Hi,

Quoted 43 lines

Quoted 29 lines · Randy Dunlap

Quoted 25 lines

Hi,

Quoted 22 lines · SJ Park

From: Asier Gutierrez <[email protected]>

Document hugepage_mem_bp metric exposed by sysfs.

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

Reviewed-by SJ Park <[email protected]>

Signed-off-by SJ Park <[email protected]>

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

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

index aed6cb1cf4831..a8c163475ef2b 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).
 

Quoted 8 lines

Quoted 5 lines

Documentation/mm/damon/design.rst mechanism tries to make ``current_value`` of ``target_metric`` be same to · line 720

Quoted 2 lines

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

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

I've looked thru the entire design.rst file and cannot find anything telling me (or anyone) what "bp" means. Explain??

OK, I found it on the internet. I still think that it would be a good idea to say "basis point" one time (the first time that it is used).

You are right, and I agree. I will add that clarification before the next merge window.

Quoted 2 lines

Quoted 6 lines

Quoted 2 lines

Signature · 1 line

~Randy

Thanks,
SJ

SJ, should I submit a new patch to fix design.rst?

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [High] Integer overflow in mult_frac on 32-bit systems for memory exceeding ~1.75 GB of huge pages, resulting in incorrect DAMOS quota auto-tuning.
- [Medium] The newly introduced DAMOS quota goal metric 'hugepage_mem_bp' is not tested in the DAMON sysfs selftests.
--

commit 59f2c739bce03363ce501965d6708d807908af18
Author: Asier Gutierrez <[email protected]>

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.

Link https://lore.kernel.org/all/[email protected]/ open here

Quoted 4 lines

mm/damon/core.c +0 -0

index 644daf5a16560..9c0e42a1d2cfc 100644

[ ... ]

Quoted 8 lines

mm/damon/core.c +4 -0

@@ -3007,6 +3007,22 @@ 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_pages, free_pages;
+

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

Quoted 10 lines

mm/damon/core.c +10 -0

+	total_pages = totalram_pages();
+	free_pages = global_zone_page_state(NR_FREE_PAGES);
+
+	if (total_pages <= free_pages)
+		return 10000;
+
+	thp = global_node_page_state(NR_ANON_THPS) +
+				global_node_page_state(NR_SHMEM_THPS) +
+				global_node_page_state(NR_FILE_THPS);
+	return mult_frac(thp, 10000, total_pages - free_pages);

[Severity: High]
Does this calculation overflow on 32-bit systems?

Since thp is an unsigned long, on a 32-bit architecture it is a 32-bit integer. If the system has more than ~1.75 GB of huge pages (about 429,496 pages), the internal multiplication thp * 10000 will exceed 4,294,967,295 and wrap around.

This leads to an incorrect value being returned from mult_frac() and results in incorrect DAMOS auto-tuning.

commit a2c5ad81dadcc820e74efd9d73c1f576bbe76457
Author: Asier Gutierrez <[email protected]>

mm/damon/sysfs: support hugepage_mem_bp quota goal metric

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

Quoted 4 lines

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

index 32f495a96b17a..d9b81d7b5910e 100644

[ ... ]

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

Quoted 9 lines

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

@@ -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: Medium]
Should there be an accompanying update to the selftests for this new sysfs metric?

Currently, the hugepage_mem_bp metric is missing from the tests. For example, in tools/testing/selftests/damon/sysfs.sh:test_goal(), the new metric is not verified:

tools/testing/selftests/damon/sysfs.sh:test_goal() {
...
ensure_write_succ "$fpath" "node_eligible_mem_bp" "valid input" ensure_write_fail "$fpath" "foo" "invalid input"
...
}

Running the sysfs.sh selftest will silently skip testing the new metric because it wasn't added to the hardcoded list of valid inputs.

Signature · 2 lines

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

From: Asier Gutierrez <[email protected]>

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