Re: [RFC PATCH v1 3/4] mm/damon: introduce DAMON_HUGEPAGE for hot region hugepage collapsing

From: SeongJae Park

Date: Thu Apr 30 2026 - 20:55:16 EST


On Thu, 30 Apr 2026 13:41:38 +0000 <gutierrez.asier@xxxxxxxxxxxxxxxxxxx> wrote:

> From: Asier Gutierrez <gutierrez.asier@xxxxxxxxxxxxxxxxxxx>
>
> This patch introduces a new DAMON module (DAMON_HUGEPAGE)
> which collapses hot regions into huge pages.
>
> DAMON_HUGEPAGE operates in the virtual memory space, for a
> specific task.

The new quota goal is for global memory, isn't it? Why use global memory goal
for virtual address based scheme?

I understand it makes sense to monitor virtual address space for collapsing.
If we have to do collapsing, should we modify the quota goal to work for only
given task's virtual address space?

Also, what about split? Should we also split huge pages into regular pages if
it is cold? Maybe that could work on physical address space, and use the
proposed quota goal as is?

> The user is expected to supply the PID of
> the task that is going to be monitored through the
> monitored_pid module variable.
>
> DAMON_HUGEPAGE uses the hugepage auto-tune mechanism to
> increase or decrease the aggressiveness of page collapsing.
> User autotuning is also available for additional tuning
> aggressiveness control.
>
> The module also includes changes to the DAMON compilation,
> so that the module can be enabled or disabled.
>
> Signed-off-by: Asier Gutierrez <gutierrez.asier@xxxxxxxxxxxxxxxxxxx>
> ---
> mm/damon/Kconfig | 7 +
> mm/damon/Makefile | 1 +
> mm/damon/hugepage.c (new) | 341 ++++++++++++++++++++++++++++++++++++++

The cover letter was saying this module is for demonstrating the usage of the
new goal type, but this is not a sample module. Let's make sure what is the
purpose of this module, and decide where to put it based on that.

I will skip detailed code review until the above high level question is
answered, as depending on the conclusion the code may be changed a lot.


Thanks,
SJ

[...]