1 .. SPDX-License-Identifier: GPL-2.0 2 3 ====== 4 Design 5 ====== 6 7 8 .. _damon_design_execution_model_and_data_structures: 9 10 Execution Model and Data Structures 11 =================================== 12 13 The monitoring-related information including the monitoring request 14 specification and DAMON-based operation schemes are stored in a data structure 15 called DAMON ``context``. DAMON executes each context with a kernel thread 16 called ``kdamond``. Multiple kdamonds could run in parallel, for different 17 types of monitoring. 18 19 To know how user-space can do the configurations and start/stop DAMON, refer to 20 :ref:`DAMON sysfs interface <sysfs_interface>` documentation. 21 22 23 Overall Architecture 24 ==================== 25 26 DAMON subsystem is configured with three layers including 27 28 - :ref:`Operations Set <damon_operations_set>`: Implements fundamental 29 operations for DAMON that depends on the given monitoring target 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 33 operations set layer, and 34 - :ref:`Modules <damon_modules>`: Implements kernel modules for various 35 purposes that provides interfaces for the user space, on top of the core 36 layer. 37 38 39 .. _damon_operations_set: 40 41 Operations Set Layer 42 ==================== 43 44 .. _damon_design_configurable_operations_set: 45 46 For data access monitoring and additional low level work, DAMON needs a set of 47 implementations for specific operations that are dependent on and optimized for 48 the given target address space. For example, below two operations for access 49 monitoring are address-space dependent. 50 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. 53 54 DAMON consolidates these implementations in a layer called DAMON Operations 55 Set, and defines the interface between it and the upper layer. The upper layer 56 is dedicated for DAMON's core logics including the mechanism for control of the 57 monitoring accruracy and the overhead. 58 59 Hence, DAMON can easily be extended for any address space and/or available 60 hardware features by configuring the core logic to use the appropriate 61 operations set. If there is no available operations set for a given purpose, a 62 new operations set can be implemented following the interface between the 63 layers. 64 65 For example, physical memory, virtual memory, swap space, those for specific 66 processes, NUMA nodes, files, and backing memory devices would be supportable. 67 Also, if some architectures or devices support special optimized access check 68 features, those will be easily configurable. 69 70 DAMON currently provides below three operation sets. Below two subsections 71 describe how those work. 72 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 76 77 To know how user-space can do the configuration via :ref:`DAMON sysfs interface 78 <sysfs_interface>`, refer to :ref:`operations <sysfs_context>` file part of the 79 documentation. 80 81 82 .. _damon_design_vaddr_target_regions_construction: 83 84 VMA-based Target Address Range Construction 85 ------------------------------------------- 86 87 A mechanism of ``vaddr`` DAMON operations set that automatically initializes 88 and updates the monitoring target address regions so that entire memory 89 mappings of the target processes can be covered. 90 91 This mechanism is only for the ``vaddr`` operations set. In cases of 92 ``fvaddr`` and ``paddr`` operation sets, users are asked to manually set the 93 monitoring target address ranges. 94 95 Only small parts in the super-huge virtual address space of the processes are 96 mapped to the physical memory and accessed. Thus, tracking the unmapped 97 address regions is just wasteful. However, because DAMON can deal with some 98 level of noise using the adaptive regions adjustment mechanism, tracking every 99 mapping is not strictly required but could even incur a high overhead in some 100 cases. That said, too huge unmapped areas inside the monitoring target should 101 be removed to not take the time for the adaptive mechanism. 102 103 For the reason, this implementation converts the complex mappings to three 104 distinct regions that cover every mapped area of the address space. The two 105 gaps between the three regions are the two biggest unmapped areas in the given 106 address space. The two biggest unmapped areas would be the gap between the 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 109 exceptionally huge in usual address spaces, excluding these will be sufficient 110 to make a reasonable trade-off. Below shows this in detail:: 111 112 <heap> 113 <BIG UNMAPPED REGION 1> 114 <uppermost mmap()-ed region> 115 (small mmap()-ed regions and munmap()-ed regions) 116 <lowermost mmap()-ed region> 117 <BIG UNMAPPED REGION 2> 118 <stack> 119 120 121 PTE Accessed-bit Based Access Check 122 ----------------------------------- 123 124 Both of the implementations for physical and virtual address spaces use PTE 125 Accessed-bit for basic access checks. Only one difference is the way of 126 finding the relevant PTE Accessed bit(s) from the address. While the 127 implementation for the virtual address walks the page table for the target task 128 of the address, the implementation for the physical address walks every page 129 table having a mapping to the address. In this way, the implementations find 130 and clear the bit(s) for next sampling target address and checks whether the 131 bit(s) set again after one sampling period. This could disturb other kernel 132 subsystems using the Accessed bits, namely Idle page tracking and the reclaim 133 logic. DAMON does nothing to avoid disturbing Idle page tracking, so handling 134 the interference is the responsibility of sysadmins. However, it solves the 135 conflict with the reclaim logic using ``PG_idle`` and ``PG_young`` page flags, 136 as Idle page tracking does. 137 138 139 .. _damon_core_logic: 140 141 Core Logics 142 =========== 143 144 .. _damon_design_monitoring: 145 146 Monitoring 147 ---------- 148 149 Below four sections describe each of the DAMON core mechanisms and the five 150 monitoring attributes, ``sampling interval``, ``aggregation interval``, 151 ``update interval``, ``minimum number of regions``, and ``maximum number of 152 regions``. 153 154 To know how user-space can set the attributes via :ref:`DAMON sysfs interface 155 <sysfs_interface>`, refer to :ref:`monitoring_attrs <sysfs_monitoring_attrs>` 156 part of the documentation. 157 158 159 Access Frequency Monitoring 160 ~~~~~~~~~~~~~~~~~~~~~~~~~~~ 161 162 The output of DAMON says what pages are how frequently accessed for a given 163 duration. The resolution of the access frequency is controlled by setting 164 ``sampling interval`` and ``aggregation interval``. In detail, DAMON checks 165 access to each page per ``sampling interval`` and aggregates the results. In 166 other words, counts the number of the accesses to each page. After each 167 ``aggregation interval`` passes, DAMON calls callback functions that previously 168 registered by users so that users can read the aggregated results and then 169 clears the results. This can be described in below simple pseudo-code:: 170 171 while monitoring_on: 172 for page in monitoring_target: 173 if accessed(page): 174 nr_accesses[page] += 1 175 if time() % aggregation_interval == 0: 176 for callback in user_registered_callbacks: 177 callback(monitoring_target, nr_accesses) 178 for page in monitoring_target: 179 nr_accesses[page] = 0 180 sleep(sampling interval) 181 182 The monitoring overhead of this mechanism will arbitrarily increase as the 183 size of the target workload grows. 184 185 186 .. _damon_design_region_based_sampling: 187 188 Region Based Sampling 189 ~~~~~~~~~~~~~~~~~~~~~ 190 191 To avoid the unbounded increase of the overhead, DAMON groups adjacent pages 192 that assumed to have the same access frequencies into a region. As long as the 193 assumption (pages in a region have the same access frequencies) is kept, only 194 one page in the region is required to be checked. Thus, for each ``sampling 195 interval``, DAMON randomly picks one page in each region, waits for one 196 ``sampling interval``, checks whether the page is accessed meanwhile, and 197 increases the access frequency counter of the region if so. The counter is 198 called ``nr_accesses`` of the region. Therefore, the monitoring overhead is 199 controllable by setting the number of regions. DAMON allows users to set the 200 minimum and the maximum number of regions for the trade-off. 201 202 This scheme, however, cannot preserve the quality of the output if the 203 assumption is not guaranteed. 204 205 206 Adaptive Regions Adjustment 207 ~~~~~~~~~~~~~~~~~~~~~~~~~~~ 208 209 Even somehow the initial monitoring target regions are well constructed to 210 fulfill the assumption (pages in same region have similar access frequencies), 211 the data access pattern can be dynamically changed. This will result in low 212 monitoring quality. To keep the assumption as much as possible, DAMON 213 adaptively merges and splits each region based on their access frequency. 214 215 For each ``aggregation interval``, it compares the access frequencies 216 (``nr_accesses``) of adjacent regions. If the difference is small, and if the 217 sum of the two regions' sizes is smaller than the size of total regions divided 218 by the ``minimum number of regions``, DAMON merges the two regions. If the 219 resulting number of total regions is still higher than ``maximum number of 220 regions``, it repeats the merging with increasing access frequenceis difference 221 threshold until the upper-limit of the number of regions is met, or the 222 threshold becomes higher than possible maximum value (``aggregation interval`` 223 divided by ``sampling interval``). Then, after it reports and clears the 224 aggregated access frequency of each region, it splits each region into two or 225 three regions if the total number of regions will not exceed the user-specified 226 maximum number of regions after the split. 227 228 In this way, DAMON provides its best-effort quality and minimal overhead while 229 keeping the bounds users set for their trade-off. 230 231 232 .. _damon_design_age_tracking: 233 234 Age Tracking 235 ~~~~~~~~~~~~ 236 237 By analyzing the monitoring results, users can also find how long the current 238 access pattern of a region has maintained. That could be used for good 239 understanding of the access pattern. For example, page placement algorithm 240 utilizing both the frequency and the recency could be implemented using that. 241 To make such access pattern maintained period analysis easier, DAMON maintains 242 yet another counter called ``age`` in each region. For each ``aggregation 243 interval``, DAMON checks if the region's size and access frequency 244 (``nr_accesses``) has significantly changed. If so, the counter is reset to 245 zero. Otherwise, the counter is increased. 246 247 248 Dynamic Target Space Updates Handling 249 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 250 251 The monitoring target address range could dynamically changed. For example, 252 virtual memory could be dynamically mapped and unmapped. Physical memory could 253 be hot-plugged. 254 255 As the changes could be quite frequent in some cases, DAMON allows the 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 259 interval (``update interval``). 260 261 User-space can get the monitoring results via DAMON sysfs interface and/or 262 tracepoints. For more details, please refer to the documentations for 263 :ref:`DAMOS tried regions <sysfs_schemes_tried_regions>` and :ref:`tracepoint`, 264 respectively. 265 266 267 .. _damon_design_damos: 268 269 Operation Schemes 270 ----------------- 271 272 One common purpose of data access monitoring is access-aware system efficiency 273 optimizations. For example, 274 275 paging out memory regions that are not accessed for more than two minutes 276 277 or 278 279 using THP for memory regions that are larger than 2 MiB and showing a high 280 access frequency for more than one minute. 281 282 One straightforward approach for such schemes would be profile-guided 283 optimizations. That is, getting data access monitoring results of the 284 workloads or the system using DAMON, finding memory regions of special 285 characteristics by profiling the monitoring results, and making system 286 operation changes for the regions. The changes could be made by modifying or 287 providing advice to the software (the application and/or the kernel), or 288 reconfiguring the hardware. Both offline and online approaches could be 289 available. 290 291 Among those, providing advice to the kernel at runtime would be flexible and 292 effective, and therefore widely be used. However, implementing such schemes 293 could impose unnecessary redundancy and inefficiency. The profiling could be 294 redundant if the type of interest is common. Exchanging the information 295 including monitoring results and operation advice between kernel and user 296 spaces could be inefficient. 297 298 To allow users to reduce such redundancy and inefficiencies by offloading the 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 301 level. For such specifications, DAMON starts monitoring, finds regions having 302 the access pattern of interest, and applies the user-desired operation actions 303 to the regions, for every user-specified time interval called 304 ``apply_interval``. 305 306 To know how user-space can set ``apply_interval`` via :ref:`DAMON sysfs 307 interface <sysfs_interface>`, refer to :ref:`apply_interval_us <sysfs_scheme>` 308 part of the documentation. 309 310 311 .. _damon_design_damos_action: 312 313 Operation Action 314 ~~~~~~~~~~~~~~~~ 315 316 The management action that the users desire to apply to the regions of their 317 interest. For example, paging out, prioritizing for next reclamation victim 318 selection, advising ``khugepaged`` to collapse or split, or doing nothing but 319 collecting statistics of the regions. 320 321 The list of supported actions is defined in DAMOS, but the implementation of 322 each action is in the DAMON operations set layer because the implementation 323 normally depends on the monitoring target address space. For example, the code 324 for paging specific virtual address ranges out would be different from that for 325 physical address ranges. And the monitoring operations implementation sets are 326 not mandated to support all actions of the list. Hence, the availability of 327 specific DAMOS action depends on what operations set is selected to be used 328 together. 329 330 The list of the supported actions, their meaning, and DAMON operations sets 331 that supports each action are as below. 332 333 - ``willneed``: Call ``madvise()`` for the region with ``MADV_WILLNEED``. 334 Supported by ``vaddr`` and ``fvaddr`` operations set. 335 - ``cold``: Call ``madvise()`` for the region with ``MADV_COLD``. 336 Supported by ``vaddr`` and ``fvaddr`` operations set. 337 - ``pageout``: Reclaim the region. 338 Supported by ``vaddr``, ``fvaddr`` and ``paddr`` operations set. 339 - ``hugepage``: Call ``madvise()`` for the region with ``MADV_HUGEPAGE``. 340 Supported by ``vaddr`` and ``fvaddr`` operations set. 341 - ``nohugepage``: Call ``madvise()`` for the region with ``MADV_NOHUGEPAGE``. 342 Supported by ``vaddr`` and ``fvaddr`` operations set. 343 - ``lru_prio``: Prioritize the region on its LRU lists. 344 Supported by ``paddr`` operations set. 345 - ``lru_deprio``: Deprioritize the region on its LRU lists. 346 Supported by ``paddr`` operations set. 347 - ``migrate_hot``: Migrate the regions prioritizing warmer regions. 348 Supported by ``paddr`` operations set. 349 - ``migrate_cold``: Migrate the regions prioritizing colder regions. 350 Supported by ``paddr`` operations set. 351 - ``stat``: Do nothing but count the statistics. 352 Supported by all operations sets. 353 354 Applying the actions except ``stat`` to a region is considered as changing the 355 region's characteristics. Hence, DAMOS resets the age of regions when any such 356 actions are applied to those. 357 358 To know how user-space can set the action via :ref:`DAMON sysfs interface 359 <sysfs_interface>`, refer to :ref:`action <sysfs_scheme>` part of the 360 documentation. 361 362 363 .. _damon_design_damos_access_pattern: 364 365 Target Access Pattern 366 ~~~~~~~~~~~~~~~~~~~~~ 367 368 The access pattern of the schemes' interest. The patterns are constructed with 369 the properties that DAMON's monitoring results provide, specifically the size, 370 the access frequency, and the age. Users can describe their access pattern of 371 interest by setting minimum and maximum values of the three properties. If a 372 region's three properties are in the ranges, DAMOS classifies it as one of the 373 regions that the scheme is having an interest in. 374 375 To know how user-space can set the access pattern via :ref:`DAMON sysfs 376 interface <sysfs_interface>`, refer to :ref:`access_pattern 377 <sysfs_access_pattern>` part of the documentation. 378 379 380 .. _damon_design_damos_quotas: 381 382 Quotas 383 ~~~~~~ 384 385 DAMOS upper-bound overhead control feature. DAMOS could incur high overhead if 386 the target access pattern is not properly tuned. For example, if a huge memory 387 region having the access pattern of interest is found, applying the scheme's 388 action to all pages of the huge region could consume unacceptably large system 389 resources. Preventing such issues by tuning the access pattern could be 390 challenging, especially if the access patterns of the workloads are highly 391 dynamic. 392 393 To mitigate that situation, DAMOS provides an upper-bound overhead control 394 feature called quotas. It lets users specify an upper limit of time that DAMOS 395 can use for applying the action, and/or a maximum bytes of memory regions that 396 the action can be applied within a user-specified time duration. 397 398 To know how user-space can set the basic quotas via :ref:`DAMON sysfs interface 399 <sysfs_interface>`, refer to :ref:`quotas <sysfs_quotas>` part of the 400 documentation. 401 402 403 .. _damon_design_damos_quotas_prioritization: 404 405 Prioritization 406 ^^^^^^^^^^^^^^ 407 408 A mechanism for making a good decision under the quotas. When the action 409 cannot be applied to all regions of interest due to the quotas, DAMOS 410 prioritizes regions and applies the action to only regions having high enough 411 priorities so that it will not exceed the quotas. 412 413 The prioritization mechanism should be different for each action. For example, 414 rarely accessed (colder) memory regions would be prioritized for page-out 415 scheme action. In contrast, the colder regions would be deprioritized for huge 416 page collapse scheme action. Hence, the prioritization mechanisms for each 417 action are implemented in each DAMON operations set, together with the actions. 418 419 Though the implementation is up to the DAMON operations set, it would be common 420 to calculate the priority using the access pattern properties of the regions. 421 Some users would want the mechanisms to be personalized for their specific 422 case. For example, some users would want the mechanism to weigh the recency 423 (``age``) more than the access frequency (``nr_accesses``). DAMOS allows users 424 to specify the weight of each access pattern property and passes the 425 information to the underlying mechanism. Nevertheless, how and even whether 426 the weight will be respected are up to the underlying prioritization mechanism 427 implementation. 428 429 To know how user-space can set the prioritization weights via :ref:`DAMON sysfs 430 interface <sysfs_interface>`, refer to :ref:`weights <sysfs_quotas>` part of 431 the documentation. 432 433 434 .. _damon_design_damos_quotas_auto_tuning: 435 436 Aim-oriented Feedback-driven Auto-tuning 437 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ 438 439 Automatic feedback-driven quota tuning. Instead of setting the absolute quota 440 value, users can specify the metric of their interest, and what target value 441 they want the metric value to be. DAMOS then automatically tunes the 442 aggressiveness (the quota) of the corresponding scheme. For example, if DAMOS 443 is under achieving the goal, DAMOS automatically increases the quota. If DAMOS 444 is over achieving the goal, it decreases the quota. 445 446 The goal can be specified with three parameters, namely ``target_metric``, 447 ``target_value``, and ``current_value``. The auto-tuning mechanism tries to 448 make ``current_value`` of ``target_metric`` be same to ``target_value``. 449 Currently, two ``target_metric`` are provided. 450 451 - ``user_input``: User-provided value. Users could use any metric that they 452 has interest in for the value. Use space main workload's latency or 453 throughput, system metrics like free memory ratio or memory pressure stall 454 time (PSI) could be examples. Note that users should explicitly set 455 ``current_value`` on their own in this case. In other words, users should 456 repeatedly provide the feedback. 457 - ``some_mem_psi_us``: System-wide ``some`` memory pressure stall information 458 in microseconds that measured from last quota reset to next quota reset. 459 DAMOS does the measurement on its own, so only ``target_value`` need to be 460 set by users at the initial time. In other words, DAMOS does self-feedback. 461 462 To know how user-space can set the tuning goal metric, the target value, and/or 463 the current value via :ref:`DAMON sysfs interface <sysfs_interface>`, refer to 464 :ref:`quota goals <sysfs_schemes_quota_goals>` part of the documentation. 465 466 467 .. _damon_design_damos_watermarks: 468 469 Watermarks 470 ~~~~~~~~~~ 471 472 Conditional DAMOS (de)activation automation. Users might want DAMOS to run 473 only under certain situations. For example, when a sufficient amount of free 474 memory is guaranteed, running a scheme for proactive reclamation would only 475 consume unnecessary system resources. To avoid such consumption, the user would 476 need to manually monitor some metrics such as free memory ratio, and turn 477 DAMON/DAMOS on or off. 478 479 DAMOS allows users to offload such works using three watermarks. It allows the 480 users to configure the metric of their interest, and three watermark values, 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 483 metric becomes below the mid watermark but above the low watermark, the scheme 484 is activated. If all schemes are deactivated by the watermarks, the monitoring 485 is also deactivated. In this case, the DAMON worker thread only periodically 486 checks the watermarks and therefore incurs nearly zero overhead. 487 488 To know how user-space can set the watermarks via :ref:`DAMON sysfs interface 489 <sysfs_interface>`, refer to :ref:`watermarks <sysfs_watermarks>` part of the 490 documentation. 491 492 493 .. _damon_design_damos_filters: 494 495 Filters 496 ~~~~~~~ 497 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 500 more than the kernel, such as future access patterns or some special 501 requirements for specific types of memory. For example, some users may know 502 only anonymous pages can impact their program's performance. They can also 503 have a list of latency-critical processes. 504 505 To let users optimize DAMOS schemes with such special knowledge, DAMOS provides 506 a feature called DAMOS filters. The feature allows users to set an arbitrary 507 number of filters for each scheme. Each filter specifies the type of target 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). 510 511 For efficient handling of filters, some types of filters are handled by the 512 core layer, while others are handled by operations set. In the latter case, 513 hence, support of the filter types depends on the DAMON operations set. In 514 case of the core layer-handled filters, the memory regions that excluded by the 515 filter are not counted as the scheme has tried to the region. In contrast, if 516 a memory regions is filtered by an operations set layer-handled filter, it is 517 counted as the scheme has tried. This difference affects the statistics. 518 519 Below types of filters are currently supported. 520 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 529 scheme. 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. 537 538 To know how user-space can set the watermarks via :ref:`DAMON sysfs interface 539 <sysfs_interface>`, refer to :ref:`filters <sysfs_filters>` part of the 540 documentation. 541 542 543 Application Programming Interface 544 --------------------------------- 545 546 The programming interface for kernel space data access-aware applications. 547 DAMON is a framework, so it does nothing by itself. Instead, it only helps 548 other kernel components such as subsystems and modules building their data 549 access-aware applications using DAMON's core features. For this, DAMON exposes 550 its all features to other kernel components via its application programming 551 interface, namely ``include/linux/damon.h``. Please refer to the API 552 :doc:`document </mm/damon/api>` for details of the interface. 553 554 555 .. _damon_modules: 556 557 Modules 558 ======= 559 560 Because the core of DAMON is a framework for kernel components, it doesn't 561 provide any direct interface for the user space. Such interfaces should be 562 implemented by each DAMON API user kernel components, instead. DAMON subsystem 563 itself implements such DAMON API user modules, which are supposed to be used 564 for general purpose DAMON control and special purpose data access-aware system 565 operations, and provides stable application binary interfaces (ABI) for the 566 user space. The user space can build their efficient data access-aware 567 applications using the interfaces. 568 569 570 General Purpose User Interface Modules 571 -------------------------------------- 572 573 DAMON modules that provide user space ABIs for general purpose DAMON usage in 574 runtime. 575 576 DAMON user interface modules, namely 'DAMON sysfs interface' and 'DAMON debugfs 577 interface' are DAMON API user kernel modules that provide ABIs to the 578 user-space. Please note that DAMON debugfs interface is currently deprecated. 579 580 Like many other ABIs, the modules create files on sysfs and debugfs, allow 581 users to specify their requests to and get the answers from DAMON by writing to 582 and reading from the files. As a response to such I/O, DAMON user interface 583 modules control DAMON and retrieve the results as user requested via the DAMON 584 API, and return the results to the user-space. 585 586 The ABIs are designed to be used for user space applications development, 587 rather than human beings' fingers. Human users are recommended to use such 588 user space tools. One such Python-written user space tool is available at 589 Github (https://github.com/damonitor/damo), Pypi 590 (https://pypistats.org/packages/damo), and Fedora 591 (https://packages.fedoraproject.org/pkgs/python-damo/damo/). 592 593 Please refer to the ABI :doc:`document </admin-guide/mm/damon/usage>` for 594 details of the interfaces. 595 596 597 Special-Purpose Access-aware Kernel Modules 598 ------------------------------------------- 599 600 DAMON modules that provide user space ABI for specific purpose DAMON usage. 601 602 DAMON sysfs/debugfs user interfaces are for full control of all DAMON features 603 in runtime. For each special-purpose system-wide data access-aware system 604 operations such as proactive reclamation or LRU lists balancing, the interfaces 605 could be simplified by removing unnecessary knobs for the specific purpose, and 606 extended for boot-time and even compile time control. Default values of DAMON 607 control parameters for the usage would also need to be optimized for the 608 purpose. 609 610 To support such cases, yet more DAMON API user kernel modules that provide more 611 simple and optimized user space interfaces are available. Currently, two 612 modules for proactive reclamation and LRU lists manipulation are provided. For 613 more detail, please read the usage documents for those 614 (:doc:`/admin-guide/mm/damon/reclaim` and 615 :doc:`/admin-guide/mm/damon/lru_sort`).
Linux® is a registered trademark of Linus Torvalds in the United States and other countries.
TOMOYO® is a registered trademark of NTT DATA CORPORATION.