Lines Matching +full:two +full:- +full:user
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
19 interfaces for the user space, on top of the core layer.
23 ---------------------------
29 space. DAMON separates the two parts in different layers, namely DAMON
45 --------------------
51 used by the user space end users.
57 The monitoring operations are defined in two parts:
63 and virtual address spaces. Below two subsections describe how those work.
66 VMA-based Target Address Range Construction
67 -------------------------------------------
73 Only small parts in the super-huge virtual address space of the processes are
82 distinct regions that cover every mapped area of the address space. The two
83 gaps between the three regions are the two biggest unmapped areas in the given
84 address space. The two biggest unmapped areas would be the gap between the
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
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.
186 splits each region into two or three regions if the total number of regions
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
229 paging out memory regions that are not accessed for more than two minutes
236 One straightforward approach for such schemes would be profile-guided
249 including monitoring results and operation advice between kernel and user
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
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
351 consume unnecessary system resources. To avoid such consumption, the user would
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
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).
390 non-anonymous pages, pages of specific cgroups, all pages excluding those of
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
419 provide any direct interface for the user space. Such interfaces should be
420 implemented by each DAMON API user kernel components, instead. DAMON subsystem
421 itself implements such DAMON API user modules, which are supposed to be used
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
428 General Purpose User Interface Modules
429 --------------------------------------
431 DAMON modules that provide user space ABIs for general purpose DAMON usage in
434 DAMON user interface modules, namely 'DAMON sysfs interface' and 'DAMON debugfs
435 interface' are DAMON API user kernel modules that provide ABIs to the
436 user-space. Please note that DAMON debugfs interface is currently deprecated.
440 and reading from the files. As a response to such I/O, DAMON user interface
441 modules control DAMON and retrieve the results as user requested via the DAMON
442 API, and return the results to the user-space.
444 The ABIs are designed to be used for user space applications development,
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.
460 DAMON sysfs/debugfs user interfaces are for full control of all DAMON features
461 in runtime. For each special-purpose system-wide data access-aware system
464 extended for boot-time and even compile time control. Default values of DAMON
468 To support such cases, yet more DAMON API user kernel modules that provide more
469 simple and optimized user space interfaces are available. Currently, two
472 (:doc:`/admin-guide/mm/damon/reclaim` and
473 :doc:`/admin-guide/mm/damon/lru_sort`).