Re: [RFC PATCH v2 0/4] mm/damon: Support hot application detections

Gutierrez Asier
2026-03-11T13:09:01Z

Hi SeongJae,

On 3/11/2026 8:07 AM, SeongJae Park wrote:
> Hello Asier,
>
>
> Thank you for continuing this work!
>
> On Tue, 10 Mar 2026 16:24:16 +0000 <gutierrez.asier@huawei-partners.com> wrote:
>
>> From: Asier Gutierrez <gutierrez.asier@huawei-partners.com>
>>
>> Overview
>> ----------
>
> Let's make the legnth of the subject and the length of the underline same.
>
>>
>> This patch set introduces a new dynamic mechanism for detecting hot applications
>> and hot regions in those applications.
>
> Seems now you offload the hot applications detection to the user space. If I'm
> not wrong, you should remove "hot applications and" on the above sentence.

You're right. I was not sure whether changing the RFC subject was right or not.
I will change it for the next RFC version.

>>
>> Motivation
>> -----------
>>
>> Since TLB is a bottleneck for many systems, 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.
>>
>>
>> Solution
>> -----------
>>
>> A new Linux kernel module that uses DAMON to detect hot regions and collapse
>> those regions into huge pages. The user supplies a set of PIDs using a module
>> parameter,
>
> This sounds reasonable to me.
>
>> and then, the module launches a new kdamond thread to monitor each
>> of the tasks.
>>
>> In each kdamond, we start with a high min_access value. Our goal is to find the
>> "maximum" min_access value at which point the DAMON action is applied. In each
>> cycle, if no action is applied, we lower the min_access.
>
> So, this patch series introduces a sort of auto-tuning of the hugepages
> collapse hotness threshold, that implemented in the new module.
>
> We already have a sort of DAMOS auto-tuning feature, namely goal-based DAMOS
> quota auto-tuning [1]. Have you considered using that? Of course, it might
> not be able to be used as is. Some extensions, e.g., introduction of new goal
> metric, may be needed.
>
> Yet another approach would be implementing the auto-tuning in the user-space.
> Because DAMON parameters can be updated online, updating the min_access from
> the user space should be doable? Given the fact the module anyway require
> user-space control for feeding the list of applications to apply access-aware
> huge pages collapsing, I find no problem at user space driven auto-tuning.
>
> If the goal-based DAMOS quota auto-tuning or the user-space based auto-tuning
> are feasible, all the controls can be done using DAMON sysfs interface.
> Introduction of the new kernel module might not really be needed in the case.
>
> We have DAMON modules in addition to DAMON sysfs interface for users who want
> to use DAMON for a given specific use case with only minimum or near-zero
> user-space control. In this case, because it is already aimed to ask the
> user-space to feed the list of applications to apply DAMOS-based hugepages
> collapsing, it seems a new module is not really needed, to me.
>
> But I guess your use case might have some special restrictions that really
> require use of the module instead of offloading the auto-tuning to the
> user-space or DAMON core. Is that the case? If so, can you share more details
> about it?

I haven't figured out how I can use goal autotune to change the min_access.
Your suggestion about moving this to the user space sound good.

The idea was to stop lowering the min_access as soon as collapses occur,
since we don't want to lower so much that we start collapsing regions that
are not very hot.

Maybe you can suggest a better way to do it. Maybe with autotuning.

>
>>
>> Regarding the action, we introduce a new action: DAMOS_COLLAPSE. This allows us
>> collapse synchronously and avoid polluting khugepaged and other parts of the MM
>> subsystem with DAMON stuff. DAMOS_HUGEPAGE eventually calls hugepage_madvise,
>> which needs the correct vm_flags_t set.
>
> This makes sense to me. I expect DAMOS_COLLAPSE to have some advantages over
> DAMOS_HUGEPAGE for some use cases, similar to MADV_COLLAPSE vs MADV_HUGEPAGE.
>
> From my perspective, this patch series is introducing three things.
> 1) hugepage collapsing hotness threshold auto-tuning, 2) the module for running
> the auto-tuning, and 3) DAMOS_COLLAPSE. To me, it is unclear if the first two
> changes are really needed. I will wait your answer.
>
> Meanwhile, the third change seems reasonable and not necessarily need to be
> blocked for the other two changes. I think separating the third change from
> this patch series and upstreaming it first could also be a path forward.
> Because the change is simple and sound, convincing me would be easy. I'd be
> convinced if at least some reasonable test results can be shown. I'm not
> saying we should drop the other two changes. We can keep discussing those in
> parallel. Rather, upstreaming the third change first could help finding real
> benefits of the other two changes, since the testing will be easier. The
> decision is up to Asier, of course. I'm just sharing my two cents.
>
>>
>>
>> -----------
>> Changes in v2:
>
> Let's keep calling this "RFC" here. When you drop the "RFC" tag, this might
> confuse some people.
>
> Also, when you add a changelog of a patch, adding a link to the previous
> version [2] can help reviewing.

Will do it.

>
>> - Previously there was a mechanism to automatically detect hot applications.
>> Based on SeongJae Park's feedback [1], this was removed from the module, leaving
>> it entirely to the user space.
>> - All allocations now use kzalloc_obj.
>> - Since the user space provides now the list of pids to monitor, a commit_input
>> parameter is added to allow changing the pids while the module runs.
>> - Renamed the module from dynamic_hugepages to hugepages
>
> Thank you for doing this, Asier.
>
>>
>> [1]: https://lore.kernel.org/all/20260211150902.70066-1-sj@kernel.org/
>>
>> Asier Gutierrez (4):
>> Damon_modules_new_paddr_ctx_target. This works only for physical
>> contexts. In case of virtual addresses, we should duplicate the
>> code.
>> Support for huge pages collapse, which will be used by
>> dynamic_hugepages module.
>> This new module launches a new kdamond thread for each of them. The
>> purpose is to detect hot regions in a given list of tasks and
>> collapse them into huge pages.
>> DAMON_HOT_HUGEPAGE documentation
>>
>> .../admin-guide/mm/damon/hugepage.rst (new) | 186 ++++++++
>> include/linux/damon.h | 1 +
>> mm/damon/Kconfig | 7 +
>> mm/damon/Makefile | 1 +
>> mm/damon/hugepage.c (new) | 441 ++++++++++++++++++
>> mm/damon/lru_sort.c | 5 +-
>> mm/damon/modules-common.c | 6 +-
>> mm/damon/modules-common.h | 4 +-
>> mm/damon/reclaim.c | 5 +-
>> mm/damon/vaddr.c | 3 +
>> 10 files changed, 650 insertions(+), 9 deletions(-)
>> create mode 100644 Documentation/admin-guide/mm/damon/hugepage.rst
>> create mode 100644 mm/damon/hugepage.c
>>
>> --
>> 2.43.0
>
> [1] https://origin.kernel.org/doc/html/latest/mm/damon/design.html#aim-oriented-feedback-driven-auto-tuning
> [2] https://docs.kernel.org/process/submitting-patches.html#commentary
>
>
> Thanks,
> SJ
>

--
Asier Gutierrez
Huawei