Lines Matching +full:high +full:- +full:dynamic +full:- +full:range
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
19 To know how user-space can do the configurations and start/stop DAMON, refer to
28 - :ref:`Operations Set <damon_operations_set>`: Implements fundamental
30 address-space and available set of software/hardware primitives,
31 - :ref:`Core <damon_core_logic>`: Implements core logics including monitoring
32 overhead/accuracy control and access-aware system operations on top of the
34 - :ref:`Modules <damon_modules>`: Implements kernel modules for various
49 monitoring are address-space dependent.
51 1. Identification of the monitoring target address range for the address space.
52 2. Access check of specific address range in the target space.
73 - vaddr: Monitor virtual address spaces of specific processes
74 - fvaddr: Monitor fixed virtual address ranges
75 - paddr: Monitor the physical address space of the system
77 To know how user-space can do the configuration via :ref:`DAMON sysfs interface
84 VMA-based Target Address Range Construction
85 -------------------------------------------
95 Only small parts in the super-huge virtual address space of the processes are
99 mapping is not strictly required but could even incur a high overhead in some
107 heap and the uppermost mmap()-ed region, and the gap between the lowermost
108 mmap()-ed region and the stack in most of the cases. Because these gaps are
110 to make a reasonable trade-off. Below shows this in detail::
114 <uppermost mmap()-ed region>
115 (small mmap()-ed regions and munmap()-ed regions)
116 <lowermost mmap()-ed region>
121 PTE Accessed-bit Based Access Check
122 -----------------------------------
125 Accessed-bit for basic access checks. Only one difference is the way of
147 ----------
154 To know how user-space can set the attributes via :ref:`DAMON sysfs interface
169 clears the results. This can be described in below simple pseudo-code::
200 minimum and the maximum number of regions for the trade-off.
221 threshold until the upper-limit of the number of regions is met, or the
225 three regions if the total number of regions will not exceed the user-specified
228 In this way, DAMON provides its best-effort quality and minimal overhead while
229 keeping the bounds users set for their trade-off.
248 Dynamic Target Space Updates Handling
251 The monitoring target address range could dynamically changed. For example,
253 be hot-plugged.
256 monitoring operations to check dynamic changes including memory mapping changes
257 and applies it to monitoring operations-related data structures such as the
258 abstracted monitoring target memory area only for each of a user-specified time
261 User-space can get the monitoring results via DAMON sysfs interface and/or
270 -----------------
272 One common purpose of data access monitoring is access-aware system efficiency
279 using THP for memory regions that are larger than 2 MiB and showing a high
282 One straightforward approach for such schemes would be profile-guided
299 works, DAMON provides a feature called Data Access Monitoring-based Operation
300 Schemes (DAMOS). It lets users specify their desired schemes at a high
302 the access pattern of interest, and applies the user-desired operation actions
303 to the regions, for every user-specified time interval called
306 To know how user-space can set ``apply_interval`` via :ref:`DAMON sysfs
333 - ``willneed``: Call ``madvise()`` for the region with ``MADV_WILLNEED``.
335 - ``cold``: Call ``madvise()`` for the region with ``MADV_COLD``.
337 - ``pageout``: Reclaim the region.
339 - ``hugepage``: Call ``madvise()`` for the region with ``MADV_HUGEPAGE``.
341 - ``nohugepage``: Call ``madvise()`` for the region with ``MADV_NOHUGEPAGE``.
343 - ``lru_prio``: Prioritize the region on its LRU lists.
345 - ``lru_deprio``: Deprioritize the region on its LRU lists.
347 - ``migrate_hot``: Migrate the regions prioritizing warmer regions.
349 - ``migrate_cold``: Migrate the regions prioritizing colder regions.
351 - ``stat``: Do nothing but count the statistics.
358 To know how user-space can set the action via :ref:`DAMON sysfs interface
375 To know how user-space can set the access pattern via :ref:`DAMON sysfs
385 DAMOS upper-bound overhead control feature. DAMOS could incur high overhead if
391 dynamic.
393 To mitigate that situation, DAMOS provides an upper-bound overhead control
396 the action can be applied within a user-specified time duration.
398 To know how user-space can set the basic quotas via :ref:`DAMON sysfs interface
410 prioritizes regions and applies the action to only regions having high enough
414 rarely accessed (colder) memory regions would be prioritized for page-out
429 To know how user-space can set the prioritization weights via :ref:`DAMON sysfs
436 Aim-oriented Feedback-driven Auto-tuning
439 Automatic feedback-driven quota tuning. Instead of setting the absolute quota
447 ``target_value``, and ``current_value``. The auto-tuning mechanism tries to
451 - ``user_input``: User-provided value. Users could use any metric that they
457 - ``some_mem_psi_us``: System-wide ``some`` memory pressure stall information
460 set by users at the initial time. In other words, DAMOS does self-feedback.
462 To know how user-space can set the tuning goal metric, the target value, and/or
481 namely high, middle, and low. If the value of the metric becomes above the
482 high watermark or below the low watermark, the scheme is deactivated. If the
488 To know how user-space can set the watermarks via :ref:`DAMON sysfs interface
498 Non-access pattern-based target memory regions filtering. If users run
499 self-written programs or have good profiling tools, they could know something
503 have a list of latency-critical processes.
508 memory, and whether it should exclude the memory of the type (filter-out), or
509 all except the memory of the type (filter-in).
514 case of the core layer-handled filters, the memory regions that excluded by the
516 a memory regions is filtered by an operations set layer-handled filter, it is
521 - anonymous page
522 - Applied to pages that containing data that not stored in files.
523 - Handled by operations set layer. Supported by only ``paddr`` set.
524 - memory cgroup
525 - Applied to pages that belonging to a given cgroup.
526 - Handled by operations set layer. Supported by only ``paddr`` set.
527 - young page
528 - Applied to pages that are accessed after the last access check from the
530 - Handled by operations set layer. Supported by only ``paddr`` set.
531 - address range
532 - Applied to pages that belonging to a given address range.
533 - Handled by the core logic.
534 - DAMON monitoring target
535 - Applied to pages that belonging to a given DAMON monitoring target.
536 - Handled by the core logic.
538 To know how user-space can set the watermarks via :ref:`DAMON sysfs interface
544 ---------------------------------
546 The programming interface for kernel space data access-aware applications.
549 access-aware applications using DAMON's core features. For this, DAMON exposes
564 for general purpose DAMON control and special purpose data access-aware system
566 user space. The user space can build their efficient data access-aware
571 --------------------------------------
578 user-space. Please note that DAMON debugfs interface is currently deprecated.
584 API, and return the results to the user-space.
588 user space tools. One such Python-written user space tool is available at
591 (https://packages.fedoraproject.org/pkgs/python-damo/damo/).
593 Please refer to the ABI :doc:`document </admin-guide/mm/damon/usage>` for
597 Special-Purpose Access-aware Kernel Modules
598 -------------------------------------------
603 in runtime. For each special-purpose system-wide data access-aware system
606 extended for boot-time and even compile time control. Default values of DAMON
614 (:doc:`/admin-guide/mm/damon/reclaim` and
615 :doc:`/admin-guide/mm/damon/lru_sort`).