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

[SeongJae Park]

On Mon, 2 Feb 2026 14:56:45 +0000 <gutierrez.asier@xxxxxxxxxxxxxxxxxxx> wrote:

> From: Asier Gutierrez <gutierrez.asier@xxxxxxxxxxxxxxxxxxx>
> 
> Overview
> ----------
> 
> This patch set introduces a new dynamic mechanism for detecting hot applications
> and hot regions in those applications.
> 
> Motivation
> -----------
> 
> Currently DAMON requires the system administrator to provide information about
> which application needs to be monitored and all the parameters. Ideally this
> should be done automatically, with minimal intervention from the system
> administrator.
> 
> 
> 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.
> 
> We would like to detect: 1. which applications are hot in the system and 2.
> which memory regions are hot in order to collapse those regions.
> 
> 
> Solution
> -----------
> 
>      ┌────────────┐           ┌────────────┐
>      │Damon_module│           │Task_monitor│
>      └──────┬─────┘           └──────┬─────┘
>             │         start          │
>             │───────────────────────>│
>             │                        │
>             │                        │────┐
>             │                        │    │ calculate task load
>             │                        │<───┘
>             │                        │
>             │                        │────┐
>             │                        │    │ sort tasks
>             │                        │<───┘
>             │                        │
>             │                        │────┐
>             │                        │    │ start kdamond for top 3 tasks
>             │                        │<───┘
>      ┌──────┴─────┐           ┌──────┴─────┐
>      │Damon_module│           │Task_monitor│
>      └────────────┘           └────────────┘
> 
> 
> We calculate the task load base on the sum of all the utime for all the threads
> in a given task. Once we get total utime, we use the exponential load average
> provided by calc_load. The tasks that become cold, the kdamond will be stopped
> for them.
> 
> 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.
> 
> 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.
> 
> Benchmark
> -----------
> 
> Asier Gutierrez (4):
>    mm/damon: Generic context creation for modules
>    mm/damon: Support for synchrounous huge pages collapse
>    mm/damon: New module with hot application detection
>    documentation/mm/damon: Documentation for the dynamic_hugepages 
> module
> 
>  .../mm/damon/dynamic_hugepages.rst (new)      | 173 ++++++
>  include/linux/damon.h                         |   1 +
>  mm/damon/Kconfig                              |   7 +
>  mm/damon/Makefile                             |   1 +
>  mm/damon/dynamic_hugepages.c (new)            | 579 ++++++++++++++++++
>  mm/damon/lru_sort.c                           |   6 +-
>  mm/damon/modules-common.c                     |   7 +-
>  mm/damon/modules-common.h                     |   5 +-
>  mm/damon/reclaim.c                            |   5 +-
>  mm/damon/vaddr.c                              |   3 +
>  10 files changed, 778 insertions(+), 9 deletions(-)
>  create mode 100644 Documentation/admin-guide/mm/damon/dynamic_hugepages.rst
>  create mode 100644 mm/damon/dynamic_hugepages.c

By the way, I proposed [1] an LSF/MM/BPF session for access-aware THP today.  I
also mentioned this patch series on the proposal as one of potential discussion
topics, and Cc-ed Asier.

I just wanted to make sure that the proposal is never a sort of implicit
request to hold the progress of this patch series.  Please continue discussions
and revisioning of this patch series regardless of the proposed LSF/MM/BPF
session.

[1] https://lore.kernel.org/20260211050729.69719-1-sj@xxxxxxxxxx


Thanks,
SJ

[...]