mm/damon/design.rst

1 .. SPDX-License-Identifier: GPL-2.0
13 - Operations Set: Implements fundamental operations for DAMON that depends on
14   the given monitoring target address-space and available set of
16 - Core: Implements core logics including monitoring overhead/accurach control
17   and access-aware system operations on top of the operations set layer, and
18 - Modules: Implements kernel modules for various purposes that provides
23 ---------------------------
26 implementations for specific operations that are dependent on and optimized for
38 For example, physical memory, virtual memory, swap space, those for specific
45 --------------------
60 2. Access check of specific address range in the target space.
66 VMA-based Target Address Range Construction
67 -------------------------------------------
70 implementation.  That for the physical address space simply asks users to
73 Only small parts in the super-huge virtual address space of the processes are
81 For the reason, this implementation converts the complex mappings to three
85 heap and the uppermost mmap()-ed region, and the gap between the lowermost
86 mmap()-ed region and the stack in most of the cases.  Because these gaps are
88 to make a reasonable trade-off.  Below shows this in detail::
92     <uppermost mmap()-ed region>
93     (small mmap()-ed regions and munmap()-ed regions)
94     <lowermost mmap()-ed region>
99 PTE Accessed-bit Based Access Check
100 -----------------------------------
103 Accessed-bit for basic access checks.  Only one difference is the way of
105 implementation for the virtual address walks the page table for the target task
106 of the address, the implementation for the physical address walks every page
122 ----------
140 clears the results.  This can be described in below simple pseudo-code::
168 to set the minimum and the maximum number of regions for the trade-off.
187 will not exceed the user-specified maximum number of regions after the split.
189 In this way, DAMON provides its best-effort quality and minimal overhead while
190 keeping the bounds users set for their trade-off.
212 be hot-plugged.
216 and applies it to monitoring operations-related data structures such as the
217 abstracted monitoring target memory area only for each of a user-specified time
224 -----------------
226 One common purpose of data access monitoring is access-aware system efficiency
236 One straightforward approach for such schemes would be profile-guided
253 works, DAMON provides a feature called Data Access Monitoring-based Operation
256 the access pattern of interest, and applies the user-desired operation actions
270 The list of supported actions is defined in DAMOS, but the implementation of
271 each action is in the DAMON operations set layer because the implementation
273 for paging specific virtual address ranges out would be different from that for
274 physical address ranges.  And the monitoring operations implementation sets are
276 specific DAMOS action depends on what operations set is selected to be used
302 DAMOS upper-bound overhead control feature.  DAMOS could incur high overhead if
310 To mitigate that situation, DAMOS provides an upper-bound overhead control
313 the action can be applied within a user-specified time duration.
327 rarely accessed (colder) memory regions would be prioritized for page-out
332 Though the implementation is up to the DAMON operations set, it would be common
334 Some users would want the mechanisms to be personalized for their specific
340 implementation.
370 Non-access pattern-based target memory regions filtering.  If users run
371 self-written programs or have good profiling tools, they could know something
373 requirements for specific types of memory. For example, some users may know
375 have a list of latency-critical processes.
380 memory, and whether it should exclude the memory of the type (filter-out), or
381 all except the memory of the type (filter-in).
389 list.  Hence, users can apply specific schemes to only anonymous pages,
390 non-anonymous pages, pages of specific cgroups, all pages excluding those of
391 specific cgroups, pages in specific address range, pages in specific DAMON
396 operations set.  If a memory region is filtered by a core layer-handled filter,
398 memory regions is filtered by an operations set layer-handled filter, it is
404 ---------------------------------
406 The programming interface for kernel space data access-aware applications.
409 access-aware applications using DAMON's core features.  For this, DAMON exposes
422 for general purpose DAMON control and special purpose data access-aware system
424 user space.  The user space can build their efficient data access-aware
429 --------------------------------------
436 user-space.  Please note that DAMON debugfs interface is currently deprecated.
442 API, and return the results to the user-space.
446 user space tools.  One such Python-written user space tool is available at
449 (https://packages.fedoraproject.org/pkgs/python-damo/damo/).
451 Please refer to the ABI :doc:`document </admin-guide/mm/damon/usage>` for
455 Special-Purpose Access-aware Kernel Modules
456 -------------------------------------------
458 DAMON modules that provide user space ABI for specific purpose DAMON usage.
461 in runtime.  For each special-purpose system-wide data access-aware system
463 could be simplified by removing unnecessary knobs for the specific purpose, and
464 extended for boot-time and even compile time control.  Default values of DAMON
472 (:doc:`/admin-guide/mm/damon/reclaim` and
473 :doc:`/admin-guide/mm/damon/lru_sort`).