mm/damon/design.rst

1 .. SPDX-License-Identifier: GPL-2.0
13 The monitoring-related information including the monitoring request
14 specification and DAMON-based operation schemes are stored in a data structure
25 - Operations Set: Implements fundamental operations for DAMON that depends on
26   the given monitoring target address-space and available set of
28 - Core: Implements core logics including monitoring overhead/accurach control
29   and access-aware system operations on top of the operations set layer, and
30 - Modules: Implements kernel modules for various purposes that provides
35 ---------------------------
50 For example, physical memory, virtual memory, swap space, those for specific
51 processes, NUMA nodes, files, and backing memory devices would be supportable.
57 --------------------
78 VMA-based Target Address Range Construction
79 -------------------------------------------
85 Only small parts in the super-huge virtual address space of the processes are
86 mapped to the physical memory and accessed.  Thus, tracking the unmapped
97 heap and the uppermost mmap()-ed region, and the gap between the lowermost
98 mmap()-ed region and the stack in most of the cases.  Because these gaps are
100 to make a reasonable trade-off.  Below shows this in detail::
103     <BIG UNMAPPED REGION 1>
104     <uppermost mmap()-ed region>
105     (small mmap()-ed regions and munmap()-ed regions)
106     <lowermost mmap()-ed region>
107     <BIG UNMAPPED REGION 2>
111 PTE Accessed-bit Based Access Check
112 -----------------------------------
115 Accessed-bit for basic access checks.  Only one difference is the way of
134 ----------
152 clears the results.  This can be described in below simple pseudo-code::
171 Region Based Sampling
175 that assumed to have the same access frequencies into a region.  As long as the
176 assumption (pages in a region have the same access frequencies) is kept, only
177 one page in the region is required to be checked.  Thus, for each ``sampling
178 interval``, DAMON randomly picks one page in each region, waits for one
180 increases the access frequency counter of the region if so.  The counter is
181 called ``nr_regions`` of the region.  Therefore, the monitoring overhead is
183 minimum and the maximum number of regions for the trade-off.
193 fulfill the assumption (pages in same region have similar access frequencies),
196 adaptively merges and splits each region based on their access frequency.
200 after it reports and clears the aggregated access frequency of each region, it
201 splits each region into two or three regions if the total number of regions
202 will not exceed the user-specified maximum number of regions after the split.
204 In this way, DAMON provides its best-effort quality and minimal overhead while
205 keeping the bounds users set for their trade-off.
214 access pattern of a region has maintained.  That could be used for good
218 yet another counter called ``age`` in each region.  For each ``aggregation
219 interval``, DAMON checks if the region's size and access frequency
228 virtual memory could be dynamically mapped and unmapped.  Physical memory could
229 be hot-plugged.
232 monitoring operations to check dynamic changes including memory mapping changes
233 and applies it to monitoring operations-related data structures such as the
234 abstracted monitoring target memory area only for each of a user-specified time
241 -----------------
243 One common purpose of data access monitoring is access-aware system efficiency
246     paging out memory regions that are not accessed for more than two minutes
250     using THP for memory regions that are larger than 2 MiB and showing a high
253 One straightforward approach for such schemes would be profile-guided
255 workloads or the system using DAMON, finding memory regions of special
270 works, DAMON provides a feature called Data Access Monitoring-based Operation
273 the access pattern of interest, and applies the user-desired operation actions
274 to the regions, for every user-specified time interval called
297 Applying an action to a region is considered as changing the region's
311 region's three properties are in the ranges, DAMOS classifies it as one of the
320 DAMOS upper-bound overhead control feature.  DAMOS could incur high overhead if
321 the target access pattern is not properly tuned.  For example, if a huge memory
322 region having the access pattern of interest is found, applying the scheme's
323 action to all pages of the huge region could consume unacceptably large system
328 To mitigate that situation, DAMOS provides an upper-bound overhead control
330 can use for applying the action, and/or a maximum bytes of memory regions that
331 the action can be applied within a user-specified time duration.
345 rarely accessed (colder) memory regions would be prioritized for page-out
363 Aim-oriented Feedback-driven Auto-tuning
366 Automatic feedback-driven quota tuning.  Instead of setting the absolute quota
381 memory is guaranteed, running a scheme for proactive reclamation would only
383 need to manually monitor some metrics such as free memory ratio, and turn
401 Non-access pattern-based target memory regions filtering.  If users run
402 self-written programs or have good profiling tools, they could know something
404 requirements for specific types of memory. For example, some users may know
406 have a list of latency-critical processes.
411 memory, and whether it should exclude the memory of the type (filter-out), or
412 all except the memory of the type (filter-in).
414 Currently, anonymous page, memory cgroup, address range, and DAMON monitoring
416 require additional arguments.  The memory cgroup filter type asks users to
417 specify the file path of the memory cgroup for the filter.  The address range
421 non-anonymous pages, pages of specific cgroups, all pages excluding those of
427 operations set.  If a memory region is filtered by a core layer-handled filter,
428 it is not counted as the scheme has tried to the region.  In contrast, if a
429 memory regions is filtered by an operations set layer-handled filter, it is
435 ---------------------------------
437 The programming interface for kernel space data access-aware applications.
440 access-aware applications using DAMON's core features.  For this, DAMON exposes
453 for general purpose DAMON control and special purpose data access-aware system
455 user space.  The user space can build their efficient data access-aware
460 --------------------------------------
467 user-space.  Please note that DAMON debugfs interface is currently deprecated.
473 API, and return the results to the user-space.
477 user space tools.  One such Python-written user space tool is available at
480 (https://packages.fedoraproject.org/pkgs/python-damo/damo/).
482 Please refer to the ABI :doc:`document </admin-guide/mm/damon/usage>` for
486 Special-Purpose Access-aware Kernel Modules
487 -------------------------------------------
492 in runtime.  For each special-purpose system-wide data access-aware system
495 extended for boot-time and even compile time control.  Default values of DAMON
503 (:doc:`/admin-guide/mm/damon/reclaim` and
504 :doc:`/admin-guide/mm/damon/lru_sort`).