mm/damon: Support hot application detections

From: Asier Gutierrez <gutierrez.asier@huawei-partners.com>

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

-- 
2.43.0