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

[SeongJae Park]

On Fri, 22 May 2026 14:55:14 +0000 <gutierrez.asier@xxxxxxxxxxxxxxxxxxx> wrote:

> From: Asier Gutierrez <gutierrez.asier@xxxxxxxxxxxxxxxxxxx>
> 
> Overview
> ========
> 
> This patch set introduces a new autotuning which allows to collapse
> hot regions into hugepages.
[...]
> 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.

Agree.

> 
> A new autotuning quota goal[2], damos_get_used_hugepage_mem_bp,

Is the name correct?  I think 'get_used_' may better to be dropped.

> is
> introduced, which checks the huge page consumption to total anonymous
> memory consumption. This new quota mechanism reuses current autotuning
> architecture.
> 
> A new module is introduced to demonstrate the use of huge pages
> collapse autotuning. The goal is to collapse hot regions of a given
> process into huge pages. The module launches a kdamond thread for a 
> certain task provided by the user through monitored_pid module argument.
> Hugepage goal autotuning will automatically adjust the aggressiveness
> of hot region collapses.

Having a module for the demonstration purpose sounds good.  But, for the
demonstration purpose, as I previousoly commented, making it as a sample module
(put under /samples/damon/) or just drop when you drop RFC tag would be better.

Let me know if this module is aimed to be as is even after you drop RFC tag.

> 
> This module also has a user autotuning knob which allows the user to
> adjust the aggressiveness of page collapsing.
> 
> Benchmarks
> ==========
> 
> Huge page collapse autotuning was tested in a physicial machine with
> MariaDB 10.5.29 and sysbench as the benchmark framework.
> 
> The hugepage module was set up in the following way:
> 
> # echo 1000 > min_age
> # echo 1000 > quota_percentage_hugepage
> # echo $(pidof mariadbd) > monitored_pid
> # echo on > enabled
> 
> The goal was to achieve 10% of the total memory used as hugepage.
> 
> The table below shows the memory consumption over time. Gaps in the
> timestamp means that no changes in the hugepage consumption happened
> over that period of time.
> 
> +-----------+----------------+---------------+----------------------+
> | timestamp | anon_memory_mb | huge_pages_mb | percentage hugepage  |
> +-----------+----------------+---------------+----------------------+
> | 0         | 2159.761719    | 0             | 0%                   |
> | 28        | 2177.574219    | 4             | 0%                   |
[...]
> | 283       | 2224.601563    | 434           | 20%                  |
> | 284       | 2224.632813    | 450           | 20%                  |
> +-----------+----------------+---------------+----------------------+

Thank you for sharing the test.  What about the performance?  Could you also do
comparison of the numbers against the module disabled case, and THP disabled
case?

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

You are correct.  If the behavior disturbs your test, please note that we
introduced 'temporal' quota tuner [1] to make it easier.  It is merged into
7.1-rc1.

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

Sounds good!  By using two DAMOS schemes that doing collapsing and splitting, I
think we can make more complete access-aware THP system.

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

Patch 1 is only for Patch 3, right?  Let's put it just before patch 3.

[1] https://lkml.kernel.org/r/20260310010529.91162-2-sj@xxxxxxxxxx


Thanks,
SJ

[...]