Lines Matching full:the
13 The monitoring-related information including the monitoring request
19 To know how user-space can do the configurations and start/stop DAMON, refer to
29 operations for DAMON that depends on the given monitoring target
32 overhead/accuracy control and access-aware system operations on top of the
35 purposes that provides interfaces for the user space, on top of the core
48 the given target address space. For example, below two operations for access
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.
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 accuracy and the overhead.
60 hardware features by configuring the core logic to use the appropriate
62 new operations set can be implemented following the interface between the
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
78 <sysfs_interface>`, refer to :ref:`operations <sysfs_context>` file part of the
88 and updates the monitoring target address regions so that entire memory
89 mappings of the target processes can be covered.
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
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
98 level of noise using the adaptive regions adjustment mechanism, tracking every
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.
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
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
132 subsystems using the Accessed bits, namely Idle page tracking and the reclaim
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,
144 ranges. In some cases, the address space for a given operations set could be
145 too large to be handled with the type. ARM (32-bit) with large physical
147 parameter called ``address unit`` is provided. It represents the scale factor
148 that need to be multiplied to the core layer's address for calculating real
149 address on the given address space. Support of ``address unit`` parameter is
150 up to each operations set implementation. ``paddr`` is the only operations set
151 implementation that supports the parameter.
163 Below four sections describe each of the DAMON core mechanisms and the five
168 To know how user-space can set the attributes via :ref:`DAMON sysfs interface
170 part of the documentation.
176 The output of DAMON says what pages are how frequently accessed for a given
177 duration. The resolution of the access frequency is controlled by setting
179 access to each page per ``sampling interval`` and aggregates the results. In
180 other words, counts the number of the accesses to each page. After each
182 registered by users so that users can read the aggregated results and then
183 clears the results. This can be described in below simple pseudo-code::
196 The monitoring overhead of this mechanism will arbitrarily increase as the
197 size of the target workload grows.
205 To avoid the unbounded increase of the overhead, DAMON groups adjacent pages
206 that assumed to have the same access frequencies into a region. As long as the
207 assumption (pages in a region have the same access frequencies) is kept, only
208 one page in the region is required to be checked. Thus, for each ``sampling
210 ``sampling interval``, checks whether the page is accessed meanwhile, and
211 increases the access frequency counter of the region if so. The counter is
212 called ``nr_accesses`` of the region. Therefore, the monitoring overhead is
213 controllable by setting the number of regions. DAMON allows users to set the
214 minimum and the maximum number of regions for the trade-off.
216 This scheme, however, cannot preserve the quality of the output if the
225 Even somehow the initial monitoring target regions are well constructed to
226 fulfill the assumption (pages in same region have similar access frequencies),
227 the data access pattern can be dynamically changed. This will result in low
228 monitoring quality. To keep the assumption as much as possible, DAMON
231 For each ``aggregation interval``, it compares the access frequencies
232 (``nr_accesses``) of adjacent regions. If the difference is small, and if the
233 sum of the two regions' sizes is smaller than the size of total regions divided
234 by the ``minimum number of regions``, DAMON merges the two regions. If the
236 regions``, it repeats the merging with increasing access frequenceis difference
237 threshold until the upper-limit of the number of regions is met, or the
239 divided by ``sampling interval``). Then, after it reports and clears the
241 three regions if the total number of regions will not exceed the user-specified
242 maximum number of regions after the split.
245 keeping the bounds users set for their trade-off.
253 By analyzing the monitoring results, users can also find how long the current
255 understanding of the access pattern. For example, page placement algorithm
256 utilizing both the frequency and the recency could be implemented using that.
259 interval``, DAMON checks if the region's size and access frequency
260 (``nr_accesses``) has significantly changed. If so, the counter is reset to
261 zero. Otherwise, the counter is increased.
267 The monitoring target address range could dynamically changed. For example,
271 As the changes could be quite frequent in some cases, DAMON allows the
273 and applies it to monitoring operations-related data structures such as the
277 User-space can get the monitoring results via DAMON sysfs interface and/or
278 tracepoints. For more details, please refer to the documentations for
289 for the purpose. The amount of accesses can be measured using ``nr_accesses``
290 and ``age`` of regions in the aggregated monitoring results snapshot. The
291 default value of the interval, ``100ms``, turns out to be too short in many
293 default, ``1/20`` is recommended as the ratio.
295 ``Aggregation interval`` should be set as the time interval that the workload
296 can make an amount of accesses for the monitoring purpose, within the interval.
297 If the interval is too short, only small number of accesses are captured. As a
298 result, the monitoring results look everything is samely accessed only rarely.
299 For many purposes, that would be useless. If it is too long, however, the time
300 to converge regions with the :ref:`regions adjustment mechanism
301 <damon_design_adaptive_regions_adjustment>` can be too long, depending on the
302 time scale of the given purpose. This could happen if the workload is actually
303 making only rare accesses but the user thinks the amount of accesses for the
304 monitoring purpose too high. For such cases, the target amount of access to
306 that the captured amount of accesses is represented with not only
307 ``nr_accesses``, but also ``age``. For example, even if every region on the
309 distinguished using ``age`` values as the recency information.
311 Hence the optimum value of ``aggregation interval`` depends on the access
312 intensiveness of the workload. The user should tune the interval based on the
313 amount of access that captured on each aggregated snapshot of the monitoring
316 Note that the default value of the interval is 100 milliseconds, which is too
319 ``Sampling interval`` defines the resolution of each aggregation. If it is set
322 undistinguishable based on access pattern, and therefore the results will be
324 degrade the resolution, but will increase the monitoring overhead. If it is
325 appropriate enough to provide a resolution of the monitoring results that
326 sufficient for the given purpose, it shouldn't be unnecessarily further
328 By default, the ratio is set as ``1/20``, and it is still recommended.
330 Based on the manual tuning guide, DAMON provides more intuitive knob-based
331 intervals auto tuning mechanism. Please refer to :ref:`the design document of
332 the feature <damon_design_monitoring_intervals_autotuning>` for detail.
334 Refer to below documents for an example tuning based on the above guide.
347 DAMON provides automatic tuning of the ``sampling interval`` and ``aggregation
348 interval`` based on the :ref:`the tuning guide idea
349 <damon_design_monitoring_params_tuning_guide>`. The tuning mechanism allows
350 users to set the aimed amount of access events to observe via DAMON within
351 given time interval. The target can be specified by the user as a ratio of
352 DAMON-observed access events to the theoretical maximum amount of the events
356 The DAMON-observed access events are calculated in byte granularity based on
360 access events for the region is calculated in same way, but replacing ``Y``
364 The mechanism calculates the ratio of access events for ``aggrs`` aggregations,
365 and increases or decrease the ``sampleing interval`` and ``aggregation
366 interval`` in same ratio, if the observed access ratio is lower or higher than
367 the target, respectively. The ratio of the intervals change is decided in
368 proportion to the distance between current samples ratio and the target ratio.
370 The user can further set the minimum and maximum ``sampling interval`` that can
371 be set by the tuning mechanism using two parameters (``min_sample_us`` and
372 ``max_sample_us``). Because the tuning mechanism changes ``sampling interval``
373 and ``aggregation interval`` in same ratio always, the minimum and maximum
374 ``aggregation interval`` after each of the tuning changes can automatically set
377 The tuning is turned off by default, and need to be set explicitly by the user.
378 As a rule of thumbs and the Parreto principle, 4% access samples ratio target
385 <damon_usage_sysfs_monitoring_intervals_goal>` part of the documentation.
404 optimizations. That is, getting data access monitoring results of the
405 workloads or the system using DAMON, finding memory regions of special
406 characteristics by profiling the monitoring results, and making system
407 operation changes for the regions. The changes could be made by modifying or
408 providing advice to the software (the application and/or the kernel), or
409 reconfiguring the hardware. Both offline and online approaches could be
412 Among those, providing advice to the kernel at runtime would be flexible and
414 could impose unnecessary redundancy and inefficiency. The profiling could be
415 redundant if the type of interest is common. Exchanging the information
419 To allow users to reduce such redundancy and inefficiencies by offloading the
423 the access pattern of interest, and applies the user-desired operation actions
424 to the regions, for every user-specified time interval called
429 part of the documentation.
437 The management action that the users desire to apply to the regions of their
440 collecting statistics of the regions.
442 The list of supported actions is defined in DAMOS, but the implementation of
443 each action is in the DAMON operations set layer because the implementation
444 normally depends on the monitoring target address space. For example, the code
446 physical address ranges. And the monitoring operations implementation sets are
447 not mandated to support all actions of the list. Hence, the availability of
451 The list of the supported actions, their meaning, and DAMON operations sets
454 - ``willneed``: Call ``madvise()`` for the region with ``MADV_WILLNEED``.
456 - ``cold``: Call ``madvise()`` for the region with ``MADV_COLD``.
458 - ``pageout``: Reclaim the region.
460 - ``hugepage``: Call ``madvise()`` for the region with ``MADV_HUGEPAGE``.
462 - ``nohugepage``: Call ``madvise()`` for the region with ``MADV_NOHUGEPAGE``.
464 - ``lru_prio``: Prioritize the region on its LRU lists.
466 - ``lru_deprio``: Deprioritize the region on its LRU lists.
468 - ``migrate_hot``: Migrate the regions prioritizing warmer regions.
470 - ``migrate_cold``: Migrate the regions prioritizing colder regions.
472 - ``stat``: Do nothing but count the statistics.
475 Applying the actions except ``stat`` to a region is considered as changing the
476 region's characteristics. Hence, DAMOS resets the age of regions when any such
479 To know how user-space can set the action via :ref:`DAMON sysfs interface
480 <sysfs_interface>`, refer to :ref:`action <sysfs_scheme>` part of the
489 The access pattern of the schemes' interest. The patterns are constructed with
490 the properties that DAMON's monitoring results provide, specifically the size,
491 the access frequency, and the age. Users can describe their access pattern of
492 interest by setting minimum and maximum values of the three properties. If a
493 region's three properties are in the ranges, DAMOS classifies it as one of the
494 regions that the scheme is having an interest in.
496 To know how user-space can set the access pattern via :ref:`DAMON sysfs
498 <sysfs_access_pattern>` part of the documentation.
507 the target access pattern is not properly tuned. For example, if a huge memory
508 region having the access pattern of interest is found, applying the scheme's
509 action to all pages of the huge region could consume unacceptably large system
510 resources. Preventing such issues by tuning the access pattern could be
511 challenging, especially if the access patterns of the workloads are highly
516 can use for applying the action, and/or a maximum bytes of memory regions that
517 the action can be applied within a user-specified time duration.
519 To know how user-space can set the basic quotas via :ref:`DAMON sysfs interface
520 <sysfs_interface>`, refer to :ref:`quotas <sysfs_quotas>` part of the
529 A mechanism for making a good decision under the quotas. When the action
530 cannot be applied to all regions of interest due to the quotas, DAMOS
531 prioritizes regions and applies the action to only regions having high enough
532 priorities so that it will not exceed the quotas.
534 The prioritization mechanism should be different for each action. For example,
536 scheme action. In contrast, the colder regions would be deprioritized for huge
537 page collapse scheme action. Hence, the prioritization mechanisms for each
538 action are implemented in each DAMON operations set, together with the actions.
540 Though the implementation is up to the DAMON operations set, it would be common
541 to calculate the priority using the access pattern properties of the regions.
542 Some users would want the mechanisms to be personalized for their specific
543 case. For example, some users would want the mechanism to weigh the recency
544 (``age``) more than the access frequency (``nr_accesses``). DAMOS allows users
545 to specify the weight of each access pattern property and passes the
546 information to the underlying mechanism. Nevertheless, how and even whether
547 the weight will be respected are up to the underlying prioritization mechanism
550 To know how user-space can set the prioritization weights via :ref:`DAMON sysfs
552 the documentation.
560 Automatic feedback-driven quota tuning. Instead of setting the absolute quota
561 value, users can specify the metric of their interest, and what target value
562 they want the metric value to be. DAMOS then automatically tunes the
563 aggressiveness (the quota) of the corresponding scheme. For example, if DAMOS
564 is under achieving the goal, DAMOS automatically increases the quota. If DAMOS
565 is over achieving the goal, it decreases the quota.
567 The goal can be specified with five parameters, namely ``target_metric``,
568 ``target_value``, ``current_value``, ``nid`` and ``path``. The auto-tuning
573 has interest in for the value. Use space main workload's latency or
577 repeatedly provide the feedback.
580 DAMOS does the measurement on its own, so only ``target_value`` need to be
581 set by users at the initial time. In other words, DAMOS does self-feedback.
591 point the specific NUMA node.
594 ``node_memcg_free_bp`` to point the path to the cgroup. The value should be
595 the path of the memory cgroup from the cgroups mount point.
597 To know how user-space can set the tuning goal metric, the target value, and/or
598 the current value via :ref:`DAMON sysfs interface <sysfs_interface>`, refer to
599 :ref:`quota goals <sysfs_schemes_quota_goals>` part of the documentation.
610 consume unnecessary system resources. To avoid such consumption, the user would
614 DAMOS allows users to offload such works using three watermarks. It allows the
615 users to configure the metric of their interest, and three watermark values,
616 namely high, middle, and low. If the value of the metric becomes above the
617 high watermark or below the low watermark, the scheme is deactivated. If the
618 metric becomes below the mid watermark but above the low watermark, the scheme
619 is activated. If all schemes are deactivated by the watermarks, the monitoring
620 is also deactivated. In this case, the DAMON worker thread only periodically
621 checks the watermarks and therefore incurs nearly zero overhead.
623 To know how user-space can set the watermarks via :ref:`DAMON sysfs interface
624 <sysfs_interface>`, refer to :ref:`watermarks <sysfs_watermarks>` part of the
635 more than the kernel, such as future access patterns or some special
641 a feature called DAMOS filters. The feature allows users to set an arbitrary
645 - whether it is for the memory of the type or all except the type
648 the scheme's action to the memory (``allow``).
650 For efficient handling of filters, some types of filters are handled by the
651 core layer, while others are handled by operations set. In the latter case,
652 hence, support of the filter types depends on the DAMON operations set. In
653 case of the core layer-handled filters, the memory regions that excluded by the
654 filter are not counted as the scheme has tried to the region. In contrast, if
656 counted as the scheme has tried. This difference affects the statistics.
658 When multiple filters are installed, the group of filters that handled by the
659 core layer are evaluated first. After that, the group of filters that handled
660 by the operations layer are evaluated. Filters in each of the groups are
661 evaluated in the installed order. If a part of memory is matched to one of the
662 filter, next filters are ignored. If the part passes through the filters
663 evaluation stage because it is not matched to any of the filters, applying the
664 scheme's action to it depends on the last filter's allowance type. If the last
665 filter was for allowing, the part of memory will be rejected, and vice versa.
668 another filter for rejecting young pages are installed in the order. If a page
669 of a region that eligible to apply the scheme's action is an anonymous page,
670 the scheme's action will be applied to the page regardless of whether it is
671 young or not, since it matches with the first allow-filter. If the page is
672 not anonymous but young, the scheme's action will not be applied, since the
673 second reject-filter blocks it. If the page is neither anonymous nor young,
674 the page will pass through the filters evaluation stage since there is no
675 matching filter, and the action will be applied to the page.
692 - Applied to pages that are accessed after the last access check from the
699 To know how user-space can set the filters via :ref:`DAMON sysfs interface
700 <sysfs_interface>`, refer to :ref:`filters <sysfs_filters>` part of the
708 The statistics of DAMOS behaviors that designed to help monitoring, tuning and
711 DAMOS accounts below statistics for each scheme, from the beginning of the
714 - ``nr_tried``: Total number of regions that the scheme is tried to be applied.
715 - ``sz_tried``: Total size of regions that the scheme is tried to be applied.
718 - ``nr_applied``: Total number of regions that the scheme is applied.
719 - ``sz_applied``: Total size of regions that the scheme is applied.
720 - ``qt_exceeds``: Total number of times the quota of the scheme has exceeded.
723 the region is eligible to apply the scheme's :ref:`action
724 <damon_design_damos_action>`. The :ref:`access pattern
729 The core logic will only ask the underlying :ref:`operation set
730 <damon_operations_set>` to do apply the action to the region, so whether the
733 "A scheme is applied to a region" means the :ref:`operation set
734 <damon_operations_set>` has applied the action to at least a part of the
735 region. The :ref:`filters <damon_design_damos_filters>` that handled by the
736 operation set, and the types of the :ref:`action <damon_design_damos_action>`
737 and the pages of the region can affect this. For example, if a filter is set
738 to exclude anonymous pages and the region has only anonymous pages, or if the
739 action is ``pageout`` while all pages of the region are unreclaimable, applying
740 the action to the region will fail.
742 To know how user-space can read the stats via :ref:`DAMON sysfs interface
743 <sysfs_interface>`, refer to :ref:s`stats <sysfs_stats>` part of the
751 access full properties of the regions including the access monitoring results
752 and amount of the region's internal memory that passed the DAMOS filters.
753 :ref:`DAMON sysfs interface <sysfs_interface>` also allows users read the data
761 The programming interface for kernel space data access-aware applications.
766 interface, namely ``include/linux/damon.h``. Please refer to the API
767 :doc:`document </mm/damon/api>` for details of the interface.
775 Because the core of DAMON is a framework for kernel components, it doesn't
776 provide any direct interface for the user space. Such interfaces should be
780 operations, and provides stable application binary interfaces (ABI) for the
781 user space. The user space can build their efficient data access-aware
782 applications using the interfaces.
791 Like many other ABIs, the modules create files on pseudo file systems like
792 'sysfs', allow users to specify their requests to and get the answers from
793 DAMON by writing to and reading from the files. As a response to such I/O,
794 DAMON user interface modules control DAMON and retrieve the results as user
795 requested via the DAMON API, and return the results to the user-space.
797 The ABIs are designed to be used for user space applications development,
805 available. Please refer to the ABI :ref:`doc <sysfs_interface>` for details of
806 the interfaces.
816 operations such as proactive reclamation or LRU lists balancing, the interfaces
817 could be simplified by removing unnecessary knobs for the specific purpose, and
819 control parameters for the usage would also need to be optimized for the
825 more detail, please read the usage documents for those