Introduce Data Access MONitor (DAMON)
Subsystems (8)
v11 cover Introduce Data Access MONitor (DAMON)
From: SeongJae Park <[email protected]>
Introduction
============
Memory management decisions can be improved if finer data access information is available. However, because such finer information usually comes with higher overhead, most systems including Linux forgives the potential benefit and rely on only coarse information or some light-weight heuristics. The pseudo-LRU and the aggressive THP promotions are such examples.
A number of data access pattern awared memory management optimizations (refer to 'Appendix A' for more details) consistently say the potential benefit is not small. However, none of those has successfully merged to the mainline Linux kernel mainly due to the absence of a scalable and efficient data access monitoring mechanism. Refer to 'Appendix B' to see the limitations of existing memory monitoring mechanisms.
DAMON is a data access monitoring subsystem for the problem. It is 1) accurate enough to be used for the DRAM level memory management (a straightforward DAMON-based optimization achieved up to 2.55x speedup), 2) light-weight enough to be applied online (compared to a straightforward access monitoring scheme, DAMON is up to 94,242.42x lighter) and 3) keeps predefined upper-bound overhead regardless of the size of target workloads (thus scalable). Refer to 'Appendix C' if you interested in how it is possible, and 'Appendix F' to know how the numbers collected.
DAMON has mainly designed for the kernel's memory management mechanisms. However, because it is implemented as a standalone kernel module and provides several interfaces, it can be used by a wide range of users including kernel space programs, user space programs, programmers, and administrators. DAMON is now supporting the monitoring only, but it will also provide simple and convenient data access pattern awared memory managements by itself. Refer to 'Appendix D' for more detailed expected usages of DAMON.
Boring? Here Are Something Colorful
===================================
For intuitive understanding of DAMON, I made web pages[1-8] showing the visualized dynamic data access pattern of various realistic workloads in PARSEC3 and SPLASH-2X bechmark suites. The figures are generated using the user space tool in 10th patch of this patchset.
There are pages showing the heatmap format dynamic access pattern of each workload for heap area[1], mmap()-ed area[2], and stack[3] area. I splitted the entire address space to the three area because there are huge unmapped regions between the areas.
You can also show how the dynamic working set size of each workload is distributed[4], and how it is chronologically changing[5].
The most important characteristic of DAMON is its promise of the upperbound of the monitoring overhead. To show whether DAMON keeps the promise well, I visualized the number of monitoring operations required for each 5 milliseconds, which is configured to not exceed 1000. You can show the distribution of the numbers[6] and how it changes chronologically[7].
[1] https://damonitor.github.io/reports/latest/by_image/heatmap.0.png.html
[2] https://damonitor.github.io/reports/latest/by_image/heatmap.1.png.html
[3] https://damonitor.github.io/reports/latest/by_image/heatmap.2.png.html
[4] https://damonitor.github.io/reports/latest/by_image/wss_sz.png.html
[5] https://damonitor.github.io/reports/latest/by_image/wss_time.png.html
[6] https://damonitor.github.io/reports/latest/by_image/nr_regions_sz.png.html
[7] https://damonitor.github.io/reports/latest/by_image/nr_regions_time.png.html
Future Plans
============
This patchset is only for the first stage of DAMON. As soon as this patchset is merged, official patchsets for below future plans will be posted.
Automate Data Access Pattern-aware Memory Management
----------------------------------------------------
Though DAMON provides the monitoring feature, implementing data access pattern aware memory management schemes could be difficult to beginners. DAMON will be able to do most of the work by itself in near future. Users will be required to only describe what kind of data access monitoring-based operation schemes they want.
By applying a very simple scheme for THP promotion/demotion with a latest version of the patchset (not posted yet), DAMON achieved 18x lower memory space overhead compared to THP while preserving about 50% of the THP performance benefit with SPLASH-2X benchmark suite.
An RFC patchset for this plan is already available
(https://lore.kernel.org/linux-mm/[email protected]/).
Support Various Address Spaces
------------------------------
Currently, DAMON supports virtual memory address spaces using PTE Accessed bits as its access checking primitive. However, the core design of DAMON is not dependent to such implementation details. In a future, DAMON will decouple those and support various address spaces including physical memory. It will further allow users to configure and even implement the primitives by themselves for their special usecase. Monitoring of page cache, NUMA nodes, specific files, or block devices would be examples of such usecases.
An RFC patchset for this plan is already available
(https://lore.kernel.org/linux-mm/[email protected]/).
Frequently Asked Questions
==========================
Q: Why a new module, instead of extending perf or other tools?
A: First, DAMON aims to be used by other programs including the kernel. Therefore, having dependency to specific tools like perf is not desirable. Second, because it need to be lightweight as much as possible so that it can be used online, any unnecessary overhead such as kernel - user space context switching cost should be avoided. These are the two most biggest reasons why DAMON is implemented in the kernel space. The idle page tracking subsystem would be the kernel module that most seems similar to DAMON. However, its own interface is not compatible with DAMON. Also, the internal implementation of it has no common part to be reused by DAMON.
Q: Can 'perf mem' or PMUs used instead of DAMON?
A: No. Roughly speaking, DAMON has two seperate layers. The low layer is access check of pages, and the higher layer is its core mechanisms for overhead controlling. For the low layer, DAMON is now using the PTE Accessed bits. Other H/W or S/W features that can be used for the access check of pages, such as 'perf mem', PMU, or even page idle, could be used instead in the layer. However, those could not alternate the high layer of DAMON.
Evaluations
===========
We evaluated DAMON's overhead, monitoring quality and usefulness using 25 realistic workloads on my QEMU/KVM based virtual machine.
DAMON is lightweight. It consumes only 0.03% more system memory and up to 1% CPU time. It makes target worloads only 0.7% slower.
DAMON is accurate and useful for memory management optimizations. An experimental DAMON-based operation scheme for THP removes 63.12% of THP memory overheads while preserving 49.15% of THP speedup. Another experimental DAMON-based 'proactive reclamation' implementation reduces 85.85% of residentail sets and 21.98% of system memory footprint while incurring only 2.42% runtime overhead in best case (parsec3/freqmine).
NOTE that the experimentail THP optimization and proactive reclamation are not for production, just only for proof of concepts.
Please refer to 'Appendix E' for detailed evaluation setup and results.
References
==========
Prototypes of DAMON have introduced by an LPC kernel summit track talk[1] and two academic papers[2,3]. Please refer to those for more detailed information, especially the evaluations. The latest version of the patchsets has also introduced by an LWN artice[4].
[1] SeongJae Park, Tracing Data Access Pattern with Bounded Overhead and Best-effort Accuracy. In The Linux Kernel Summit, September 2019.
https://linuxplumbersconf.org/event/4/contributions/548/
[2] SeongJae Park, Yunjae Lee, Heon Y. Yeom, Profiling Dynamic Data Access Patterns with Controlled Overhead and Quality. In 20th ACM/IFIP International Middleware Conference Industry, December 2019.
https://dl.acm.org/doi/10.1145/3366626.3368125
[3] SeongJae Park, Yunjae Lee, Yunhee Kim, Heon Y. Yeom, Profiling Dynamic Data Access Patterns with Bounded Overhead and Accuracy. In IEEE International Workshop on Foundations and Applications of Self- Systems (FAS 2019), June 2019.
[4] Jonathan Corbet, Memory-management optimization with DAMON. In Linux Weekly
News (LWN), Feb 2020. https://lwn.net/Articles/812707/
Baseline and Complete Git Trees
===============================
The patches are based on the v5.6. You can also clone the complete git tree:
$ git clone git://github.com/sjp38/linux -b damon/patches/v11
The web is also available:
https://github.com/sjp38/linux/releases/tag/damon/patches/v11
This patchset contains patches for the stabled main logic of DAMON only. The latest DAMON development tree is also available at:
https://github.com/sjp38/linux/tree/damon/master
Sequence Of Patches
===================
The patches are organized in the following sequence. The first two patches are preparation of DAMON patchset. The 1st patch adds typos found in previous versions of DAMON patchset to 'scripts/spelling.txt' so that the typos can be caught by 'checkpatch.pl'. The 2nd patch exports 'lookup_page_ext()' to GPL modules so that it can be used by DAMON even though it is built as a loadable module.
Next five patches implement the core of DAMON and it's programming interface. The 3rd patch introduces DAMON module, it's data structures, and data structure related common functions. Following four patches (4nd to 7th) implements the core mechanisms of DAMON, namely regions based sampling (patch 4), adaptive regions adjustment (patches 5-6), and dynamic memory mapping chage adoption (patch 7).
Following four patches are for low level users of DAMON. The 8th patch implements callbacks for each of monitoring steps so that users can do whatever they want with the access patterns. The 9th one implements recording of access patterns in DAMON for better convenience and efficiency. Each of next two patches (10th and 11th) respectively adds a debugfs interface for privileged people and/or programs in user space, and a tracepoint for other tracepoints supporting tracers such as perf.
Two patches for high level users of DAMON follows. To provide a minimal reference to the debugfs interface and for high level use/tests of the DAMON, the next patch (12th) implements an user space tool. The 13th patch adds a document for administrators of DAMON.
Next two patches are for tests. The 14th and 15th patches provide unit tests (based on kunit) and user space tests (based on kselftest), respectively.
Finally, the last patch (16th) updates the MAINTAINERS file.
Patch History
=============
The most biggest change in this version is support of minimal region size, which defaults to 'PAGE_SIZE'. This change will reduce unnecessary region splits and thus improve the quality of the output. In a future, we will be able to make this configurable for support of various access check primitives such as PMUs.
Changes from v10
(https://lore.kernel.org/linux-mm/[email protected]/)
- Reduce aggressive split overhead by doing it only if required
Changes from v9
(https://lore.kernel.org/linux-mm/[email protected]/)
- Split each region into 4 subregions if possible (Jonathan Cameraon)
- Update kunit test for the split code change
Changes from v8
(https://lore.kernel.org/linux-mm/[email protected]/)
- Make regions always aligned by minimal region size that can be changed (Stefan Nuernberger)
- Store binary format version in the recording file (Stefan Nuernberger)
- Use 'int' for pid instead of 'unsigned long' (Stefan Nuernberger)
- Fix a race condition in damon thread termination (Stefan Nuernberger)
- Optimize random value generation and recording (Stefan Nuernberger)
- Clean up commit messages and comments (Stefan Nuernberger)
- Clean up code (Stefan Nuernberger)
- Use explicit signalling and 'do_exit()' for damon thread termination
- Add more typos to spelling.txt
- Update the performance evaluation results
- Describe future plans in the cover letter
Changes from v7
(https://lore.kernel.org/linux-mm/[email protected]/)
- Cleanup variable names (Jonathan Cameron)
- Split sampling address setup from access_check() (Jonathan Cameron)
- Make sampling address to always locate in the region (Jonathan Cameron)
- Make initial region's sampling addr to be old (Jonathan Cameron)
- Split kdamond on/off function to seperate functions (Jonathan Cameron)
- Fix wrong kernel doc comments (Jonathan Cameron)
- Reset 'last_accessed' to false in kdamond_check_access() if necessary
- Rebase on v5.6
Changes from v6
(https://lore.kernel.org/linux-mm/[email protected]/)
- Wordsmith cover letter (Shakeel Butt)
- Cleanup code and commit messages (Jonathan Cameron)
- Avoid kthread_run() under spinlock critical section (Jonathan Cameron)
- Use kthread_stop() (Jonathan Cameron)
- Change tracepoint to trace regions (Jonathan Cameron)
- Implement API from the beginning (Jonathan Cameron)
- Fix typos (Jonathan Cameron)
- Fix access checking to properly handle regions smaller than single page (Jonathan Cameron)
- Add found typos to 'scripts/spelling.txt'
- Add recent evaluation results including DAMON-based Operation Schemes
Changes from v5
(https://lore.kernel.org/linux-mm/[email protected]/)
- Fix minor bugs (sampling, record attributes, debugfs and user space tool)
- selftests: Add debugfs interface tests for the bugs
- Modify the user space tool to use its self default values for parameters
- Fix pmg huge page access check
Changes from v4
(https://lore.kernel.org/linux-mm/[email protected]/)
- Add 'Reviewed-by' for the kunit tests patch (Brendan Higgins)
- Make the unit test to depedns on 'DAMON=y' (Randy Dunlap and kbuild bot)
- Fix m68k module build issue
- Add selftests
- Seperate patches for low level users from core logics for better reading
- Clean up debugfs interface
- Trivial nitpicks
Changes from v3
(https://lore.kernel.org/linux-mm/[email protected]/)
- Fix i386 build issue
- Increase the default size of the monitoring result buffer to 1 MiB
- Fix misc bugs in debugfs interface
Changes from v2
(https://lore.kernel.org/linux-mm/[email protected]/)
- Move MAINTAINERS changes to last commit (Brendan Higgins)
- Add descriptions for kunittest: why not only entire mappings and what the 4 input sets are trying to test (Brendan Higgins)
- Remove 'kdamond_need_stop()' test (Brendan Higgins)
- Discuss about the 'perf mem' and DAMON (Peter Zijlstra)
- Make CV clearly say what it actually does (Peter Zijlstra)
- Answer why new module (Qian Cai)
- Diable DAMON by default (Randy Dunlap)
- Change the interface: Seperate recording attributes
(attrs, record, rules) and allow multiple kdamond instances
- Implement kernel API interface
Changes from v1
(https://lore.kernel.org/linux-mm/[email protected]/)
- Rebase on v5.5
- Add a tracepoint for integration with other tracers (Kirill A. Shutemov)
- document: Add more description for the user space tool (Brendan Higgins)
- unittest: Improve readability (Brendan Higgins)
- unittest: Use consistent name and helpers function (Brendan Higgins)
- Update PG_Young to avoid reclaim logic interference (Yunjae Lee)
Changes from RFC
(https://lore.kernel.org/linux-mm/[email protected]/)
- Specify an ambiguous plan of access pattern based mm optimizations
- Support loadable module build
- Cleanup code
SeongJae Park (16):
scripts/spelling: Add a few more typos mm/page_ext: Export lookup_page_ext() to GPL modules
mm: Introduce Data Access MONitor (DAMON) mm/damon: Implement region based sampling mm/damon: Adaptively adjust regions
mm/damon: Split regions into 3 subregions if necessary mm/damon: Apply dynamic memory mapping changes mm/damon: Implement callbacks
mm/damon: Implement access pattern recording mm/damon: Add debugfs interface
mm/damon: Add tracepoints
tools: Add a minimal user-space tool for DAMON Documentation/admin-guide/mm: Add a document for DAMON mm/damon: Add kunit tests
mm/damon: Add user space selftests
MAINTAINERS: Update for DAMON
.../admin-guide/mm/data_access_monitor.rst | 428 +++++ Documentation/admin-guide/mm/index.rst | 1 + MAINTAINERS | 12 + include/linux/damon.h | 78 + include/trace/events/damon.h | 43 + mm/Kconfig | 23 + mm/Makefile | 1 + mm/damon-test.h | 622 +++++++ mm/damon.c | 1511 +++++++++++++++++ mm/page_ext.c | 1 + scripts/spelling.txt | 8 + tools/damon/.gitignore | 1 + tools/damon/_dist.py | 36 + tools/damon/_recfile.py | 23 + tools/damon/bin2txt.py | 67 + tools/damon/damo | 37 + tools/damon/heats.py | 362 ++++ tools/damon/nr_regions.py | 91 + tools/damon/record.py | 212 +++ tools/damon/report.py | 45 + tools/damon/wss.py | 97 ++ tools/testing/selftests/damon/Makefile | 7 + .../selftests/damon/_chk_dependency.sh | 28 + tools/testing/selftests/damon/_chk_record.py | 108 ++ .../testing/selftests/damon/debugfs_attrs.sh | 139 ++ .../testing/selftests/damon/debugfs_record.sh | 50 + 26 files changed, 4031 insertions(+) create mode 100644 Documentation/admin-guide/mm/data_access_monitor.rst create mode 100644 include/linux/damon.h create mode 100644 include/trace/events/damon.h create mode 100644 mm/damon-test.h create mode 100644 mm/damon.c create mode 100644 tools/damon/.gitignore create mode 100644 tools/damon/_dist.py create mode 100644 tools/damon/_recfile.py create mode 100644 tools/damon/bin2txt.py create mode 100755 tools/damon/damo create mode 100644 tools/damon/heats.py create mode 100644 tools/damon/nr_regions.py create mode 100644 tools/damon/record.py create mode 100644 tools/damon/report.py create mode 100644 tools/damon/wss.py create mode 100644 tools/testing/selftests/damon/Makefile create mode 100644 tools/testing/selftests/damon/_chk_dependency.sh create mode 100644 tools/testing/selftests/damon/_chk_record.py create mode 100755 tools/testing/selftests/damon/debugfs_attrs.sh create mode 100755 tools/testing/selftests/damon/debugfs_record.sh
Signature · 445 lines
2.17.1
================================== >8 =========================================
Appendix A: Related Works
=========================
There are a number of researches[1,2,3,4,5,6] optimizing memory management
mechanisms based on the actual memory access patterns that shows impressive
results. However, most of those has no deep consideration about the monitoring
of the accesses itself. Some of those focused on the overhead of the
monitoring, but does not consider the accuracy scalability[6] or has additional
dependencies[7]. Indeed, one recent research[5] about the proactive
reclamation has also proposed[8] to the kernel community but the monitoring
overhead was considered a main problem.
[1] Subramanya R Dulloor, Amitabha Roy, Zheguang Zhao, Narayanan Sundaram,
Nadathur Satish, Rajesh Sankaran, Jeff Jackson, and Karsten Schwan. 2016.
Data tiering in heterogeneous memory systems. In Proceedings of the 11th
European Conference on Computer Systems (EuroSys). ACM, 15.
[2] Youngjin Kwon, Hangchen Yu, Simon Peter, Christopher J Rossbach, and Emmett
Witchel. 2016. Coordinated and efficient huge page management with ingens.
In 12th USENIX Symposium on Operating Systems Design and Implementation
(OSDI). 705–721.
[3] Harald Servat, Antonio J Peña, Germán Llort, Estanislao Mercadal,
HansChristian Hoppe, and Jesús Labarta. 2017. Automating the application
data placement in hybrid memory systems. In 2017 IEEE International
Conference on Cluster Computing (CLUSTER). IEEE, 126–136.
[4] Vlad Nitu, Boris Teabe, Alain Tchana, Canturk Isci, and Daniel Hagimont.
2018. Welcome to zombieland: practical and energy-efficient memory
disaggregation in a datacenter. In Proceedings of the 13th European
Conference on Computer Systems (EuroSys). ACM, 16.
[5] Andres Lagar-Cavilla, Junwhan Ahn, Suleiman Souhlal, Neha Agarwal, Radoslaw
Burny, Shakeel Butt, Jichuan Chang, Ashwin Chaugule, Nan Deng, Junaid
Shahid, Greg Thelen, Kamil Adam Yurtsever, Yu Zhao, and Parthasarathy
Ranganathan. 2019. Software-Defined Far Memory in Warehouse-Scale
Computers. In Proceedings of the 24th International Conference on
Architectural Support for Programming Languages and Operating Systems
(ASPLOS). ACM, New York, NY, USA, 317–330.
DOI:https://doi.org/10.1145/3297858.3304053
[6] Carl Waldspurger, Trausti Saemundsson, Irfan Ahmad, and Nohhyun Park.
2017. Cache Modeling and Optimization using Miniature Simulations. In 2017
USENIX Annual Technical Conference (ATC). USENIX Association, Santa
Clara, CA, 487–498.
https://www.usenix.org/conference/atc17/technical-sessions/
[7] Haojie Wang, Jidong Zhai, Xiongchao Tang, Bowen Yu, Xiaosong Ma, and
Wenguang Chen. 2018. Spindle: Informed Memory Access Monitoring. In 2018
USENIX Annual Technical Conference (ATC). USENIX Association, Boston, MA,
561–574. https://www.usenix.org/conference/atc18/presentation/wang-haojie
[8] Jonathan Corbet. 2019. Proactively reclaiming idle memory. (2019).
https://lwn.net/Articles/787611/.
Appendix B: Limitations of Other Access Monitoring Techniques
=============================================================
The memory access instrumentation techniques which are applied to
many tools such as Intel PIN is essential for correctness required cases such
as memory access bug detections or cache level optimizations. However, those
usually incur exceptionally high overhead which is unacceptable.
Periodic access checks based on access counting features (e.g., PTE Accessed
bits or PG_Idle flags) can reduce the overhead. It sacrifies some of the
quality but it's still ok to many of this domain. However, the overhead
arbitrarily increase as the size of the target workload grows. Miniature-like
static region based sampling can set the upperbound of the overhead, but it
will now decrease the quality of the output as the size of the workload grows.
DAMON is another solution that overcomes the limitations. It is 1) accurate
enough for this domain, 2) light-weight so that it can be applied online, and
3) allow users to set the upper-bound of the overhead, regardless of the size
of target workloads. It is implemented as a simple and small kernel module to
support various users in both of the user space and the kernel space. Refer to
'Evaluations' section below for detailed performance of DAMON.
For the goals, DAMON utilizes its two core mechanisms, which allows lightweight
overhead and high quality of output, repectively. To show how DAMON promises
those, refer to 'Mechanisms of DAMON' section below.
Appendix C: Mechanisms of DAMON
===============================
Basic Access Check
------------------
DAMON basically reports what pages are how frequently accessed. The report is
passed to users in binary format via a ``result file`` which users can set it's
path. Note that the frequency is not an absolute number of accesses, but a
relative frequency among the pages of the target workloads.
Users can also control the resolution of the reports by setting two time
intervals, ``sampling interval`` and ``aggregation interval``. In detail,
DAMON checks access to each page per ``sampling interval``, aggregates the
results (counts the number of the accesses to each page), and reports the
aggregated results per ``aggregation interval``. For the access check of each
page, DAMON uses the Accessed bits of PTEs.
This is thus similar to the previously mentioned periodic access checks based
mechanisms, which overhead is increasing as the size of the target process
grows.
Region Based Sampling
---------------------
To avoid the unbounded increase of the overhead, DAMON groups a number of
adjacent pages that assumed to have same access frequencies into a region. As
long as the assumption (pages in a region have 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 and clears
its Accessed bit. After one more ``sampling interval``, DAMON reads the
Accessed bit of the page and increases the access frequency of the region if
the bit has set meanwhile. Therefore, the monitoring overhead is controllable
by setting the number of regions. DAMON allows users to set the minimal and
maximum number of regions for the trade-off.
Except the assumption, this is almost same with the above-mentioned
miniature-like static region based sampling. In other words, this scheme
cannot preserve the quality of the output if the assumption is not guaranteed.
Adaptive Regions Adjustment
---------------------------
At the beginning of the monitoring, DAMON constructs the initial regions by
evenly splitting the memory mapped address space of the process into the
user-specified minimal number of regions. In this initial state, the
assumption is normally not kept and thus the quality could be low. To keep the
assumption as much as possible, DAMON adaptively merges and splits each region.
For each ``aggregation interval``, it compares the access frequencies of
adjacent regions and merges those if the frequency difference is small. Then,
after it reports and clears the aggregated access frequency of each region, it
splits each region into two regions if the total number of regions is smaller
than the half of the user-specified maximum number of regions.
In this way, DAMON provides its best-effort quality and minimal overhead while
keeping the bounds users set for their trade-off.
Applying Dynamic Memory Mappings
--------------------------------
Only a number of small parts in the super-huge virtual address space of the
processes is mapped to physical memory and accessed. Thus, tracking the
unmapped address regions is just wasteful. However, tracking every memory
mapping change might incur an overhead. For the reason, DAMON applies the
dynamic memory mapping changes to the tracking regions only for each of an
user-specified time interval (``regions update interval``).
Appendix D: Expected Use-cases
==============================
A straightforward usecase of DAMON would be the program behavior analysis.
With the DAMON output, users can confirm whether the program is running as
intended or not. This will be useful for debuggings and tests of design
points.
The monitored results can also be useful for counting the dynamic working set
size of workloads. For the administration of memory overcommitted systems or
selection of the environments (e.g., containers providing different amount of
memory) for your workloads, this will be useful.
If you are a programmer, you can optimize your program by managing the memory
based on the actual data access pattern. For example, you can identify the
dynamic hotness of your data using DAMON and call ``mlock()`` to keep your hot
data in DRAM, or call ``madvise()`` with ``MADV_PAGEOUT`` to proactively
reclaim cold data. Even though your program is guaranteed to not encounter
memory pressure, you can still improve the performance by applying the DAMON
outputs for call of ``MADV_HUGEPAGE`` and ``MADV_NOHUGEPAGE``. More creative
optimizations would be possible. Our evaluations of DAMON includes a
straightforward optimization using the ``mlock()``. Please refer to the below
Evaluation section for more detail.
As DAMON incurs very low overhead, such optimizations can be applied not only
offline, but also online. Also, there is no reason to limit such optimizations
to the user space. Several parts of the kernel's memory management mechanisms
could be also optimized using DAMON. The reclamation, the THP (de)promotion
decisions, and the compaction would be such a candidates. DAMON will continue
its development to be highly optimized for the online/in-kernel uses. We will
further automate the optimization for many usecases.
Appendix E: Evaluations
=======================
Setup
-----
On my personal QEMU/KVM based virtual machine on an Intel i7 host machine
running Ubuntu 18.04, I measure runtime and consumed system memory while
running various realistic workloads with several configurations. I use 13 and
12 workloads in PARSEC3[3] and SPLASH-2X[4] benchmark suites, respectively. I
personally use another wrapper scripts[5] for setup and run of the workloads.
On top of this patchset, we also applied the DAMON-based operation schemes
patchset[6] for this evaluation.
Measurement
~~~~~~~~~~~
For the measurement of the amount of consumed memory in system global scope, I
drop caches before starting each of the workloads and monitor 'MemFree' in the
'/proc/meminfo' file. To make results more stable, I repeat the runs 5 times
and average results. You can get stdev, min, and max of the numbers among the
repeated runs in appendix below.
Configurations
~~~~~~~~~~~~~~
The configurations I use are as below.
orig: Linux v5.5 with 'madvise' THP policy
rec: 'orig' plus DAMON running with record feature
thp: same with 'orig', but use 'always' THP policy
ethp: 'orig' plus a DAMON operation scheme[6], 'efficient THP'
prcl: 'orig' plus a DAMON operation scheme, 'proactive reclaim[7]'
I use 'rec' for measurement of DAMON overheads to target workloads and system
memory. The remaining configs including 'thp', 'ethp', and 'prcl' are for
measurement of DAMON monitoring accuracy.
'ethp' and 'prcl' is simple DAMON-based operation schemes developed for
proof of concepts of DAMON. 'ethp' reduces memory space waste of THP by using
DAMON for decision of promotions and demotion for huge pages, while 'prcl' is
as similar as the original work. Those are implemented as below:
# format: <min/max size> <min/max frequency (0-100)> <min/max age> <action>
# ethp: Use huge pages if a region >2MB shows >5% access rate, use regular
# pages if a region >2MB shows <5% access rate for >1 second
2M null 5 null null null hugepage
2M null null 5 1s null nohugepage
# prcl: If a region >4KB shows <5% access rate for >5 seconds, page out.
4K null null 5 500ms null pageout
Note that both 'ethp' and 'prcl' are designed with my only straightforward
intuition, because those are for only proof of concepts and monitoring accuracy
of DAMON. In other words, those are not for production. For production use,
those should be tuned more.
[1] "Redis latency problems troubleshooting", https://redis.io/topics/latency
[2] "Disable Transparent Huge Pages (THP)",
https://docs.mongodb.com/manual/tutorial/transparent-huge-pages/
[3] "The PARSEC Becnhmark Suite", https://parsec.cs.princeton.edu/index.htm
[4] "SPLASH-2x", https://parsec.cs.princeton.edu/parsec3-doc.htm#splash2x
[5] "parsec3_on_ubuntu", https://github.com/sjp38/parsec3_on_ubuntu
[6] "[RFC v4 0/7] Implement Data Access Monitoring-based Memory Operation
Schemes",
https://lore.kernel.org/linux-mm/[email protected]/
[7] "Proactively reclaiming idle memory", https://lwn.net/Articles/787611/
Results
-------
Below two tables show the measurement results. The runtimes are in seconds
while the memory usages are in KiB. Each configurations except 'orig' shows
its overhead relative to 'orig' in percent within parenthesises.
runtime orig rec (overhead) thp (overhead) ethp (overhead) prcl (overhead)
parsec3/blackscholes 107.065 107.478 (0.39) 106.682 (-0.36) 107.365 (0.28) 111.811 (4.43)
parsec3/bodytrack 79.256 79.450 (0.25) 78.645 (-0.77) 79.314 (0.07) 80.305 (1.32)
parsec3/canneal 139.497 141.181 (1.21) 121.526 (-12.88) 130.074 (-6.75) 154.644 (10.86)
parsec3/dedup 11.879 11.873 (-0.05) 11.693 (-1.56) 11.948 (0.58) 12.694 (6.86)
parsec3/facesim 207.814 208.467 (0.31) 203.743 (-1.96) 206.759 (-0.51) 214.603 (3.27)
parsec3/ferret 190.124 190.955 (0.44) 189.575 (-0.29) 190.852 (0.38) 191.548 (0.75)
parsec3/fluidanimate 211.046 212.282 (0.59) 208.832 (-1.05) 212.143 (0.52) 218.774 (3.66)
parsec3/freqmine 289.259 290.096 (0.29) 288.510 (-0.26) 290.177 (0.32) 296.269 (2.42)
parsec3/raytrace 118.522 119.701 (0.99) 119.469 (0.80) 118.964 (0.37) 130.584 (10.18)
parsec3/streamcluster 323.619 327.830 (1.30) 283.374 (-12.44) 287.837 (-11.06) 330.216 (2.04)
parsec3/swaptions 154.007 155.714 (1.11) 154.767 (0.49) 154.955 (0.62) 155.256 (0.81)
parsec3/vips 58.822 58.750 (-0.12) 58.564 (-0.44) 58.807 (-0.02) 60.320 (2.55)
parsec3/x264 67.335 72.516 (7.69) 64.680 (-3.94) 70.096 (4.10) 72.465 (7.62)
splash2x/barnes 80.335 80.979 (0.80) 73.758 (-8.19) 78.874 (-1.82) 99.226 (23.52)
splash2x/fft 33.441 33.312 (-0.38) 22.909 (-31.49) 31.561 (-5.62) 41.496 (24.09)
splash2x/lu_cb 85.691 85.706 (0.02) 84.352 (-1.56) 85.943 (0.29) 88.914 (3.76)
splash2x/lu_ncb 92.338 92.749 (0.45) 89.773 (-2.78) 92.888 (0.60) 94.104 (1.91)
splash2x/ocean_cp 44.542 44.795 (0.57) 42.958 (-3.56) 44.061 (-1.08) 49.091 (10.21)
splash2x/ocean_ncp 82.101 82.006 (-0.12) 51.418 (-37.37) 64.496 (-21.44) 105.998 (29.11)
splash2x/radiosity 91.296 91.353 (0.06) 90.668 (-0.69) 91.379 (0.09) 103.265 (13.11)
splash2x/radix 31.243 31.417 (0.56) 25.176 (-19.42) 30.297 (-3.03) 38.474 (23.14)
splash2x/raytrace 84.405 84.863 (0.54) 83.498 (-1.08) 83.637 (-0.91) 85.166 (0.90)
splash2x/volrend 87.516 88.156 (0.73) 86.311 (-1.38) 87.016 (-0.57) 88.318 (0.92)
splash2x/water_nsquared 233.515 233.826 (0.13) 221.169 (-5.29) 224.430 (-3.89) 236.929 (1.46)
splash2x/water_spatial 89.207 89.448 (0.27) 89.396 (0.21) 89.826 (0.69) 97.700 (9.52)
total 2993.890 3014.920 (0.70) 2851.460 (-4.76) 2923.710 (-2.34) 3158.180 (5.49)
memused.avg orig rec (overhead) thp (overhead) ethp (overhead) prcl (overhead)
parsec3/blackscholes 1819997.200 1832626.000 (0.69) 1821707.000 (0.09) 1830010.400 (0.55) 1651016.200 (-9.28)
parsec3/bodytrack 1416437.600 1430462.200 (0.99) 1420736.400 (0.30) 1428355.600 (0.84) 1430327.000 (0.98)
parsec3/canneal 1040414.400 1050736.800 (0.99) 1041515.600 (0.11) 1048562.200 (0.78) 1049049.400 (0.83)
parsec3/dedup 2414431.800 2454260.400 (1.65) 2423175.400 (0.36) 2396560.200 (-0.74) 2379898.200 (-1.43)
parsec3/facesim 540432.200 551410.200 (2.03) 545978.200 (1.03) 558558.400 (3.35) 483755.400 (-10.49)
parsec3/ferret 318728.600 333971.800 (4.78) 322158.200 (1.08) 332889.200 (4.44) 327896.400 (2.88)
parsec3/fluidanimate 576917.800 585126.600 (1.42) 575123.200 (-0.31) 585429.200 (1.48) 484810.600 (-15.97)
parsec3/freqmine 987882.200 997030.600 (0.93) 990429.200 (0.26) 998484.000 (1.07) 770740.200 (-21.98)
parsec3/raytrace 1747059.800 1752904.000 (0.33) 1738853.600 (-0.47) 1753948.600 (0.39) 1578118.000 (-9.67)
parsec3/streamcluster 121857.600 133934.400 (9.91) 121777.800 (-0.07) 133145.800 (9.26) 131512.800 (7.92)
parsec3/swaptions 14123.000 29254.400 (107.14) 14017.200 (-0.75) 26470.600 (87.43) 28429.800 (101.30)
parsec3/vips 2957631.800 2972884.400 (0.52) 2938855.400 (-0.63) 2960746.000 (0.11) 2946850.800 (-0.36)
parsec3/x264 3184777.200 3214527.400 (0.93) 3177061.000 (-0.24) 3192446.600 (0.24) 3185851.800 (0.03)
splash2x/barnes 1209737.200 1214763.200 (0.42) 1242138.400 (2.68) 1215857.600 (0.51) 994280.800 (-17.81)
splash2x/fft 9362799.400 9178844.600 (-1.96) 9264052.600 (-1.05) 9164996.600 (-2.11) 9452048.200 (0.95)
splash2x/lu_cb 515716.000 524071.600 (1.62) 521226.200 (1.07) 524261.400 (1.66) 372910.200 (-27.69)
splash2x/lu_ncb 512898.200 523057.600 (1.98) 520630.800 (1.51) 523779.000 (2.12) 446282.400 (-12.99)
splash2x/ocean_cp 3346038.000 3288703.600 (-1.71) 3386906.600 (1.22) 3330937.200 (-0.45) 3266442.400 (-2.38)
splash2x/ocean_ncp 3886945.600 3871894.000 (-0.39) 7066192.000 (81.79) 5065229.800 (30.31) 3652078.200 (-6.04)
splash2x/radiosity 1467107.200 1468850.800 (0.12) 1481292.600 (0.97) 1470335.800 (0.22) 530923.400 (-63.81)
splash2x/radix 1708330.800 1699792.200 (-0.50) 1352708.600 (-20.82) 1601339.200 (-6.26) 2043947.800 (19.65)
splash2x/raytrace 44817.200 59047.800 (31.75) 52010.200 (16.05) 60407.200 (34.79) 53916.400 (20.30)
splash2x/volrend 151534.200 167791.400 (10.73) 151759.000 (0.15) 165012.400 (8.89) 160864.600 (6.16)
splash2x/water_nsquared 46549.400 61846.800 (32.86) 51741.200 (11.15) 59214.400 (27.21) 91869.400 (97.36)
splash2x/water_spatial 669085.200 675929.200 (1.02) 665924.600 (-0.47) 676218.200 (1.07) 538430.200 (-19.53)
total 40062200.000 40073700.000 (0.03) 42888000.000 (7.05) 41103100.000 (2.60) 38052200.000 (-5.02)
DAMON Overheads
~~~~~~~~~~~~~~~
In total, DAMON recording feature incurs 0.70% runtime overhead and 0.03%
memory space overhead.
For convenience test run of 'rec', I use a Python wrapper. The wrapper
constantly consumes about 10-15MB of memory. This becomes high memory overhead
if the target workload has small memory footprint. Nonetheless, the overheads
are not from DAMON, but from the wrapper, and thus should be ignored. This
fake memory overhead continues in 'ethp' and 'prcl', as those configurations
are also using the Python wrapper.
Efficient THP
~~~~~~~~~~~~~
THP 'always' enabled policy achieves 4.76% speedup but incurs 7.05% memory
overhead. It achieves 37.37% speedup in best case, but 81.79% memory overhead
in worst case. Interestingly, both the best and worst case are with
'splash2x/ocean_ncp').
The 2-lines implementation of data access monitoring based THP version ('ethp')
shows 2.34% speedup and 2.60% memory overhead. In other words, 'ethp' removes
63.12% of THP memory waste while preserving 49.15% of THP speedup in total. In
case of the 'splash2x/ocean_ncp', 'ethp' removes 62.94% of THP memory waste
while preserving 57.37% of THP speedup.
Proactive Reclamation
~~~~~~~~~~~~~~~~~~~~
As same to the original work, I use 'zram' swap device for this configuration.
In total, our 1 line implementation of Proactive Reclamation, 'prcl', incurred
8.41% runtime overhead in total while achieving 5.83% system memory usage
reduction.
Nonetheless, as the memory usage is calculated with 'MemFree' in
'/proc/meminfo', it contains the SwapCached pages. As the swapcached pages can
be easily evicted, I also measured the residential set size of the workloads:
rss.avg orig rec (overhead) thp (overhead) ethp (overhead) prcl (overhead)
parsec3/blackscholes 591452.000 591466.400 (0.00) 593145.200 (0.29) 590609.400 (-0.14) 324379.000 (-45.16)
parsec3/bodytrack 32458.600 32352.200 (-0.33) 32218.400 (-0.74) 32376.400 (-0.25) 27186.000 (-16.24)
parsec3/canneal 841311.600 839888.400 (-0.17) 837008.400 (-0.51) 837811.000 (-0.42) 823276.200 (-2.14)
parsec3/dedup 1219096.600 1228038.800 (0.73) 1235610.800 (1.35) 1214267.000 (-0.40) 992031.000 (-18.63)
parsec3/facesim 311322.200 311574.400 (0.08) 316277.000 (1.59) 312593.800 (0.41) 188789.400 (-39.36)
parsec3/ferret 99536.600 99556.800 (0.02) 102366.000 (2.84) 99799.000 (0.26) 88392.000 (-11.20)
parsec3/fluidanimate 531893.600 531856.000 (-0.01) 532143.400 (0.05) 532190.200 (0.06) 421798.800 (-20.70)
parsec3/freqmine 553533.200 552730.400 (-0.15) 555642.600 (0.38) 553895.400 (0.07) 78335.000 (-85.85)
parsec3/raytrace 894094.200 894849.000 (0.08) 889964.000 (-0.46) 892865.000 (-0.14) 332911.800 (-62.77)
parsec3/streamcluster 110938.000 110968.200 (0.03) 111673.400 (0.66) 111312.200 (0.34) 109911.200 (-0.93)
parsec3/swaptions 5630.000 5634.800 (0.09) 5656.600 (0.47) 5692.000 (1.10) 4028.400 (-28.45)
parsec3/vips 32107.000 32045.200 (-0.19) 32207.800 (0.31) 32293.800 (0.58) 29093.600 (-9.39)
parsec3/x264 81926.000 82143.000 (0.26) 83258.400 (1.63) 82570.600 (0.79) 80651.800 (-1.56)
splash2x/barnes 1215468.800 1217889.800 (0.20) 1222006.800 (0.54) 1217425.600 (0.16) 752405.200 (-38.10)
splash2x/fft 9584734.800 9568872.800 (-0.17) 9660321.400 (0.79) 9646012.000 (0.64) 8367492.800 (-12.70)
splash2x/lu_cb 510555.400 510807.400 (0.05) 514448.600 (0.76) 509281.800 (-0.25) 349272.200 (-31.59)
splash2x/lu_ncb 510310.000 508915.600 (-0.27) 513886.000 (0.70) 510288.400 (-0.00) 431521.800 (-15.44)
splash2x/ocean_cp 3408724.400 3408424.600 (-0.01) 3446054.400 (1.10) 3419536.200 (0.32) 3173818.600 (-6.89)
splash2x/ocean_ncp 3923539.600 3922605.400 (-0.02) 7175526.600 (82.88) 5152558.800 (31.32) 3475756.000 (-11.41)
splash2x/radiosity 1476050.000 1475470.400 (-0.04) 1485747.000 (0.66) 1476232.600 (0.01) 269512.200 (-81.74)
splash2x/radix 1756385.400 1752676.000 (-0.21) 1431621.600 (-18.49) 1711460.800 (-2.56) 1923448.200 (9.51)
splash2x/raytrace 23286.400 23311.200 (0.11) 28440.800 (22.13) 26977.200 (15.85) 15685.200 (-32.64)
splash2x/volrend 44089.400 44125.600 (0.08) 44436.600 (0.79) 44250.400 (0.37) 27616.800 (-37.36)
splash2x/water_nsquared 29437.600 29403.200 (-0.12) 29817.400 (1.29) 30040.000 (2.05) 25369.600 (-13.82)
splash2x/water_spatial 656264.400 656566.400 (0.05) 656016.400 (-0.04) 656420.200 (0.02) 474480.400 (-27.70)
total 28444100.000 28432200.000 (-0.04) 31535300.000 (10.87) 29698900.000 (4.41) 22787200.000 (-19.89)
In total, 19.89% of residential sets were reduced.
With parsec3/freqmine, 'prcl' reduced 85.85% of residential sets and 21.98% of
system memory usage while incurring only 2.42% runtime overhead.
Appendix F: Prototype Evaluations
=================================
A prototype of DAMON has evaluated on an Intel Xeon E7-8837 machine using 20
benchmarks that picked from SPEC CPU 2006, NAS, Tensorflow Benchmark,
SPLASH-2X, and PARSEC 3 benchmark suite. Nonethless, this section provides
only summary of the results. For more detail, please refer to the slides used
for the introduction of DAMON at the Linux Plumbers Conference 2019[1] or the
MIDDLEWARE'19 industrial track paper[2].
[1] SeongJae Park, Tracing Data Access Pattern with Bounded Overhead and
Best-effort Accuracy. In The Linux Kernel Summit, September 2019.
https://linuxplumbersconf.org/event/4/contributions/548/
[2] SeongJae Park, Yunjae Lee, Heon Y. Yeom, Profiling Dynamic Data Access
Patterns with Controlled Overhead and Quality. In 20th ACM/IFIP
International Middleware Conference Industry, December 2019.
https://dl.acm.org/doi/10.1145/3366626.3368125
Quality
-------
We first traced and visualized the data access pattern of each workload. We
were able to confirm that the visualized results are reasonably accurate by
manually comparing those with the source code of the workloads.
To see the usefulness of the monitoring, we optimized 9 memory intensive
workloads among them for memory pressure situations using the DAMON outputs.
In detail, we identified frequently accessed memory regions in each workload
based on the DAMON results and protected them with ``mlock()`` system calls by
manually modifying the source code. The optimized versions consistently show
speedup (2.55x in best case, 1.65x in average) under artificial memory
pressures. We use cgroups for the pressure.
Overhead
--------
We also measured the overhead of DAMON. The upperbound we set was kept as
expected. Besides, it was much lower (0.6 percent of the bound in best case,
13.288 percent of the bound in average). This reduction of the overhead is
mainly resulted from its core mechanism called adaptive regions adjustment.
Refer to 'Appendix D' for more detail about the mechanism. We also compared
the overhead of DAMON with that of a straightforward periodic PTE Accessed bit
checking based monitoring. DAMON's overhead was smaller than it by 94,242.42x
in best case, 3,159.61x in average.
The latest version of DAMON running with its default configuration consumes
only up to 1% of CPU time when applied to realistic workloads in PARSEC3 and
SPLASH-2X and makes no visible slowdown to the target processes.PATCH v11 1/16 scripts/spelling: Add a few more typos
From: SeongJae Park <[email protected]>
This commit adds typos found from DAMON patchset.
--- scripts/spelling.txt | 8 ++++++++ 1 file changed, 8 insertions(+)
scripts/spelling.txt +8 -0
@@ -59,6 +59,7 @@ actualy||actually acumulating||accumulating acumulative||accumulative acumulator||accumulator +acutally||actually adapater||adapter addional||additional additionaly||additionally
@@ -245,6 +246,7 @@ calescing||coalescing calle||called callibration||calibration callled||called +callser||caller calucate||calculate calulate||calculate cancelation||cancellation
@@ -664,6 +666,7 @@ hanlde||handle hanled||handled happend||happened harware||hardware +havind||having heirarchically||hierarchically helpfull||helpful hexdecimal||hexadecimal
@@ -835,6 +838,7 @@ logile||logfile loobpack||loopback loosing||losing losted||lost +maangement||management machinary||machinery maibox||mailbox maintainance||maintenance
@@ -999,6 +1003,7 @@ partiton||partition pased||passed passin||passing pathes||paths +pattrns||patterns pecularities||peculiarities peformance||performance peforming||performing
@@ -1238,6 +1243,7 @@ shoule||should shrinked||shrunk siginificantly||significantly signabl||signal +significanly||significantly similary||similarly similiar||similar simlar||similar
@@ -1352,6 +1358,7 @@ thead||thread therfore||therefore thier||their threds||threads +threee||three threshhold||threshold thresold||threshold throught||through
@@ -1391,6 +1398,7 @@ tyep||type udpate||update uesd||used uknown||unknown +usccess||success usupported||unsupported uncommited||uncommitted unconditionaly||unconditionally
Signature · 1 line
2.17.1
PATCH v11 2/16 mm/page_ext: Export lookup_page_ext() to GPL modules
In reply to SeongJae ParkFrom: SeongJae Park <[email protected]>
This commit exports 'lookup_page_ext()' to GPL modules. This will be used by DAMON.
--- mm/page_ext.c | 1 + 1 file changed, 1 insertion(+)
mm/page_ext.c +1 -0
@@ -131,6 +131,7 @@ struct page_ext *lookup_page_ext(const struct page *page) MAX_ORDER_NR_PAGES);return get_entry (base, index); } +EXPORT_SYMBOL_GPL (lookup_page_ext);static int __init alloc_node_page_ext (int nid) {
Signature · 1 line
2.17.1
PATCH v11 3/16 mm: Introduce Data Access MONitor (DAMON)
In reply to SeongJae ParkFrom: SeongJae Park <[email protected]>
This commit introduces a kernel module named DAMON. Note that this commit is implementing only the stub for the module load/unload, basic data structures, and simple manipulation functions of the structures to keep the size of commit small. The core mechanisms of DAMON will be implemented one by one by following commits.
--- include/linux/damon.h | 36 +++++++++ mm/Kconfig | 12 +++ mm/Makefile | 1 + mm/damon.c | 173 ++++++++++++++++++++++++++++++++++++++++++ 4 files changed, 222 insertions(+) create mode 100644 include/linux/damon.h create mode 100644 mm/damon.c
include/linux/damon.h new file +36 -0
@@ -0,0 +1,36 @@ +/* SPDX-License-Identifier: GPL-2.0 */ +/* +* DAMON api +* +* Copyright 2019-2020 Amazon.com, Inc. or its affiliates. +* +* Author: SeongJae Park <[email protected]> +*/ + +#ifndef _DAMON_H_ +#define _DAMON_H_ + +#include <linux/random.h> +#include <linux/types.h> + +/* Represents a monitoring target region of [vm_start, vm_end) */ +struct damon_region { +unsigned long vm_start; +unsigned long vm_end; +unsigned long sampling_addr; +unsigned int nr_accesses; +struct list_head list; +}; + +/* Represents a monitoring target task */ +struct damon_task { +int pid; +struct list_head regions_list; +struct list_head list; +}; + +struct damon_ctx { +struct list_head tasks_list;/* 'damon_task' objects */ +}; + +#endif
mm/Kconfig +12 -0
@@ -739,4 +739,16 @@ config ARCH_HAS_HUGEPD config MAPPING_DIRTY_HELPERS bool +config DAMON + tristate "Data Access Monitor" + depends on MMU + help + Provides data access monitoring. + + DAMON is a kernel module that allows users to monitor the actual + memory access pattern of specific user-space processes. It aims to + be 1) accurate enough to be useful for performance-centric domains, + and 2) sufficiently light-weight so that it can be applied online. + If unsure, say N. + endmenu
mm/Makefile +1 -0
@@ -110,3 +110,4 @@ obj-$(CONFIG_HMM_MIRROR) += hmm.o obj-$(CONFIG_MEMFD_CREATE) += memfd.o obj-$(CONFIG_MAPPING_DIRTY_HELPERS) += mapping_dirty_helpers.o obj-$(CONFIG_PTDUMP_CORE) += ptdump.o +obj-$(CONFIG_DAMON) += damon.o
mm/damon.c new file +173 -0
173 lines not on this page · raw message
Signature · 1 line
2.17.1
PATCH v11 4/16 mm/damon: Implement region based sampling
In reply to SeongJae ParkFrom: SeongJae Park <[email protected]>
This commit implements DAMON's basic access check and region based sampling mechanisms. This change would seems make no sense, mainly because it is only a part of the DAMON's logics. Following two commits will make more sense.
Basic Access Check
------------------
DAMON basically reports what pages are how frequently accessed. Note that the frequency is not an absolute number of accesses, but a relative frequency among the pages of the target workloads.
Users can control the resolution of the reports by setting two time intervals, ``sampling interval`` and ``aggregation interval``. In detail, DAMON checks access to each page per ``sampling interval``, aggregates the results (counts the number of the accesses to each page), and reports the aggregated results per ``aggregation interval``. For the access check of each page, DAMON uses the Accessed bits of PTEs.
This is thus similar to common periodic access checks based access tracking mechanisms, which overhead is increasing as the size of the target process grows.
Region Based Sampling
---------------------
To avoid the unbounded increase of the overhead, DAMON groups a number of adjacent pages that assumed to have same access frequencies into a region. As long as the assumption (pages in a region have 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 and clears its Accessed bit. After one more ``sampling interval``, DAMON reads the Accessed bit of the page and increases the access frequency of the region if the bit has set meanwhile. Therefore, the monitoring overhead is controllable by setting the number of regions.
Nonetheless, this scheme cannot preserve the quality of the output if the assumption is not kept. Following commit will introduce how we can make the guarantee with best effort.
--- include/linux/damon.h | 25 ++ mm/damon.c | 597 ++++++++++++++++++++++++++++++++++++++++++ 2 files changed, 622 insertions(+)
include/linux/damon.h +25 -0
@@ -11,6 +11,8 @@#define _DAMON_H_#include <linux/random.h> +#include <linux/mutex.h> +#include <linux/time64.h> #include <linux/types.h> /* Represents a monitoring target region of [vm_start, vm_end) */
@@ -29,8 +31,31 @@ struct damon_task { struct list_head list; }; +/* +* For each 'sample_interval', DAMON checks whether each region is accessed or +* not. It aggregates and keeps the access information (number of accesses to +* each region) for each 'aggr_interval' time. +* +* All time intervals are in micro-seconds. +*/ struct damon_ctx { +unsigned long sample_interval; +unsigned long aggr_interval; +unsigned long min_nr_regions; + +struct timespec64 last_aggregation; + +struct task_struct *kdamond; +bool kdamond_stop; +struct mutex kdamond_lock; +struct list_head tasks_list;/* 'damon_task' objects */ }; +int damon_set_pids (struct damon_ctx *ctx,int *pids,ssize_t nr_pids); +int damon_set_attrs (struct damon_ctx *ctx,unsigned long sample_int, +unsigned long aggr_int,unsigned long min_nr_reg); +int damon_start (struct damon_ctx *ctx); +int damon_stop (struct damon_ctx *ctx); +#endif
mm/damon.c +597 -0
613 lines not on this page · raw message
Signature · 1 line
2.17.1
PATCH v11 5/16 mm/damon: Adaptively adjust regions
In reply to SeongJae ParkFrom: SeongJae Park <[email protected]>
At the beginning of the monitoring, DAMON constructs the initial regions by evenly splitting the memory mapped address space of the process into the user-specified minimal number of regions. In this initial state, the assumption of the regions (pages in same region have similar access frequencies) is normally not kept and thus the monitoring quality could be low. To keep the assumption as much as possible, DAMON adaptively merges and splits each region.
For each ``aggregation interval``, it compares the access frequencies of adjacent regions and merges those if the frequency difference is small. Then, after it reports and clears the aggregated access frequency of each region, it splits each region into two regions if the total number of regions is smaller than the half of the user-specified maximum number of regions.
In this way, DAMON provides its best-effort quality and minimal overhead while keeping the bounds users set for their trade-off.
--- include/linux/damon.h | 6 +- mm/damon.c | 158 +++++++++++++++++++++++++++++++++++++++--- 2 files changed, 152 insertions(+), 12 deletions(-)
include/linux/damon.h +4 -2
@@ -42,6 +42,7 @@ struct damon_ctx {unsigned long sample_interval;unsigned long aggr_interval;unsigned long min_nr_regions; +unsigned long max_nr_regions;struct timespec64 last_aggregation;
@@ -53,8 +54,9 @@ struct damon_ctx { };int damon_set_pids (struct damon_ctx *ctx,int *pids,ssize_t nr_pids); -int damon_set_attrs (struct damon_ctx *ctx,unsigned long sample_int, -unsigned long aggr_int,unsigned long min_nr_reg); +int damon_set_attrs (struct damon_ctx *ctx, +unsigned long sample_int,unsigned long aggr_int, +unsigned long min_nr_reg,unsigned long max_nr_reg);int damon_start (struct damon_ctx *ctx);int damon_stop (struct damon_ctx *ctx);
mm/damon.c +148 -10
224 lines not on this page · raw message
Signature · 1 line
2.17.1
PATCH v11 6/16 mm/damon: Split regions into 3 subregions if necessary
In reply to SeongJae ParkFrom: SeongJae Park <[email protected]>
Suppose that there are a very wide and cold region and a hot region, and both regions are identified by DAMON. And then, the middle small region inside the very wide and cold region becomes hot. DAMON will not be able to identify this new region because the adaptive regions adjustment mechanism splits each region to only two subregions.
This commit modifies the logic to split each region to 3 subregions if such corner case is detected.
--- mm/damon.c | 51 ++++++++++++++++++++++++++++++++++----------------- 1 file changed, 34 insertions(+), 17 deletions(-)
mm/damon.c +34 -17
@@ -650,26 +650,32 @@ static void damon_split_region_at(struct damon_ctx *ctx,damon_insert_region (new, r,damon_next_region (r)); } -/* Split every region in the given task into two randomly-sized regions */ -static void damon_split_regions_of (struct damon_ctx *ctx,struct damon_task *t) +/* Split every region in the given task into 'nr_subs' regions */ +static void damon_split_regions_of (struct damon_ctx *ctx, +struct damon_task *t,int nr_subs) {struct damon_region *r, *next; -unsigned long sz_orig_region, sz_left_region; +unsigned long sz_region, sz_sub =0 ; +int i;damon_for_each_region_safe (r, next, t) { - sz_orig_region = r->vm_end - r->vm_start; - -/* -* Randomly select size of left sub-region to be at least -* 10 percent and at most 90% of original region -*/ - sz_left_region =ALIGN_DOWN (damon_rand (1 ,10 ) * sz_orig_region - /10 ,MIN_REGION ); -/* Do not allow blank region */ -if (sz_left_region ==0 || sz_left_region >= sz_orig_region) -continue ; - -damon_split_region_at (ctx, r, sz_left_region); + sz_region = r->vm_end - r->vm_start; + +for (i =0 ; i < nr_subs -1 && + sz_region >2 *MIN_REGION ; i++) { +/* +* Randomly select size of left sub-region to be at +* least 10 percent and at most 90% of original region +*/ + sz_sub =ALIGN_DOWN (damon_rand (1 ,10 ) * + sz_region /10 ,MIN_REGION ); +/* Do not allow blank region */ +if (sz_sub ==0 || sz_sub >= sz_region) +continue ; + +damon_split_region_at (ctx, r, sz_sub); + sz_region = sz_sub; + } } }
@@ -687,14 +693,25 @@ static void kdamond_split_regions(struct damon_ctx *ctx) {struct damon_task *t;unsigned int nr_regions =0 ; +static unsigned int last_nr_regions; +int nr_subregions =2 ;damon_for_each_task (ctx, t) nr_regions +=nr_damon_regions (t); +if (nr_regions > ctx->max_nr_regions /2 )return ; +/* If number of regions is not changed, we are maybe in corner case */ +if (last_nr_regions == nr_regions && + nr_regions < ctx->max_nr_regions /3 ) + nr_subregions =3 ; +damon_for_each_task (ctx, t) -damon_split_regions_of (ctx, t); +damon_split_regions_of (ctx, t, nr_subregions); + +if (!last_nr_regions) + last_nr_regions = nr_regions; }/*
Signature · 1 line
2.17.1
PATCH v11 7/16 mm/damon: Apply dynamic memory mapping changes
In reply to SeongJae ParkFrom: SeongJae Park <[email protected]>
Only a number of parts in the virtual address space of the processes is mapped to physical memory and accessed. Thus, tracking the unmapped address regions is just wasteful. However, tracking every memory mapping change might incur an overhead. For the reason, DAMON applies the dynamic memory mapping changes to the tracking regions only for each of a user-specified time interval (``regions update interval``).
--- include/linux/damon.h | 10 +++-- mm/damon.c | 101 +++++++++++++++++++++++++++++++++++++++++- 2 files changed, 106 insertions(+), 5 deletions(-)
include/linux/damon.h +7 -3
@@ -34,17 +34,21 @@ struct damon_task {/* * For each 'sample_interval', DAMON checks whether each region is accessed or * not. It aggregates and keeps the access information (number of accesses to -* each region) for each 'aggr_interval' time. +* each region) for 'aggr_interval' time. DAMON also checks whether the memory +* mapping of the target tasks has changed (e.g., by mmap() calls from the +* application) and applies the changes for each 'regions_update_interval'. * * All time intervals are in micro-seconds. */ struct damon_ctx {unsigned long sample_interval;unsigned long aggr_interval; +unsigned long regions_update_interval;unsigned long min_nr_regions;unsigned long max_nr_regions;struct timespec64 last_aggregation; +struct timespec64 last_regions_update;struct task_struct *kdamond;bool kdamond_stop;
@@ -54,8 +58,8 @@ struct damon_ctx { };int damon_set_pids (struct damon_ctx *ctx,int *pids,ssize_t nr_pids); -int damon_set_attrs (struct damon_ctx *ctx, -unsigned long sample_int,unsigned long aggr_int, +int damon_set_attrs (struct damon_ctx *ctx,unsigned long sample_int, +unsigned long aggr_int,unsigned long regions_update_int,unsigned long min_nr_reg,unsigned long max_nr_reg);int damon_start (struct damon_ctx *ctx);int damon_stop (struct damon_ctx *ctx);
mm/damon.c +99 -2
131 lines not on this page · raw message
Signature · 1 line
2.17.1
PATCH v11 8/16 mm/damon: Implement callbacks
In reply to SeongJae ParkFrom: SeongJae Park <[email protected]>
This commit implements callbacks for DAMON. Using this, DAMON users can install their callbacks for each step of the access monitoring so that they can do something interesting with the monitored access patterns online. For example, callbacks can report the monitored patterns to users or do some access pattern based memory management such as proactive reclamations or access pattern based THP promotions/demotions decision makings.
--- include/linux/damon.h | 4 ++++ mm/damon.c | 4 ++++ 2 files changed, 8 insertions(+)
include/linux/damon.h +4 -0
@@ -55,6 +55,10 @@ struct damon_ctx {struct mutex kdamond_lock;struct list_head tasks_list;/* 'damon_task' objects */ + +/* callbacks */ +void (*sample_cb)(struct damon_ctx *context); +void (*aggregate_cb)(struct damon_ctx *context); };int damon_set_pids (struct damon_ctx *ctx,int *pids,ssize_t nr_pids);
mm/damon.c +4 -0
@@ -851,6 +851,8 @@ static int kdamond_fn(void *data)kdamond_init_regions (ctx);while (!kdamond_need_stop (ctx)) {kdamond_prepare_access_checks (ctx); +if (ctx->sample_cb) + ctx->sample_cb (ctx);usleep_range (ctx->sample_interval, ctx->sample_interval +1 );
@@ -858,6 +860,8 @@ static int kdamond_fn(void *data)if (kdamond_aggregate_interval_passed (ctx)) {kdamond_merge_regions (ctx, max_nr_accesses /10 ); +if (ctx->aggregate_cb) + ctx->aggregate_cb (ctx);kdamond_reset_aggregated (ctx);kdamond_split_regions (ctx); }
Signature · 1 line
2.17.1
PATCH v11 9/16 mm/damon: Implement access pattern recording
In reply to SeongJae ParkFrom: SeongJae Park <[email protected]>
This commit implements the recording feature of DAMON. If this feature is enabled, DAMON writes the monitored access patterns in its binary format into a file which specified by the user. This is already able to be implemented by each user using the callbacks. However, as the recording is expected to be used widely, this commit implements the feature in the DAMON, for more convenience and efficiency.
--- include/linux/damon.h | 7 +++ mm/damon.c | 131 +++++++++++++++++++++++++++++++++++++++++- 2 files changed, 135 insertions(+), 3 deletions(-)
include/linux/damon.h +7 -0
@@ -50,6 +50,11 @@ struct damon_ctx {struct timespec64 last_aggregation;struct timespec64 last_regions_update; +unsigned char *rbuf; +unsigned int rbuf_len; +unsigned int rbuf_offset; +char *rfile_path; +struct task_struct *kdamond;bool kdamond_stop;struct mutex kdamond_lock;
@@ -65,6 +70,8 @@ int damon_set_pids(struct damon_ctx *ctx, int *pids, ssize_t nr_pids);int damon_set_attrs (struct damon_ctx *ctx,unsigned long sample_int,unsigned long aggr_int,unsigned long regions_update_int,unsigned long min_nr_reg,unsigned long max_nr_reg); +int damon_set_recording (struct damon_ctx *ctx, +unsigned int rbuf_len,char *rfile_path);int damon_start (struct damon_ctx *ctx);int damon_stop (struct damon_ctx *ctx);
mm/damon.c +128 -3
174 lines not on this page · raw message
Signature · 1 line
2.17.1
PATCH v11 10/16 mm/damon: Add debugfs interface
In reply to SeongJae ParkFrom: SeongJae Park <[email protected]>
This commit adds a debugfs interface for DAMON.
DAMON exports four files, ``attrs``, ``pids``, ``record``, and ``monitor_on`` under its debugfs directory, ``<debugfs>/damon/``.
Attributes
----------
Users can read and write the ``sampling interval``, ``aggregation interval``, ``regions update interval``, and min/max number of monitoring target regions by reading from and writing to the ``attrs`` file. For example, below commands set those values to 5 ms, 100 ms, 1,000 ms, 10, 1000 and check it again::
# cd <debugfs>/damon
# echo 5000 100000 1000000 10 1000 > attrs
# cat attrs
5000 100000 1000000 10 1000Target PIDs
-----------
Users can read and write the pids of current monitoring target processes by reading from and writing to the ``pids`` file. For example, below commands set processes having pids 42 and 4242 as the processes to be monitored and check it again::
# cd <debugfs>/damon
# echo 42 4242 > pids
# cat pids
42 4242Note that setting the pids doesn't start the monitoring.
Record
------
DAMON supports direct monitoring result record feature. The recorded results are first written to a buffer and flushed to a file in batch. Users can set the size of the buffer and the path to the result file by reading from and writing to the ``record`` file. For example, below commands set the buffer to be 4 KiB and the result to be saved in '/damon.data'.
# cd <debugfs>/damon
# echo 4096 /damon.data > pids
# cat record
4096 /damon.dataTurning On/Off
--------------
You can check current status, start and stop the monitoring by reading from and writing to the ``monitor_on`` file. Writing ``on`` to the file starts DAMON to monitor the target processes with the attributes. Writing ``off`` to the file stops DAMON. DAMON also stops if every target processes is terminated. Below example commands turn on, off, and check status of DAMON::
# cd <debugfs>/damon
# echo on > monitor_on
# echo off > monitor_on
# cat monitor_on
offPlease note that you cannot write to the ``attrs`` and ``pids`` files while the monitoring is turned on. If you write to the files while DAMON is running, ``-EINVAL`` will be returned.
--- mm/damon.c | 351 ++++++++++++++++++++++++++++++++++++++++++++++++++++- 1 file changed, 350 insertions(+), 1 deletion(-)
mm/damon.c +350 -1
@@ -10,6 +10,7 @@#define pr_fmt (fmt) "damon: " fmt#include <linux/damon.h> +#include <linux/debugfs.h> #include <linux/delay.h> #include <linux/kthread.h> #include <linux/mm.h>
@@ -50,6 +51,15 @@/* Get a random number in [l, r) */ #define damon_rand (l, r) (l + prandom_u32() % (r - l)) +/* A monitoring context for debugfs interface users. */ +static struct damon_ctx damon_user_ctx = { + .sample_interval =5 *1000 , + .aggr_interval =100 *1000 , + .regions_update_interval =1000 *1000 , + .min_nr_regions =10 , + .max_nr_regions =1000 , +}; +/* * Construct a damon_region struct *
@@ -1134,13 +1144,352 @@ int damon_set_attrs(struct damon_ctx *ctx, unsigned long sample_int,return 0 ; } -static int __init damon_init (void ) +static ssize_t debugfs_monitor_on_read (struct file *file, +char __user *buf,size_t count,loff_t *ppos) +{ +struct damon_ctx *ctx = &damon_user_ctx; +char monitor_on_buf[5 ]; +bool monitor_on; +int len; + + monitor_on =damon_kdamond_running (ctx); + len =snprintf (monitor_on_buf,5 , monitor_on ?"on\n" :"off\n" ); + +return simple_read_from_buffer (buf, count, ppos, monitor_on_buf, len); +} + +static ssize_t debugfs_monitor_on_write (struct file *file, +const char __user *buf,size_t count,loff_t *ppos) +{ +struct damon_ctx *ctx = &damon_user_ctx; +ssize_t ret; +char cmdbuf[5 ]; +int err; + + ret =simple_write_to_buffer (cmdbuf,5 , ppos, buf, count); +if (ret <0 ) +return ret; + +if (sscanf (cmdbuf,"%s" , cmdbuf) !=1 ) +return -EINVAL ; +if (!strncmp (cmdbuf,"on" ,5 )) + err =damon_start (ctx); +else if (!strncmp (cmdbuf,"off" ,5 )) + err =damon_stop (ctx); +else +return -EINVAL ; + +if (err) + ret = err; +return ret; +} + +static ssize_t damon_sprint_pids (struct damon_ctx *ctx,char *buf,ssize_t len) +{ +struct damon_task *t; +int written =0 ; +int rc; + +damon_for_each_task (ctx, t) { + rc =snprintf (&buf[written], len - written,"%d " , t->pid); +if (!rc) +return -ENOMEM ; + written += rc; + } +if (written) + written -=1 ; + written +=snprintf (&buf[written], len - written,"\n" ); +return written; +} + +static ssize_t debugfs_pids_read (struct file *file, +char __user *buf,size_t count,loff_t *ppos) +{ +struct damon_ctx *ctx = &damon_user_ctx; +ssize_t len; +char pids_buf[320 ]; + + len =damon_sprint_pids (ctx, pids_buf,320 ); +if (len <0 ) +return len; + +return simple_read_from_buffer (buf, count, ppos, pids_buf, len); +} + +/* +* Converts a string into an array of unsigned long integers +* +* Returns an array of unsigned long integers if the conversion success, or +* NULL otherwise. +*/ +static int *str_to_pids (const char *str,ssize_t len,ssize_t *nr_pids) +{ +int *pids; +const int max_nr_pids =32 ; +int pid; +int pos =0 , parsed, ret; + + *nr_pids =0 ; + pids =kmalloc_array (max_nr_pids,sizeof (pid),GFP_KERNEL ); +if (!pids) +return NULL ; +while (*nr_pids < max_nr_pids && pos < len) { + ret =sscanf (&str[pos],"%d%n" , &pid, &parsed); + pos += parsed; +if (ret !=1 ) +break ; + pids[*nr_pids] = pid; + *nr_pids +=1 ; + } +if (*nr_pids ==0 ) { +kfree (pids); + pids =NULL ; + } + +return pids; +} + +static ssize_t debugfs_pids_write (struct file *file, +const char __user *buf,size_t count,loff_t *ppos) +{ +struct damon_ctx *ctx = &damon_user_ctx; +char *kbuf; +int *targets; +ssize_t nr_targets; +ssize_t ret; +int err; + + kbuf =kmalloc (count,GFP_KERNEL ); +if (!kbuf) +return -ENOMEM ; + + ret =simple_write_to_buffer (kbuf, count, ppos, buf, count); +if (ret <0 ) + goto out; + + targets =str_to_pids (kbuf, ret, &nr_targets); +if (!targets) { + ret = -ENOMEM ; + goto out; + } + +mutex_lock (&ctx->kdamond_lock); +if (ctx->kdamond) { + ret = -EINVAL ; + goto unlock_out; + } + + err =damon_set_pids (ctx, targets, nr_targets); +if (err) + ret = err; +unlock_out: +mutex_unlock (&ctx->kdamond_lock); +kfree (targets); +out: +kfree (kbuf); +return ret; +} + +static ssize_t debugfs_record_read (struct file *file, +char __user *buf,size_t count,loff_t *ppos) +{ +struct damon_ctx *ctx = &damon_user_ctx; +char record_buf[20 +MAX_RFILE_PATH_LEN ]; +int ret; + + ret =snprintf (record_buf,ARRAY_SIZE (record_buf),"%u %s\n" , + ctx->rbuf_len, ctx->rfile_path); +return simple_read_from_buffer (buf, count, ppos, record_buf, ret); +} + +static ssize_t debugfs_record_write (struct file *file, +const char __user *buf,size_t count,loff_t *ppos) { +struct damon_ctx *ctx = &damon_user_ctx; +char *kbuf; +unsigned int rbuf_len; +char rfile_path[MAX_RFILE_PATH_LEN ]; +ssize_t ret; +int err; + + kbuf =kmalloc (count +1 ,GFP_KERNEL ); +if (!kbuf) +return -ENOMEM ; + kbuf[count] ='\0' ; + + ret =simple_write_to_buffer (kbuf, count, ppos, buf, count); +if (ret <0 ) + goto out; +if (sscanf (kbuf,"%u %s" , + &rbuf_len, rfile_path) !=2 ) { + ret = -EINVAL ; + goto out; + } + +mutex_lock (&ctx->kdamond_lock); +if (ctx->kdamond) { + ret = -EBUSY ; + goto unlock_out; + } + + err =damon_set_recording (ctx, rbuf_len, rfile_path); +if (err) + ret = err; +unlock_out: +mutex_unlock (&ctx->kdamond_lock); +out: +kfree (kbuf); +return ret; +} + + +static ssize_t debugfs_attrs_read (struct file *file, +char __user *buf,size_t count,loff_t *ppos) +{ +struct damon_ctx *ctx = &damon_user_ctx; +char kbuf[128 ]; +int ret; + + ret =snprintf (kbuf,ARRAY_SIZE (kbuf),"%lu %lu %lu %lu %lu\n" , + ctx->sample_interval, ctx->aggr_interval, + ctx->regions_update_interval, ctx->min_nr_regions, + ctx->max_nr_regions); + +return simple_read_from_buffer (buf, count, ppos, kbuf, ret); +} + +static ssize_t debugfs_attrs_write (struct file *file, +const char __user *buf,size_t count,loff_t *ppos) +{ +struct damon_ctx *ctx = &damon_user_ctx; +unsigned long s, a, r, minr, maxr; +char *kbuf; +ssize_t ret; +int err; + + kbuf =kmalloc (count,GFP_KERNEL ); +if (!kbuf) +return -ENOMEM ; + + ret =simple_write_to_buffer (kbuf, count, ppos, buf, count); +if (ret <0 ) + goto out; + +if (sscanf (kbuf,"%lu %lu %lu %lu %lu" , + &s, &a, &r, &minr, &maxr) !=5 ) { + ret = -EINVAL ; + goto out; + } + +mutex_lock (&ctx->kdamond_lock); +if (ctx->kdamond) { + ret = -EBUSY ; + goto unlock_out; + } + + err =damon_set_attrs (ctx, s, a, r, minr, maxr); +if (err) + ret = err; +unlock_out: +mutex_unlock (&ctx->kdamond_lock); +out: +kfree (kbuf); +return ret; +} + +static const struct file_operations monitor_on_fops = { + .owner =THIS_MODULE , + .read = debugfs_monitor_on_read, + .write = debugfs_monitor_on_write, +}; + +static const struct file_operations pids_fops = { + .owner =THIS_MODULE , + .read = debugfs_pids_read, + .write = debugfs_pids_write, +}; + +static const struct file_operations record_fops = { + .owner =THIS_MODULE , + .read = debugfs_record_read, + .write = debugfs_record_write, +}; + +static const struct file_operations attrs_fops = { + .owner =THIS_MODULE , + .read = debugfs_attrs_read, + .write = debugfs_attrs_write, +}; + +static struct dentry *debugfs_root; + +static int __init damon_debugfs_init (void ) +{ +const char *const file_names[] = {"attrs" ,"record" , +"pids" ,"monitor_on" }; +const struct file_operations *fops[] = {&attrs_fops, &record_fops, + &pids_fops, &monitor_on_fops}; +int i; + + debugfs_root =debugfs_create_dir ("damon" ,NULL ); +if (!debugfs_root) { +pr_err ("failed to create the debugfs dir\n" ); +return -ENOMEM ; + } + +for (i =0 ; i <ARRAY_SIZE (file_names); i++) { +if (!debugfs_create_file (file_names[i],0600 , debugfs_root, +NULL , fops[i])) { +pr_err ("failed to create %s file\n" , file_names[i]); +return -ENOMEM ; + } + } +return 0 ; } +static int __init damon_init_user_ctx (void ) +{ +int rc; + +struct damon_ctx *ctx = &damon_user_ctx; + +ktime_get_coarse_ts64 (&ctx->last_aggregation); + ctx->last_regions_update = ctx->last_aggregation; + + rc =damon_set_recording (ctx,1024 *1024 ,"/damon.data" ); +if (rc) +return rc; + +mutex_init (&ctx->kdamond_lock); + +INIT_LIST_HEAD (&ctx->tasks_list); + +return 0 ; +} + +static int __init damon_init (void ) +{ +int rc; + + rc =damon_init_user_ctx (); +if (rc) +return rc; + + rc =damon_debugfs_init (); +if (rc) +pr_err ("%s: debugfs init failed\n" , __func__); + +return rc; +} + static void __exit damon_exit(void) { +damon_stop (&damon_user_ctx); +debugfs_remove_recursive (debugfs_root); + +kfree (damon_user_ctx.rbuf); +kfree (damon_user_ctx.rfile_path); }module_init (damon_init);
Signature · 1 line
2.17.1
PATCH v11 11/16 mm/damon: Add tracepoints
In reply to SeongJae ParkFrom: SeongJae Park <[email protected]>
This commit adds a tracepoint for DAMON. It traces the monitoring results of each region for each aggregation interval. Using this, DAMON will be easily integrated with any tracepoints supporting tools such as perf.
--- include/trace/events/damon.h | 43 ++++++++++++++++++++++++++++++++++++ mm/damon.c | 5 +++++ 2 files changed, 48 insertions(+) create mode 100644 include/trace/events/damon.h
include/trace/events/damon.h new file +43 -0
@@ -0,0 +1,43 @@ +/* SPDX-License-Identifier: GPL-2.0 */ +#undef TRACE_SYSTEM +#define TRACE_SYSTEM damon + +#if !defined(_TRACE_DAMON_H) || defined(TRACE_HEADER_MULTI_READ ) +#define _TRACE_DAMON_H + +#include <linux/types.h> +#include <linux/tracepoint.h> + +TRACE_EVENT (damon_aggregated, + + TP_PROTO(int pid, unsigned int nr_regions, + unsigned long vm_start, unsigned long vm_end, + unsigned int nr_accesses), + +TP_ARGS (pid, nr_regions, vm_start, vm_end, nr_accesses), + +TP_STRUCT__entry ( + __field(int, pid) + __field(unsigned int, nr_regions) + __field(unsigned long, vm_start) + __field(unsigned long, vm_end) + __field(unsigned int, nr_accesses) + ), + +TP_fast_assign ( + __entry->pid = pid; + __entry->nr_regions = nr_regions; + __entry->vm_start = vm_start; + __entry->vm_end = vm_end; + __entry->nr_accesses = nr_accesses; + ), + +TP_printk ("pid=%d nr_regions=%u %lu-%lu: %u" , __entry->pid, + __entry->nr_regions, __entry->vm_start, + __entry->vm_end, __entry->nr_accesses) +); + +#endif /* _TRACE_DAMON_H */ + +/* This part must be outside protection */ +#include <trace/define_trace.h>
mm/damon.c +5 -0
@@ -9,6 +9,8 @@#define pr_fmt (fmt) "damon: " fmt +#define CREATE_TRACE_POINTS +#include <linux/damon.h> #include <linux/debugfs.h> #include <linux/delay.h>
@@ -20,6 +22,7 @@#include <linux/sched/mm.h> #include <linux/sched/task.h> #include <linux/slab.h> +#include <trace/events/damon.h> /* Minimal region size. Every damon_region is aligned by this. */ #define MIN_REGION PAGE_SIZE
@@ -650,6 +653,8 @@ static void kdamond_reset_aggregated(struct damon_ctx *c)damon_write_rbuf (c, &r->vm_end,sizeof (r->vm_end));damon_write_rbuf (c, &r->nr_accesses,sizeof (r->nr_accesses)); +trace_damon_aggregated (t->pid, nr, + r->vm_start, r->vm_end, r->nr_accesses); r->nr_accesses =0 ; } }
Signature · 1 line
2.17.1
PATCH v11 12/16 tools: Add a minimal user-space tool for DAMON
In reply to SeongJae ParkFrom: SeongJae Park <[email protected]>
This commit adds a shallow wrapper python script, ``/tools/damon/damo`` that provides more convenient interface. Note that it is only aimed to be used for minimal reference of the DAMON's debugfs interfaces and for debugging of the DAMON itself.
--- tools/damon/.gitignore | 1 + tools/damon/_dist.py | 36 ++++ tools/damon/_recfile.py | 23 +++ tools/damon/bin2txt.py | 67 +++++++ tools/damon/damo | 37 ++++ tools/damon/heats.py | 362 ++++++++++++++++++++++++++++++++++++++ tools/damon/nr_regions.py | 91 ++++++++++ tools/damon/record.py | 212 ++++++++++++++++++++++ tools/damon/report.py | 45 +++++ tools/damon/wss.py | 97 ++++++++++ 10 files changed, 971 insertions(+) create mode 100644 tools/damon/.gitignore create mode 100644 tools/damon/_dist.py create mode 100644 tools/damon/_recfile.py create mode 100644 tools/damon/bin2txt.py create mode 100755 tools/damon/damo create mode 100644 tools/damon/heats.py create mode 100644 tools/damon/nr_regions.py create mode 100644 tools/damon/record.py create mode 100644 tools/damon/report.py create mode 100644 tools/damon/wss.py
tools/damon/.gitignore new file +1 -0
@@ -0,0 +1 @@ +__pycache__/*
tools/damon/_dist.py new file +36 -0
@@ -0,0 +1,36 @@ +#!/usr/bin/env python3 +# SPDX-License-Identifier: GPL-2.0 + +import os +import struct +import subprocess + +def access_patterns(f): + nr_regions = struct.unpack('I', f.read(4))[0] + + patterns = [] + for r in range(nr_regions): + saddr = struct.unpack('L', f.read(8))[0] + eaddr = struct.unpack('L', f.read(8))[0] + nr_accesses = struct.unpack('I', f.read(4))[0] + patterns.append([eaddr - saddr, nr_accesses]) + return patterns + +def plot_dist(data_file, output_file, xlabel, ylabel): + terminal = output_file.split('.')[-1] + if not terminal in ['pdf', 'jpeg', 'png', 'svg']: + os.remove(data_file) + print("Unsupported plot output type.") + exit(-1) + + gnuplot_cmd = """ + set term %s; + set output '%s'; + set key off; + set xlabel '%s'; + set ylabel '%s'; + plot '%s' with linespoints;""" % (terminal, output_file, xlabel, ylabel, + data_file) + subprocess.call(['gnuplot', '-e', gnuplot_cmd]) + os.remove(data_file) +
tools/damon/_recfile.py new file +23 -0
@@ -0,0 +1,23 @@ +#!/usr/bin/env python3 +# SPDX-License-Identifier: GPL-2.0 + +import struct + +fmt_version = 0 + +def set_fmt_version(f): + global fmt_version + + mark = f.read(16) + if mark == b'damon_recfmt_ver': + fmt_version = struct.unpack('i', f.read(4))[0] + else: + fmt_version = 0 + f.seek(0) + return fmt_version + +def pid(f): + if fmt_version == 0: + return struct.unpack('L', f.read(8))[0] + else: + return struct.unpack('i', f.read(4))[0]
tools/damon/bin2txt.py new file +67 -0
67 lines not on this page · raw message
tools/damon/damo new file +37 -0
@@ -0,0 +1,37 @@ +#!/usr/bin/env python3 +# SPDX-License-Identifier: GPL-2.0 + +import argparse + +import record +import report + +class SubCmdHelpFormatter(argparse.RawDescriptionHelpFormatter): + def _format_action(self, action): + parts = super(argparse.RawDescriptionHelpFormatter, + self)._format_action(action) + # skip sub parsers help + if action.nargs == argparse.PARSER: + parts = '\n'.join(parts.split('\n')[1:]) + return parts + +parser = argparse.ArgumentParser(formatter_class=SubCmdHelpFormatter) + +subparser = parser.add_subparsers(title='command', dest='command', + metavar='<command>') +subparser.required = True + +parser_record = subparser.add_parser('record', + help='record data accesses of the given target processes') +record.set_argparser(parser_record) + +parser_report = subparser.add_parser('report', + help='report the recorded data accesses in the specified form') +report.set_argparser(parser_report) + +args = parser.parse_args() + +if args.command == 'record': + record.main(args) +elif args.command == 'report': + report.main(args)
tools/damon/heats.py new file +362 -0
362 lines not on this page · raw message
tools/damon/nr_regions.py new file +91 -0
91 lines not on this page · raw message
tools/damon/record.py new file +212 -0
212 lines not on this page · raw message
tools/damon/report.py new file +45 -0
45 lines not on this page · raw message
tools/damon/wss.py new file +97 -0
97 lines not on this page · raw message
Signature · 1 line
2.17.1
PATCH v11 13/16 Documentation/admin-guide/mm: Add a document for DAMON
In reply to SeongJae ParkFrom: SeongJae Park <[email protected]>
This commit adds a simple document for DAMON under Documentation/admin-guide/mm.
--- .../admin-guide/mm/data_access_monitor.rst | 428 ++++++++++++++++++ Documentation/admin-guide/mm/index.rst | 1 + 2 files changed, 429 insertions(+) create mode 100644 Documentation/admin-guide/mm/data_access_monitor.rst
Documentation/admin-guide/mm/data_access_monitor.rst new file +428 -0
@@ -0,0 +1,428 @@ +.. SPDX-License-Identifier: GPL-2.0 + +========================== +DAMON: Data Access MONitor +========================== + +Introduction +============ + +Memory management decisions can be improved if finer data access information is +available. However, because such finer information usually comes with higher +overhead, most systems including Linux forgives the potential benefit and rely +on only coarse information or some light-weight heuristics. + +A number of data access pattern awared memory management optimizations +consistently say the potential benefit is not small (2.55x speedup). However, +none of those has successfully adopted into into the Linux kernel mainly due to +the absence of a scalable and efficient data access monitoring mechanism. + +DAMON is a data access monitoring subsystem for the problem. It is 1) accurate +enough to be used for the DRAM level memory management, 2) light-weight enough +to be applied online, and 3) keeps predefined upper-bound overhead +regardless of the size of target workloads (thus scalable). + +DAMON is implemented as a standalone kernel module and provides several simple +interfaces. Owing to that, though it has mainly designed for the kernel's +memory management mechanisms, it can be also used for a wide range of user +space programs and people. + + +Frequently Asked Questions +========================== + +Q: Why not integrated with perf? +A: From the perspective of perf like profilers, DAMON can be thought of as a +data source in kernel, like tracepoints, pressure stall information (psi), or +idle page tracking. Thus, it can be easily integrated with those. However, +this patchset doesn't provide a fancy perf integration because current step of +DAMON development is focused on its core logic only. That said, DAMON already +provides two interfaces for user space programs, which based on debugfs and +tracepoint, respectively. Using the tracepoint interface, you can use DAMON +with perf. This patchset also provides the debugfs interface based user space +tool for DAMON. It can be used to record, visualize, and analyze data access +pattern of target processes in a convenient way. + +Q: Why a new module, instead of extending perf or other tools? +A: First, DAMON aims to be used by other programs including the kernel. +Therefore, having dependency to specific tools like perf is not desirable. +Second, because it need to be lightweight as much as possible so that it can be +used online, any unnecessary overhead such as kernel - user space context +switching cost should be avoided. These are the two most biggest reasons why +DAMON is implemented in the kernel space. The idle page tracking subsystem +would be the kernel module that most seems similar to DAMON. However, it's own +interface is not compatible with DAMON. Also, the internal implementation of +it has no common part to be reused by DAMON. + +Q: Can 'perf mem' provide the data required for DAMON? +A: On the systems supporting 'perf mem', yes. DAMON is using the PTE Accessed +bits in low level. Other H/W or S/W features that can be used for the purpose +could be used. However, as explained with above question, DAMON need to be +implemented in the kernel space. + + +Expected Use-cases +================== + +A straightforward usecase of DAMON would be the program behavior analysis. +With the DAMON output, users can confirm whether the program is running as +intended or not. This will be useful for debuggings and tests of design +points. + +The monitored results can also be useful for counting the dynamic working set +size of workloads. For the administration of memory overcommitted systems or +selection of the environments (e.g., containers providing different amount of +memory) for your workloads, this will be useful. + +If you are a programmer, you can optimize your program by managing the memory +based on the actual data access pattern. For example, you can identify the +dynamic hotness of your data using DAMON and call ``mlock()`` to keep your hot +data in DRAM, or call ``madvise()`` with ``MADV_PAGEOUT`` to proactively +reclaim cold data. Even though your program is guaranteed to not encounter +memory pressure, you can still improve the performance by applying the DAMON +outputs for call of ``MADV_HUGEPAGE`` and ``MADV_NOHUGEPAGE``. More creative +optimizations would be possible. Our evaluations of DAMON includes a +straightforward optimization using the ``mlock()``. Please refer to the below +Evaluation section for more detail. + +As DAMON incurs very low overhead, such optimizations can be applied not only +offline, but also online. Also, there is no reason to limit such optimizations +to the user space. Several parts of the kernel's memory management mechanisms +could be also optimized using DAMON. The reclamation, the THP (de)promotion +decisions, and the compaction would be such a candidates. + + +Mechanisms of DAMON +=================== + + +Basic Access Check +------------------ + +DAMON basically reports what pages are how frequently accessed. The report is +passed to users in binary format via a ``result file`` which users can set it's +path. Note that the frequency is not an absolute number of accesses, but a +relative frequency among the pages of the target workloads. + +Users can also control the resolution of the reports by setting two time +intervals, ``sampling interval`` and ``aggregation interval``. In detail, +DAMON checks access to each page per ``sampling interval``, aggregates the +results (counts the number of the accesses to each page), and reports the +aggregated results per ``aggregation interval``. For the access check of each +page, DAMON uses the Accessed bits of PTEs. + +This is thus similar to the previously mentioned periodic access checks based +mechanisms, which overhead is increasing as the size of the target process +grows. + + +Region Based Sampling +--------------------- + +To avoid the unbounded increase of the overhead, DAMON groups a number of +adjacent pages that assumed to have same access frequencies into a region. As +long as the assumption (pages in a region have 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 and clears +its Accessed bit. After one more ``sampling interval``, DAMON reads the +Accessed bit of the page and increases the access frequency of the region if +the bit has set meanwhile. Therefore, the monitoring overhead is controllable +by setting the number of regions. DAMON allows users to set the minimal and +maximum number of regions for the trade-off. + +Except the assumption, this is almost same with the above-mentioned +miniature-like static region based sampling. In other words, this scheme +cannot preserve the quality of the output if the assumption is not guaranteed. + + +Adaptive Regions Adjustment +--------------------------- + +At the beginning of the monitoring, DAMON constructs the initial regions by +evenly splitting the memory mapped address space of the process into the +user-specified minimal number of regions. In this initial state, the +assumption is normally not kept and thus the quality could be low. To keep the +assumption as much as possible, DAMON adaptively merges and splits each region. +For each ``aggregation interval``, it compares the access frequencies of +adjacent regions and merges those if the frequency difference is small. Then, +after it reports and clears the aggregated access frequency of each region, it +splits each region into two regions if the total number of regions is smaller +than the half of the user-specified maximum number of regions. + +In this way, DAMON provides its best-effort quality and minimal overhead while +keeping the bounds users set for their trade-off. + + +Applying Complex and Dynamic Memory Mappings +-------------------------------------------- + +Only a number of small parts in the super-huge virtual address space of the +processes is mapped to physical memory and accessed. Thus, tracking the +unmapped address regions is just wasteful. However, because DAMON can deal +with some level of noises using the adaptive regions adjustment mechanism, +tracking every mapping is not strictly required but could even incur a high +overhead in somce 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, DAMON converts the complex mappings to three distinct regions +that cover every mapped areas of the address space. Also the two gaps between +the three regions are the two biggest unmapped areas in the given address +space. The two biggest unmapped areas might be the gap between the heap and +the uppermost mmap()-ed region, and the gap between the lowermost mmap()-ed +region and the stack will be two biggest unmapped regions. Because these gaps +are exceptionally huge areas in usual address space, excluding these two +biggest unmapped regions will be sufficient to make a trade-off. + +To further minimize dynamic mapping changes applying overhead, DAMON check the +dynamic memory mapping changes and applies it to the abstracted target area +only for each of a user-specified time interval (``regions update interval``). + + +``debugfs`` Interface +===================== + +DAMON exports four files, ``attrs``, ``pids``, ``record``, and ``monitor_on`` +under its debugfs directory, ``<debugfs>/damon/``. + +Attributes +---------- + +Users can read and write the ``sampling interval``, ``aggregation interval``, +``regions update interval``, and min/max number of monitoring target regions by +reading from and writing to the ``attrs`` file. For example, below commands +set those values to 5 ms, 100 ms, 1,000 ms, 10, 1000 and check it again:: + + # cd <debugfs>/damon + # echo 5000 100000 1000000 10 1000 > attrs + # cat attrs + 5000 100000 1000000 10 1000 + +Target PIDs +----------- + +Users can read and write the pids of current monitoring target processes by +reading from and writing to the ``pids`` file. For example, below commands set +processes having pids 42 and 4242 as the processes to be monitored and check it +again:: + + # cd <debugfs>/damon + # echo 42 4242 > pids + # cat pids + 42 4242 + +Note that setting the pids doesn't start the monitoring. + +Record +------ + +DAMON supports direct monitoring result record feature. The recorded results +are first written to a buffer and flushed to a file in batch. Users can set +the size of the buffer and the path to the result file by reading from and +writing to the ``record`` file. For example, below commands set the buffer to +be 4 KiB and the result to be saved in ``/damon.data``. + + # cd <debugfs>/damon + # echo "4096 /damon.data" > record + # cat record + 4096 /damon.data + +Turning On/Off +-------------- + +You can check current status, start and stop the monitoring by reading from and +writing to the ``monitor_on`` file. Writing ``on`` to the file starts DAMON to +monitor the target processes with the attributes. Writing ``off`` to the file +stops DAMON. DAMON also stops if every target processes is terminated. +Below example commands turn on, off, and check status of DAMON:: + + # cd <debugfs>/damon + # echo on > monitor_on + # echo off > monitor_on + # cat monitor_on + off + +Please note that you cannot write to the ``attrs`` and ``pids`` files while the +monitoring is turned on. If you write to the files while DAMON is running, an +error code such as ``-EBUSY`` will be returned. + + +User Space Tool for DAMON +========================= + +There is a user space tool for DAMON, ``/tools/damon/damo``. It provides +another user interface which more convenient than the debugfs interface. +Nevertheless, note that it is only aimed to be used for minimal reference of +the DAMON's debugfs interfaces and for tests of the DAMON itself. Based on the +debugfs interface, you can create another cool and more convenient user space +tools. + +The interface of the tool is basically subcommand based. You can almost always +use ``-h`` option to get help of the use of each subcommand. Currently, it +supports two subcommands, ``record`` and ``report``. + + +Recording Data Access Pattern +----------------------------- + +The ``record`` subcommand records the data access pattern of target process in +a file (``./damon.data`` by default) using DAMON. You can specifies the target +as either pid or a command for an execution of the process. Below example +shows a command target usage:: + + # cd <kernel>/tools/damon/ + # ./damo record "sleep 5" + +The tool will execute ``sleep 5`` by itself and record the data access patterns +of the process. Below example shows a pid target usage:: + + # sleep 5 & + # ./damo record `pidof sleep` + +You can set more detailed attributes and path to the recorded data file using +optional arguments to the subcommand. Use the ``-h`` option for more help. + + +Analyzing Data Access Pattern +----------------------------- + +The ``report`` subcommand reads a data access pattern record file (if not +explicitly specified, reads ``./damon.data`` file if exists) and generates +reports of various types. You can specify what type of report you want using +sub-subcommand to ``report`` subcommand. For supported types, pass the ``-h`` +option to ``report`` subcommand. + + +raw +~~~ + +``raw`` sub-subcommand simply transforms the record, which is storing the data +access patterns in binary format to human readable text. For example:: + + $ ./damo report raw + start_time: 193485829398 + rel time: 0 + nr_tasks: 1 + pid: 1348 + nr_regions: 4 + 560189609000-56018abce000( 22827008): 0 + 7fbdff59a000-7fbdffaf1a00( 5601792): 0 + 7fbdffaf1a00-7fbdffbb5000( 800256): 1 + 7ffea0dc0000-7ffea0dfd000( 249856): 0 + + rel time: 100000731 + nr_tasks: 1 + pid: 1348 + nr_regions: 6 + 560189609000-56018abce000( 22827008): 0 + 7fbdff59a000-7fbdff8ce933( 3361075): 0 + 7fbdff8ce933-7fbdffaf1a00( 2240717): 1 + 7fbdffaf1a00-7fbdffb66d99( 480153): 0 + 7fbdffb66d99-7fbdffbb5000( 320103): 1 + 7ffea0dc0000-7ffea0dfd000( 249856): 0 + +The first line shows recording started timestamp (nanosecond). Records of data +access patterns are following this. Each record is sperated by a blank line. +Each record first specifies the recorded time (``rel time``), number of +monitored tasks in this record (``nr_tasks``). Multiple number of records of +data access pattern for each task continue. Each data access pattern for each +task shows first it's pid (``pid``) and number of monitored virtual address +regions in this access pattern (``nr_regions``). After that, each line shows +start/end address, size, and number of monitored accesses to the region for +each of the regions. + + +heats +~~~~~ + +The ``raw`` type shows detailed information but it is exhaustive to manually +read and analyzed. For the reason, ``heats`` plots the data in heatmap form, +using time as x-axis, virtual address as y-axis, and access frequency as +z-axis. Also, users set the resolution and start/end point of each axis via +optional arguments. For example:: + + $ ./damo report heats --tres 3 --ares 3 + 0 0 0.0 + 0 7609002 0.0 + 0 15218004 0.0 + 66112620851 0 0.0 + 66112620851 7609002 0.0 + 66112620851 15218004 0.0 + 132225241702 0 0.0 + 132225241702 7609002 0.0 + 132225241702 15218004 0.0 + +This command shows the recorded access pattern of the ``sleep`` command using 3 +data points for each of time axis and address axis. Therefore, it shows 9 data +points in total. + +Users can easily converts this text output into heatmap image or other 3D +representation using various tools such as 'gnuplot'. ``raw`` sub-subcommand +also provides 'gnuplot' based heatmap image creation. For this, you can use +``--heatmap`` option. Also, note that because it uses 'gnuplot' internally, it +will fail if 'gnuplot' is not installed on your system. For example:: + + $ ./damo report heats --heatmap heatmap.png + +Creates ``heatmap.png`` file containing the heatmap image. It supports +``pdf``, ``png``, ``jpeg``, and ``svg``. + +For proper zoom in / zoom out, you need to see the layout of the record. For +that, use '--guide' option. If the option is given, it will provide useful +information about the records in the record file. For example:: + + $ ./damo report heats --guide + pid:1348 + time: 193485829398-198337863555 (4852034157) + region 0: 00000094564599762944-00000094564622589952 (22827008) + region 1: 00000140454009610240-00000140454016012288 (6402048) + region 2: 00000140731597193216-00000140731597443072 (249856) + +The output shows monitored regions (start and end addresses in byte) and +monitored time duration (start and end time in nanosecond) of each target task. +Therefore, it would be wise to plot only each region rather than plotting +entire address space in one heatmap because the gaps between the regions are so +huge in this case. + + +wss +~~~ + +The ``wss`` type shows the distribution or time-varying working set sizes of +the recorded workload using the records. For example:: + + $ ./damo report wss + # <percentile> <wss> + # pid 1348 + # avr: 66228 + 0 0 + 25 0 + 50 0 + 75 0 + 100 1920615 + +Without any option, it shows the distribution of the working set sizes as +above. Basically it shows 0th, 25th, 50th, 75th, and 100th percentile and +average of the measured working set sizes in the access pattern records. In +this case, the working set size was zero for 75th percentile but 1,920,615 +bytes in max and 66,228 in average. + +By setting the sort key of the percentile using '--sortby', you can also see +how the working set size is chronologically changed. For example:: + + $ ./damo report wss --sortby time + # <percentile> <wss> + # pid 1348 + # avr: 66228 + 0 0 + 25 0 + 50 0 + 75 0 + 100 0 + +The average is still 66,228. And, because we sorted the working set using +recorded time and the access is very short, we cannot show when the access +made. + +Users can specify the resolution of the distribution (``--range``). It also +supports 'gnuplot' based simple visualization (``--plot``) of the distribution.
Documentation/admin-guide/mm/index.rst +1 -0
@@ -27,6 +27,7 @@ the Linux memory management. concepts cma_debugfs + data_access_monitor hugetlbpage idle_page_tracking ksm
Signature · 1 line
2.17.1
PATCH v11 14/16 mm/damon: Add kunit tests
In reply to SeongJae ParkFrom: SeongJae Park <[email protected]>
This commit adds kunit based unit tests for DAMON.
--- mm/Kconfig | 11 + mm/damon-test.h | 622 ++++++++++++++++++++++++++++++++++++++++++++++++ mm/damon.c | 6 + 3 files changed, 639 insertions(+) create mode 100644 mm/damon-test.h
mm/Kconfig +11 -0
@@ -751,4 +751,15 @@ config DAMON and 2) sufficiently light-weight so that it can be applied online. If unsure, say N. +config DAMON_KUNIT_TEST + bool "Test for damon" + depends on DAMON=y && KUNIT + help + This builds the DAMON Kunit test suite. + + For more information on KUnit and unit tests in general, please refer + to the KUnit documentation. + + If unsure, say N. + endmenu
mm/damon-test.h new file +622 -0
622 lines not on this page · raw message
mm/damon.c +6 -0
@@ -25,7 +25,11 @@#include <trace/events/damon.h> /* Minimal region size. Every damon_region is aligned by this. */ +#ifndef CONFIG_DAMON_KUNIT_TEST #define MIN_REGION PAGE_SIZE +#else +#define MIN_REGION 1 +#endif #define damon_get_task_struct (t) \ (get_pid_task(find_vpid(t->pid), PIDTYPE_PID))
@@ -1503,3 +1507,5 @@ module_exit(damon_exit);MODULE_LICENSE ("GPL" );MODULE_AUTHOR ("SeongJae Park <[email protected]>" );MODULE_DESCRIPTION ("DAMON: Data Access MONitor" ); + +#include "damon-test.h"
Signature · 1 line
2.17.1
PATCH v11 15/16 mm/damon: Add user space selftests
In reply to SeongJae ParkFrom: SeongJae Park <[email protected]>
This commit adds a simple user space tests for DAMON. The tests are using kselftest framework.
--- tools/testing/selftests/damon/Makefile | 7 + .../selftests/damon/_chk_dependency.sh | 28 ++++ tools/testing/selftests/damon/_chk_record.py | 108 ++++++++++++++ .../testing/selftests/damon/debugfs_attrs.sh | 139 ++++++++++++++++++ .../testing/selftests/damon/debugfs_record.sh | 50 +++++++ 5 files changed, 332 insertions(+) create mode 100644 tools/testing/selftests/damon/Makefile create mode 100644 tools/testing/selftests/damon/_chk_dependency.sh create mode 100644 tools/testing/selftests/damon/_chk_record.py create mode 100755 tools/testing/selftests/damon/debugfs_attrs.sh create mode 100755 tools/testing/selftests/damon/debugfs_record.sh
tools/testing/selftests/damon/Makefile new file +7 -0
@@ -0,0 +1,7 @@ +# SPDX-License-Identifier: GPL-2.0 +# Makefile for damon selftests + +TEST_FILES = _chk_dependency.sh _chk_record_file.py +TEST_PROGS = debugfs_attrs.sh debugfs_record.sh + +include ../lib.mk
tools/testing/selftests/damon/_chk_dependency.sh new file +28 -0
@@ -0,0 +1,28 @@ +#!/bin/bash +# SPDX-License-Identifier: GPL-2.0 + +# Kselftest framework requirement - SKIP code is 4. +ksft_skip=4 + +DBGFS=/sys/kernel/debug/damon + +if [ $EUID -ne 0 ]; +then + echo "Run as root" + exit $ksft_skip +fi + +if [ ! -d $DBGFS ] +then + echo "$DBGFS not found" + exit $ksft_skip +fi + +for f in attrs record pids monitor_on +do + if [ ! -f "$DBGFS/$f" ] + then + echo "$f not found" + exit 1 + fi +done
tools/testing/selftests/damon/_chk_record.py new file +108 -0
108 lines not on this page · raw message
tools/testing/selftests/damon/debugfs_attrs.sh new file +139 -0
139 lines not on this page · raw message
tools/testing/selftests/damon/debugfs_record.sh new file +50 -0
50 lines not on this page · raw message
Signature · 1 line
2.17.1
PATCH v11 16/16 MAINTAINERS: Update for DAMON
In reply to SeongJae ParkFrom: SeongJae Park <[email protected]>
This commit updates MAINTAINERS file for DAMON related files.
--- MAINTAINERS | 12 ++++++++++++ 1 file changed, 12 insertions(+)
MAINTAINERS +12 -0
@@ -4661,6 +4661,18 @@ F: net/ax25/ax25_out.c F: net/ax25/ax25_timer.c F: net/ax25/sysctl_net_ax25.c +DATA ACCESS MONITOR +M: SeongJae Park <[email protected]> +L: [email protected] +S: Maintained +F: Documentation/admin-guide/mm/data_access_monitor.rst +F: include/linux/damon.h +F: include/trace/events/damon.h +F: mm/damon-test.h +F: mm/damon.c +F: tools/damon/* +F: tools/testing/selftests/damon/* + DAVICOM FAST ETHERNET (DMFE) NETWORK DRIVER L: [email protected] S: Orphan
Signature · 1 line
2.17.1