23a425aab0
Patch series "Docs/damon: update GitHub repo URLs and maintainer-profile". Replace GitHub URLS on DAMON documents for none-kernel parts DAMON repos with new ones[1] via the first patch. With following two patches, wordsmith maitnainer-profile for better readability, and document the Google clendsar for bi-weekly meetups, respectively. [1] https://lore.kernel.org/20240813232158.83903-1-sj@kernel.org This patch (of 3): GitHub repos for non-kernel parts of DAMON project including 'damo', 'damon-tests' and 'damoos' will be moved[1] from 'awslabs' org to 'damonitor', by 2024-09-05. Update related URLs in kernel tree. [1] https://lore.kernel.org/20240813232158.83903-1-sj@kernel.org Link: https://lkml.kernel.org/r/20240826015741.80707-1-sj@kernel.org Link: https://lkml.kernel.org/r/20240826015741.80707-2-sj@kernel.org Signed-off-by: SeongJae Park <sj@kernel.org> Cc: Alex Shi <alexs@kernel.org> Cc: Hu Haowen <2023002089@link.tyut.edu.cn> Cc: Jonathan Corbet <corbet@lwn.net> Cc: Yanteng Si <siyanteng@loongson.cn> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
616 lines
28 KiB
ReStructuredText
616 lines
28 KiB
ReStructuredText
.. SPDX-License-Identifier: GPL-2.0
|
|
|
|
======
|
|
Design
|
|
======
|
|
|
|
|
|
.. _damon_design_execution_model_and_data_structures:
|
|
|
|
Execution Model and Data Structures
|
|
===================================
|
|
|
|
The monitoring-related information including the monitoring request
|
|
specification and DAMON-based operation schemes are stored in a data structure
|
|
called DAMON ``context``. DAMON executes each context with a kernel thread
|
|
called ``kdamond``. Multiple kdamonds could run in parallel, for different
|
|
types of monitoring.
|
|
|
|
To know how user-space can do the configurations and start/stop DAMON, refer to
|
|
:ref:`DAMON sysfs interface <sysfs_interface>` documentation.
|
|
|
|
|
|
Overall Architecture
|
|
====================
|
|
|
|
DAMON subsystem is configured with three layers including
|
|
|
|
- :ref:`Operations Set <damon_operations_set>`: Implements fundamental
|
|
operations for DAMON that depends on the given monitoring target
|
|
address-space and available set of software/hardware primitives,
|
|
- :ref:`Core <damon_core_logic>`: Implements core logics including monitoring
|
|
overhead/accuracy control and access-aware system operations on top of the
|
|
operations set layer, and
|
|
- :ref:`Modules <damon_modules>`: Implements kernel modules for various
|
|
purposes that provides interfaces for the user space, on top of the core
|
|
layer.
|
|
|
|
|
|
.. _damon_operations_set:
|
|
|
|
Operations Set Layer
|
|
====================
|
|
|
|
.. _damon_design_configurable_operations_set:
|
|
|
|
For data access monitoring and additional low level work, DAMON needs a set of
|
|
implementations for specific operations that are dependent on and optimized for
|
|
the given target address space. For example, below two operations for access
|
|
monitoring are address-space dependent.
|
|
|
|
1. Identification of the monitoring target address range for the address space.
|
|
2. Access check of specific address range in the target space.
|
|
|
|
DAMON consolidates these implementations in a layer called DAMON Operations
|
|
Set, and defines the interface between it and the upper layer. The upper layer
|
|
is dedicated for DAMON's core logics including the mechanism for control of the
|
|
monitoring accruracy and the overhead.
|
|
|
|
Hence, DAMON can easily be extended for any address space and/or available
|
|
hardware features by configuring the core logic to use the appropriate
|
|
operations set. If there is no available operations set for a given purpose, a
|
|
new operations set can be implemented following the interface between the
|
|
layers.
|
|
|
|
For example, physical memory, virtual memory, swap space, those for specific
|
|
processes, NUMA nodes, files, and backing memory devices would be supportable.
|
|
Also, if some architectures or devices support special optimized access check
|
|
features, those will be easily configurable.
|
|
|
|
DAMON currently provides below three operation sets. Below two subsections
|
|
describe how those work.
|
|
|
|
- vaddr: Monitor virtual address spaces of specific processes
|
|
- fvaddr: Monitor fixed virtual address ranges
|
|
- paddr: Monitor the physical address space of the system
|
|
|
|
To know how user-space can do the configuration via :ref:`DAMON sysfs interface
|
|
<sysfs_interface>`, refer to :ref:`operations <sysfs_context>` file part of the
|
|
documentation.
|
|
|
|
|
|
.. _damon_design_vaddr_target_regions_construction:
|
|
|
|
VMA-based Target Address Range Construction
|
|
-------------------------------------------
|
|
|
|
A mechanism of ``vaddr`` DAMON operations set that automatically initializes
|
|
and updates the monitoring target address regions so that entire memory
|
|
mappings of the target processes can be covered.
|
|
|
|
This mechanism is only for the ``vaddr`` operations set. In cases of
|
|
``fvaddr`` and ``paddr`` operation sets, users are asked to manually set the
|
|
monitoring target address ranges.
|
|
|
|
Only small parts in the super-huge virtual address space of the processes are
|
|
mapped to the physical memory and accessed. Thus, tracking the unmapped
|
|
address regions is just wasteful. However, because DAMON can deal with some
|
|
level of noise using the adaptive regions adjustment mechanism, tracking every
|
|
mapping is not strictly required but could even incur a high overhead in some
|
|
cases. That said, too huge unmapped areas inside the monitoring target should
|
|
be removed to not take the time for the adaptive mechanism.
|
|
|
|
For the reason, this implementation converts the complex mappings to three
|
|
distinct regions that cover every mapped area of the address space. The two
|
|
gaps between the three regions are the two biggest unmapped areas in the given
|
|
address space. The two biggest unmapped areas would be the gap between the
|
|
heap and the uppermost mmap()-ed region, and the gap between the lowermost
|
|
mmap()-ed region and the stack in most of the cases. Because these gaps are
|
|
exceptionally huge in usual address spaces, excluding these will be sufficient
|
|
to make a reasonable trade-off. Below shows this in detail::
|
|
|
|
<heap>
|
|
<BIG UNMAPPED REGION 1>
|
|
<uppermost mmap()-ed region>
|
|
(small mmap()-ed regions and munmap()-ed regions)
|
|
<lowermost mmap()-ed region>
|
|
<BIG UNMAPPED REGION 2>
|
|
<stack>
|
|
|
|
|
|
PTE Accessed-bit Based Access Check
|
|
-----------------------------------
|
|
|
|
Both of the implementations for physical and virtual address spaces use PTE
|
|
Accessed-bit for basic access checks. Only one difference is the way of
|
|
finding the relevant PTE Accessed bit(s) from the address. While the
|
|
implementation for the virtual address walks the page table for the target task
|
|
of the address, the implementation for the physical address walks every page
|
|
table having a mapping to the address. In this way, the implementations find
|
|
and clear the bit(s) for next sampling target address and checks whether the
|
|
bit(s) set again after one sampling period. This could disturb other kernel
|
|
subsystems using the Accessed bits, namely Idle page tracking and the reclaim
|
|
logic. DAMON does nothing to avoid disturbing Idle page tracking, so handling
|
|
the interference is the responsibility of sysadmins. However, it solves the
|
|
conflict with the reclaim logic using ``PG_idle`` and ``PG_young`` page flags,
|
|
as Idle page tracking does.
|
|
|
|
|
|
.. _damon_core_logic:
|
|
|
|
Core Logics
|
|
===========
|
|
|
|
.. _damon_design_monitoring:
|
|
|
|
Monitoring
|
|
----------
|
|
|
|
Below four sections describe each of the DAMON core mechanisms and the five
|
|
monitoring attributes, ``sampling interval``, ``aggregation interval``,
|
|
``update interval``, ``minimum number of regions``, and ``maximum number of
|
|
regions``.
|
|
|
|
To know how user-space can set the attributes via :ref:`DAMON sysfs interface
|
|
<sysfs_interface>`, refer to :ref:`monitoring_attrs <sysfs_monitoring_attrs>`
|
|
part of the documentation.
|
|
|
|
|
|
Access Frequency Monitoring
|
|
~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
|
|
|
The output of DAMON says what pages are how frequently accessed for a given
|
|
duration. The resolution of the access frequency is controlled by setting
|
|
``sampling interval`` and ``aggregation interval``. In detail, DAMON checks
|
|
access to each page per ``sampling interval`` and aggregates the results. In
|
|
other words, counts the number of the accesses to each page. After each
|
|
``aggregation interval`` passes, DAMON calls callback functions that previously
|
|
registered by users so that users can read the aggregated results and then
|
|
clears the results. This can be described in below simple pseudo-code::
|
|
|
|
while monitoring_on:
|
|
for page in monitoring_target:
|
|
if accessed(page):
|
|
nr_accesses[page] += 1
|
|
if time() % aggregation_interval == 0:
|
|
for callback in user_registered_callbacks:
|
|
callback(monitoring_target, nr_accesses)
|
|
for page in monitoring_target:
|
|
nr_accesses[page] = 0
|
|
sleep(sampling interval)
|
|
|
|
The monitoring overhead of this mechanism will arbitrarily increase as the
|
|
size of the target workload grows.
|
|
|
|
|
|
.. _damon_design_region_based_sampling:
|
|
|
|
Region Based Sampling
|
|
~~~~~~~~~~~~~~~~~~~~~
|
|
|
|
To avoid the unbounded increase of the overhead, DAMON groups adjacent pages
|
|
that assumed to have the same access frequencies into a region. As long as the
|
|
assumption (pages in a region have the same access frequencies) is kept, only
|
|
one page in the region is required to be checked. Thus, for each ``sampling
|
|
interval``, DAMON randomly picks one page in each region, waits for one
|
|
``sampling interval``, checks whether the page is accessed meanwhile, and
|
|
increases the access frequency counter of the region if so. The counter is
|
|
called ``nr_accesses`` of the region. Therefore, the monitoring overhead is
|
|
controllable by setting the number of regions. DAMON allows users to set the
|
|
minimum and the maximum number of regions for the trade-off.
|
|
|
|
This scheme, however, cannot preserve the quality of the output if the
|
|
assumption is not guaranteed.
|
|
|
|
|
|
Adaptive Regions Adjustment
|
|
~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
|
|
|
Even somehow the initial monitoring target regions are well constructed to
|
|
fulfill the assumption (pages in same region have similar access frequencies),
|
|
the data access pattern can be dynamically changed. This will result in low
|
|
monitoring quality. To keep the assumption as much as possible, DAMON
|
|
adaptively merges and splits each region based on their access frequency.
|
|
|
|
For each ``aggregation interval``, it compares the access frequencies
|
|
(``nr_accesses``) of adjacent regions. If the difference is small, and if the
|
|
sum of the two regions' sizes is smaller than the size of total regions divided
|
|
by the ``minimum number of regions``, DAMON merges the two regions. If the
|
|
resulting number of total regions is still higher than ``maximum number of
|
|
regions``, it repeats the merging with increasing access frequenceis difference
|
|
threshold until the upper-limit of the number of regions is met, or the
|
|
threshold becomes higher than possible maximum value (``aggregation interval``
|
|
divided by ``sampling interval``). Then, after it reports and clears the
|
|
aggregated access frequency of each region, it splits each region into two or
|
|
three regions if the total number of regions will not exceed the user-specified
|
|
maximum number of regions after the split.
|
|
|
|
In this way, DAMON provides its best-effort quality and minimal overhead while
|
|
keeping the bounds users set for their trade-off.
|
|
|
|
|
|
.. _damon_design_age_tracking:
|
|
|
|
Age Tracking
|
|
~~~~~~~~~~~~
|
|
|
|
By analyzing the monitoring results, users can also find how long the current
|
|
access pattern of a region has maintained. That could be used for good
|
|
understanding of the access pattern. For example, page placement algorithm
|
|
utilizing both the frequency and the recency could be implemented using that.
|
|
To make such access pattern maintained period analysis easier, DAMON maintains
|
|
yet another counter called ``age`` in each region. For each ``aggregation
|
|
interval``, DAMON checks if the region's size and access frequency
|
|
(``nr_accesses``) has significantly changed. If so, the counter is reset to
|
|
zero. Otherwise, the counter is increased.
|
|
|
|
|
|
Dynamic Target Space Updates Handling
|
|
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
|
|
|
The monitoring target address range could dynamically changed. For example,
|
|
virtual memory could be dynamically mapped and unmapped. Physical memory could
|
|
be hot-plugged.
|
|
|
|
As the changes could be quite frequent in some cases, DAMON allows the
|
|
monitoring operations to check dynamic changes including memory mapping changes
|
|
and applies it to monitoring operations-related data structures such as the
|
|
abstracted monitoring target memory area only for each of a user-specified time
|
|
interval (``update interval``).
|
|
|
|
User-space can get the monitoring results via DAMON sysfs interface and/or
|
|
tracepoints. For more details, please refer to the documentations for
|
|
:ref:`DAMOS tried regions <sysfs_schemes_tried_regions>` and :ref:`tracepoint`,
|
|
respectively.
|
|
|
|
|
|
.. _damon_design_damos:
|
|
|
|
Operation Schemes
|
|
-----------------
|
|
|
|
One common purpose of data access monitoring is access-aware system efficiency
|
|
optimizations. For example,
|
|
|
|
paging out memory regions that are not accessed for more than two minutes
|
|
|
|
or
|
|
|
|
using THP for memory regions that are larger than 2 MiB and showing a high
|
|
access frequency for more than one minute.
|
|
|
|
One straightforward approach for such schemes would be profile-guided
|
|
optimizations. That is, getting data access monitoring results of the
|
|
workloads or the system using DAMON, finding memory regions of special
|
|
characteristics by profiling the monitoring results, and making system
|
|
operation changes for the regions. The changes could be made by modifying or
|
|
providing advice to the software (the application and/or the kernel), or
|
|
reconfiguring the hardware. Both offline and online approaches could be
|
|
available.
|
|
|
|
Among those, providing advice to the kernel at runtime would be flexible and
|
|
effective, and therefore widely be used. However, implementing such schemes
|
|
could impose unnecessary redundancy and inefficiency. The profiling could be
|
|
redundant if the type of interest is common. Exchanging the information
|
|
including monitoring results and operation advice between kernel and user
|
|
spaces could be inefficient.
|
|
|
|
To allow users to reduce such redundancy and inefficiencies by offloading the
|
|
works, DAMON provides a feature called Data Access Monitoring-based Operation
|
|
Schemes (DAMOS). It lets users specify their desired schemes at a high
|
|
level. For such specifications, DAMON starts monitoring, finds regions having
|
|
the access pattern of interest, and applies the user-desired operation actions
|
|
to the regions, for every user-specified time interval called
|
|
``apply_interval``.
|
|
|
|
To know how user-space can set ``apply_interval`` via :ref:`DAMON sysfs
|
|
interface <sysfs_interface>`, refer to :ref:`apply_interval_us <sysfs_scheme>`
|
|
part of the documentation.
|
|
|
|
|
|
.. _damon_design_damos_action:
|
|
|
|
Operation Action
|
|
~~~~~~~~~~~~~~~~
|
|
|
|
The management action that the users desire to apply to the regions of their
|
|
interest. For example, paging out, prioritizing for next reclamation victim
|
|
selection, advising ``khugepaged`` to collapse or split, or doing nothing but
|
|
collecting statistics of the regions.
|
|
|
|
The list of supported actions is defined in DAMOS, but the implementation of
|
|
each action is in the DAMON operations set layer because the implementation
|
|
normally depends on the monitoring target address space. For example, the code
|
|
for paging specific virtual address ranges out would be different from that for
|
|
physical address ranges. And the monitoring operations implementation sets are
|
|
not mandated to support all actions of the list. Hence, the availability of
|
|
specific DAMOS action depends on what operations set is selected to be used
|
|
together.
|
|
|
|
The list of the supported actions, their meaning, and DAMON operations sets
|
|
that supports each action are as below.
|
|
|
|
- ``willneed``: Call ``madvise()`` for the region with ``MADV_WILLNEED``.
|
|
Supported by ``vaddr`` and ``fvaddr`` operations set.
|
|
- ``cold``: Call ``madvise()`` for the region with ``MADV_COLD``.
|
|
Supported by ``vaddr`` and ``fvaddr`` operations set.
|
|
- ``pageout``: Reclaim the region.
|
|
Supported by ``vaddr``, ``fvaddr`` and ``paddr`` operations set.
|
|
- ``hugepage``: Call ``madvise()`` for the region with ``MADV_HUGEPAGE``.
|
|
Supported by ``vaddr`` and ``fvaddr`` operations set.
|
|
- ``nohugepage``: Call ``madvise()`` for the region with ``MADV_NOHUGEPAGE``.
|
|
Supported by ``vaddr`` and ``fvaddr`` operations set.
|
|
- ``lru_prio``: Prioritize the region on its LRU lists.
|
|
Supported by ``paddr`` operations set.
|
|
- ``lru_deprio``: Deprioritize the region on its LRU lists.
|
|
Supported by ``paddr`` operations set.
|
|
- ``migrate_hot``: Migrate the regions prioritizing warmer regions.
|
|
Supported by ``paddr`` operations set.
|
|
- ``migrate_cold``: Migrate the regions prioritizing colder regions.
|
|
Supported by ``paddr`` operations set.
|
|
- ``stat``: Do nothing but count the statistics.
|
|
Supported by all operations sets.
|
|
|
|
Applying the actions except ``stat`` to a region is considered as changing the
|
|
region's characteristics. Hence, DAMOS resets the age of regions when any such
|
|
actions are applied to those.
|
|
|
|
To know how user-space can set the action via :ref:`DAMON sysfs interface
|
|
<sysfs_interface>`, refer to :ref:`action <sysfs_scheme>` part of the
|
|
documentation.
|
|
|
|
|
|
.. _damon_design_damos_access_pattern:
|
|
|
|
Target Access Pattern
|
|
~~~~~~~~~~~~~~~~~~~~~
|
|
|
|
The access pattern of the schemes' interest. The patterns are constructed with
|
|
the properties that DAMON's monitoring results provide, specifically the size,
|
|
the access frequency, and the age. Users can describe their access pattern of
|
|
interest by setting minimum and maximum values of the three properties. If a
|
|
region's three properties are in the ranges, DAMOS classifies it as one of the
|
|
regions that the scheme is having an interest in.
|
|
|
|
To know how user-space can set the access pattern via :ref:`DAMON sysfs
|
|
interface <sysfs_interface>`, refer to :ref:`access_pattern
|
|
<sysfs_access_pattern>` part of the documentation.
|
|
|
|
|
|
.. _damon_design_damos_quotas:
|
|
|
|
Quotas
|
|
~~~~~~
|
|
|
|
DAMOS upper-bound overhead control feature. DAMOS could incur high overhead if
|
|
the target access pattern is not properly tuned. For example, if a huge memory
|
|
region having the access pattern of interest is found, applying the scheme's
|
|
action to all pages of the huge region could consume unacceptably large system
|
|
resources. Preventing such issues by tuning the access pattern could be
|
|
challenging, especially if the access patterns of the workloads are highly
|
|
dynamic.
|
|
|
|
To mitigate that situation, DAMOS provides an upper-bound overhead control
|
|
feature called quotas. It lets users specify an upper limit of time that DAMOS
|
|
can use for applying the action, and/or a maximum bytes of memory regions that
|
|
the action can be applied within a user-specified time duration.
|
|
|
|
To know how user-space can set the basic quotas via :ref:`DAMON sysfs interface
|
|
<sysfs_interface>`, refer to :ref:`quotas <sysfs_quotas>` part of the
|
|
documentation.
|
|
|
|
|
|
.. _damon_design_damos_quotas_prioritization:
|
|
|
|
Prioritization
|
|
^^^^^^^^^^^^^^
|
|
|
|
A mechanism for making a good decision under the quotas. When the action
|
|
cannot be applied to all regions of interest due to the quotas, DAMOS
|
|
prioritizes regions and applies the action to only regions having high enough
|
|
priorities so that it will not exceed the quotas.
|
|
|
|
The prioritization mechanism should be different for each action. For example,
|
|
rarely accessed (colder) memory regions would be prioritized for page-out
|
|
scheme action. In contrast, the colder regions would be deprioritized for huge
|
|
page collapse scheme action. Hence, the prioritization mechanisms for each
|
|
action are implemented in each DAMON operations set, together with the actions.
|
|
|
|
Though the implementation is up to the DAMON operations set, it would be common
|
|
to calculate the priority using the access pattern properties of the regions.
|
|
Some users would want the mechanisms to be personalized for their specific
|
|
case. For example, some users would want the mechanism to weigh the recency
|
|
(``age``) more than the access frequency (``nr_accesses``). DAMOS allows users
|
|
to specify the weight of each access pattern property and passes the
|
|
information to the underlying mechanism. Nevertheless, how and even whether
|
|
the weight will be respected are up to the underlying prioritization mechanism
|
|
implementation.
|
|
|
|
To know how user-space can set the prioritization weights via :ref:`DAMON sysfs
|
|
interface <sysfs_interface>`, refer to :ref:`weights <sysfs_quotas>` part of
|
|
the documentation.
|
|
|
|
|
|
.. _damon_design_damos_quotas_auto_tuning:
|
|
|
|
Aim-oriented Feedback-driven Auto-tuning
|
|
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
|
|
|
Automatic feedback-driven quota tuning. Instead of setting the absolute quota
|
|
value, users can specify the metric of their interest, and what target value
|
|
they want the metric value to be. DAMOS then automatically tunes the
|
|
aggressiveness (the quota) of the corresponding scheme. For example, if DAMOS
|
|
is under achieving the goal, DAMOS automatically increases the quota. If DAMOS
|
|
is over achieving the goal, it decreases the quota.
|
|
|
|
The goal can be specified with three parameters, namely ``target_metric``,
|
|
``target_value``, and ``current_value``. The auto-tuning mechanism tries to
|
|
make ``current_value`` of ``target_metric`` be same to ``target_value``.
|
|
Currently, two ``target_metric`` are provided.
|
|
|
|
- ``user_input``: User-provided value. Users could use any metric that they
|
|
has interest in for the value. Use space main workload's latency or
|
|
throughput, system metrics like free memory ratio or memory pressure stall
|
|
time (PSI) could be examples. Note that users should explicitly set
|
|
``current_value`` on their own in this case. In other words, users should
|
|
repeatedly provide the feedback.
|
|
- ``some_mem_psi_us``: System-wide ``some`` memory pressure stall information
|
|
in microseconds that measured from last quota reset to next quota reset.
|
|
DAMOS does the measurement on its own, so only ``target_value`` need to be
|
|
set by users at the initial time. In other words, DAMOS does self-feedback.
|
|
|
|
To know how user-space can set the tuning goal metric, the target value, and/or
|
|
the current value via :ref:`DAMON sysfs interface <sysfs_interface>`, refer to
|
|
:ref:`quota goals <sysfs_schemes_quota_goals>` part of the documentation.
|
|
|
|
|
|
.. _damon_design_damos_watermarks:
|
|
|
|
Watermarks
|
|
~~~~~~~~~~
|
|
|
|
Conditional DAMOS (de)activation automation. Users might want DAMOS to run
|
|
only under certain situations. For example, when a sufficient amount of free
|
|
memory is guaranteed, running a scheme for proactive reclamation would only
|
|
consume unnecessary system resources. To avoid such consumption, the user would
|
|
need to manually monitor some metrics such as free memory ratio, and turn
|
|
DAMON/DAMOS on or off.
|
|
|
|
DAMOS allows users to offload such works using three watermarks. It allows the
|
|
users to configure the metric of their interest, and three watermark values,
|
|
namely high, middle, and low. If the value of the metric becomes above the
|
|
high watermark or below the low watermark, the scheme is deactivated. If the
|
|
metric becomes below the mid watermark but above the low watermark, the scheme
|
|
is activated. If all schemes are deactivated by the watermarks, the monitoring
|
|
is also deactivated. In this case, the DAMON worker thread only periodically
|
|
checks the watermarks and therefore incurs nearly zero overhead.
|
|
|
|
To know how user-space can set the watermarks via :ref:`DAMON sysfs interface
|
|
<sysfs_interface>`, refer to :ref:`watermarks <sysfs_watermarks>` part of the
|
|
documentation.
|
|
|
|
|
|
.. _damon_design_damos_filters:
|
|
|
|
Filters
|
|
~~~~~~~
|
|
|
|
Non-access pattern-based target memory regions filtering. If users run
|
|
self-written programs or have good profiling tools, they could know something
|
|
more than the kernel, such as future access patterns or some special
|
|
requirements for specific types of memory. For example, some users may know
|
|
only anonymous pages can impact their program's performance. They can also
|
|
have a list of latency-critical processes.
|
|
|
|
To let users optimize DAMOS schemes with such special knowledge, DAMOS provides
|
|
a feature called DAMOS filters. The feature allows users to set an arbitrary
|
|
number of filters for each scheme. Each filter specifies the type of target
|
|
memory, and whether it should exclude the memory of the type (filter-out), or
|
|
all except the memory of the type (filter-in).
|
|
|
|
For efficient handling of filters, some types of filters are handled by the
|
|
core layer, while others are handled by operations set. In the latter case,
|
|
hence, support of the filter types depends on the DAMON operations set. In
|
|
case of the core layer-handled filters, the memory regions that excluded by the
|
|
filter are not counted as the scheme has tried to the region. In contrast, if
|
|
a memory regions is filtered by an operations set layer-handled filter, it is
|
|
counted as the scheme has tried. This difference affects the statistics.
|
|
|
|
Below types of filters are currently supported.
|
|
|
|
- anonymous page
|
|
- Applied to pages that containing data that not stored in files.
|
|
- Handled by operations set layer. Supported by only ``paddr`` set.
|
|
- memory cgroup
|
|
- Applied to pages that belonging to a given cgroup.
|
|
- Handled by operations set layer. Supported by only ``paddr`` set.
|
|
- young page
|
|
- Applied to pages that are accessed after the last access check from the
|
|
scheme.
|
|
- Handled by operations set layer. Supported by only ``paddr`` set.
|
|
- address range
|
|
- Applied to pages that belonging to a given address range.
|
|
- Handled by the core logic.
|
|
- DAMON monitoring target
|
|
- Applied to pages that belonging to a given DAMON monitoring target.
|
|
- Handled by the core logic.
|
|
|
|
To know how user-space can set the watermarks via :ref:`DAMON sysfs interface
|
|
<sysfs_interface>`, refer to :ref:`filters <sysfs_filters>` part of the
|
|
documentation.
|
|
|
|
|
|
Application Programming Interface
|
|
---------------------------------
|
|
|
|
The programming interface for kernel space data access-aware applications.
|
|
DAMON is a framework, so it does nothing by itself. Instead, it only helps
|
|
other kernel components such as subsystems and modules building their data
|
|
access-aware applications using DAMON's core features. For this, DAMON exposes
|
|
its all features to other kernel components via its application programming
|
|
interface, namely ``include/linux/damon.h``. Please refer to the API
|
|
:doc:`document </mm/damon/api>` for details of the interface.
|
|
|
|
|
|
.. _damon_modules:
|
|
|
|
Modules
|
|
=======
|
|
|
|
Because the core of DAMON is a framework for kernel components, it doesn't
|
|
provide any direct interface for the user space. Such interfaces should be
|
|
implemented by each DAMON API user kernel components, instead. DAMON subsystem
|
|
itself implements such DAMON API user modules, which are supposed to be used
|
|
for general purpose DAMON control and special purpose data access-aware system
|
|
operations, and provides stable application binary interfaces (ABI) for the
|
|
user space. The user space can build their efficient data access-aware
|
|
applications using the interfaces.
|
|
|
|
|
|
General Purpose User Interface Modules
|
|
--------------------------------------
|
|
|
|
DAMON modules that provide user space ABIs for general purpose DAMON usage in
|
|
runtime.
|
|
|
|
DAMON user interface modules, namely 'DAMON sysfs interface' and 'DAMON debugfs
|
|
interface' are DAMON API user kernel modules that provide ABIs to the
|
|
user-space. Please note that DAMON debugfs interface is currently deprecated.
|
|
|
|
Like many other ABIs, the modules create files on sysfs and debugfs, allow
|
|
users to specify their requests to and get the answers from DAMON by writing to
|
|
and reading from the files. As a response to such I/O, DAMON user interface
|
|
modules control DAMON and retrieve the results as user requested via the DAMON
|
|
API, and return the results to the user-space.
|
|
|
|
The ABIs are designed to be used for user space applications development,
|
|
rather than human beings' fingers. Human users are recommended to use such
|
|
user space tools. One such Python-written user space tool is available at
|
|
Github (https://github.com/damonitor/damo), Pypi
|
|
(https://pypistats.org/packages/damo), and Fedora
|
|
(https://packages.fedoraproject.org/pkgs/python-damo/damo/).
|
|
|
|
Please refer to the ABI :doc:`document </admin-guide/mm/damon/usage>` for
|
|
details of the interfaces.
|
|
|
|
|
|
Special-Purpose Access-aware Kernel Modules
|
|
-------------------------------------------
|
|
|
|
DAMON modules that provide user space ABI for specific purpose DAMON usage.
|
|
|
|
DAMON sysfs/debugfs user interfaces are for full control of all DAMON features
|
|
in runtime. For each special-purpose system-wide data access-aware system
|
|
operations such as proactive reclamation or LRU lists balancing, the interfaces
|
|
could be simplified by removing unnecessary knobs for the specific purpose, and
|
|
extended for boot-time and even compile time control. Default values of DAMON
|
|
control parameters for the usage would also need to be optimized for the
|
|
purpose.
|
|
|
|
To support such cases, yet more DAMON API user kernel modules that provide more
|
|
simple and optimized user space interfaces are available. Currently, two
|
|
modules for proactive reclamation and LRU lists manipulation are provided. For
|
|
more detail, please read the usage documents for those
|
|
(:doc:`/admin-guide/mm/damon/reclaim` and
|
|
:doc:`/admin-guide/mm/damon/lru_sort`).
|