Introduce Data Access MONitor (DAMON)
Subsystems (8)
v6 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 improvement 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 experimental data access pattern awared memory management optimizations (refer to 'Appendix A' for more details) say the sacrifices are huge. However, none of those has successfully adopted to 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.
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.
Visualized Outputs of DAMON
===========================
For intuitively understanding of DAMON, I made web pages[1-8] showing the visualized dynamic data access pattern of various realistic workloads, which I picked up from 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
Data Access Monitoring-based Operation Schemes
==============================================
As 'Appendix D' describes, DAMON can be used for data access monitoring-based operation schemes (DAMOS). RFC patchsets for DAMOS are already available
(https://lore.kernel.org/linux-mm/[email protected]/).
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.
The detailed setup and number will be posted soon with the next RFC patchset for DAMOS. The posting is currently scheduled for tomorrow.
Frequently Asked Questions
==========================
Q: Why DAMON is not integrated with perf?
A: From the perspective of perf like profilers, DAMON can be thought of as a data source in kernel, like the tracepoints, the pressure stall information (psi), or the idle page tracking. Thus, it is easy to integrate DAMON with the profilers. 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 a debugfs interface based user space tool for DAMON. It can be used to record, visualize, and analyze data access patterns 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, 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' 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.
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].
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. The optimized versions consistently show speedup (2.55x in best case, 1.65x in average) under memory pressure.
Overhead
--------
We also measured the overhead of DAMON. It was not only under the upperbound we set, but 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 access check-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.
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/
Sequence Of Patches
===================
The patches are organized in the following sequence. The first patch introduces DAMON module, it's data structures, and data structure related common functions. Following three patches (2nd to 4th) implement the core logics of DAMON, namely regions based sampling, adaptive regions adjustment, and dynamic memory mapping chage adoption, one by one.
Following five patches are for low level users of DAMON. The 5th patch implements callbacks for each of monitoring steps so that users can do whatever they want with the access patterns. The 6th one implements recording of access patterns in DAMON for better convenience and efficiency. Each of next three patches (7th to 9th) respectively adds a programmable interface for other kernel code, 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 (10th) implements an user space tool. The 11th patch adds a document for administrators of DAMON.
Next two patches are for tests. The 12th and 13th patches provide unit tests (based on kunit) and user space tests (based on kselftest) respectively.
Finally, the last patch (14th) updates the MAINTAINERS file.
The patches are based on the v5.5. You can also clone the complete git tree:
$ git clone git://github.com/sjp38/linux -b damon/patches/v6
The web is also available:
https://github.com/sjp38/linux/releases/tag/damon/patches/v6
Patch History
=============
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 (14):
mm: Introduce Data Access MONitor (DAMON) mm/damon: Implement region based sampling mm/damon: Adaptively adjust regions
mm/damon: Apply dynamic memory mapping changes mm/damon: Implement callbacks
mm/damon: Implement access pattern recording mm/damon: Implement kernel space API mm/damon: Add debugfs interface
mm/damon: Add a tracepoint for result writing
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 selftests
MAINTAINERS: Update for DAMON
.../admin-guide/mm/data_access_monitor.rst | 414 +++++ Documentation/admin-guide/mm/index.rst | 1 + MAINTAINERS | 12 + include/linux/damon.h | 71 + include/trace/events/damon.h | 32 + mm/Kconfig | 23 + mm/Makefile | 1 + mm/damon-test.h | 604 +++++++ mm/damon.c | 1427 +++++++++++++++++ mm/page_ext.c | 1 + tools/damon/.gitignore | 1 + tools/damon/_dist.py | 36 + tools/damon/bin2txt.py | 64 + tools/damon/damo | 37 + tools/damon/heats.py | 358 +++++ tools/damon/nr_regions.py | 89 + tools/damon/record.py | 212 +++ tools/damon/report.py | 45 + tools/damon/wss.py | 95 ++ tools/testing/selftests/damon/Makefile | 7 + .../selftests/damon/_chk_dependency.sh | 28 + tools/testing/selftests/damon/_chk_record.py | 89 + .../testing/selftests/damon/debugfs_attrs.sh | 139 ++ .../testing/selftests/damon/debugfs_record.sh | 50 + 24 files changed, 3836 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/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 · 236 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.
A Future Plan: Data Access Monitoring-based Operation Schemes
-------------------------------------------------------------
As described in the above section, DAMON could be helpful for actual access
based memory management optimizations. Nevertheless, users who want to do such
optimizations should run DAMON, read the traced data (either online or
offline), analyze it, plan a new memory management scheme, and apply the new
scheme by themselves. It must be easier than the past, but could still require
some level of efforts. In its next development stage, DAMON will reduce some
of such efforts by allowing users to specify some access based memory
management rules for their specific processes.
Because this is just a plan, the specific interface is not fixed yet, but for
example, users will be allowed to write their desired memory management rules
to a special file in a DAMON specific format. The rules will be something like
'if a memory region of size in a range is keeping a range of hotness for more
than a duration, apply specific memory management rule using madvise() or
mlock() to the region'. For example, we can imagine rules like below:
# format is: <min/max size> <min/max frequency (0-99)> <duration> <action>
# if a region of a size keeps a very high access frequency for more than
# 100ms, lock the region in the main memory (call mlock()). But, if the
# region is larger than 500 MiB, skip it. The exception might be helpful
# if the system has only, say, 600 MiB of DRAM, a region of size larger
# than 600 MiB cannot be locked in the DRAM at all.
na 500M 90 99 100ms mlock
# if a region keeps a high access frequency for more than 100ms, put the
# region on the head of the LRU list (call madvise() with MADV_WILLNEED).
na na 80 90 100ms madv_willneed
# if a region keeps a low access frequency for more than 100ms, put the
# region on the tail of the LRU list (call madvise() with MADV_COLD).
na na 10 20 100ms madv_cold
# if a region keeps a very low access frequency for more than 100ms, swap
# out the region immediately (call madvise() with MADV_PAGEOUT).
na na 0 10 100ms madv_pageout
# if a region of a size bigger than 2MB keeps a very high access frequency
# for more than 100ms, let the region to use huge pages (call madvise()
# with MADV_HUGEPAGE).
2M na 90 99 100ms madv_hugepage
# If a regions of a size bigger than > 2MB keeps no high access frequency
# for more than 100ms, avoid the region from using huge pages (call
# madvise() with MADV_NOHUGEPAGE).
2M na 0 25 100ms madv_nohugepage
An RFC patchset for this is available:
https://lore.kernel.org/linux-mm/[email protected]/PATCH v6 1/14 mm: Introduce Data Access MONitor (DAMON)
From: 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.
Brief 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 improvement 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 experimental data access pattern awared memory management optimizations say the sacrifices are huge. However, none of those has successfully adopted to Linux kernel mainly due to the absence of a scalable and efficient data access monitoring mechanism.
DAMON is a data access monitoring solution for the problem. It is 1) accurate enough 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.
--- mm/Kconfig | 12 +++ mm/Makefile | 1 + mm/damon.c | 224 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 3 files changed, 237 insertions(+) create mode 100644 mm/damon.c
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 + default n + 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. + endmenu
mm/Makefile +1 -0
@@ -108,3 +108,4 @@ obj-$(CONFIG_ZONE_DEVICE) += memremap.o obj-$(CONFIG_HMM_MIRROR) += hmm.o obj-$(CONFIG_MEMFD_CREATE) += memfd.o obj-$(CONFIG_MAPPING_DIRTY_HELPERS) += mapping_dirty_helpers.o +obj-$(CONFIG_DAMON) += damon.o
mm/damon.c new file +224 -0
224 lines not on this page · raw message
Signature · 1 line
2.17.1
Re: [PATCH v6 01/14] mm: Introduce Data Access MONitor (DAMON)
Apologies if anyone gets these twice. I had an email server throttling issue yesterday.
Quoted 7 lines · On Mon, 24 Feb 2020 13:30:34 +0100 SeongJae Park <[email protected]> wrote:
From: 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.
Interesting piece of work. I'm reviewing this partly as an exercise in understanding it, but I'll point out minor stuff on the basis I might as well whilst I'm here. ;) Note I review bottom up so some comments won't make much sense read from the top.
Quoted 3 lines
Brief Introduction
==================
I'd keep this level of intro for the cover letter / docs. It's not particularly useful in commit message it git.
Quoted 70 lines
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 improvement 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 experimental data access pattern awared memory management optimizations say the sacrifices are huge. However, none of those has successfully adopted to Linux kernel mainly due to the absence of a scalable and efficient data access monitoring mechanism.
DAMON is a data access monitoring solution for the problem. It is 1) accurate enough 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.Signed-off-by SeongJae Park <[email protected]>--- mm/Kconfig | 12 +++ mm/Makefile | 1 + mm/damon.c | 224 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 3 files changed, 237 insertions(+) create mode 100644 mm/damon.cmm/Kconfig +0
-0
mm/Kconfig config ARCH_HAS_HUGEPD · line 745
Quoted 7 lines
mm/Kconfig +4
-0@@ -739,4 +739,16 @@ config ARCH_HAS_HUGEPD config MAPPING_DIRTY_HELPERS bool +config DAMON + tristate "Data Access Monitor" + depends on MMU + default n
No need to specify a default of n.
Quoted 85 lines
mm/Kconfig +8
-0+ 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. + endmenumm/Makefile +1
-0@@ -108,3 +108,4 @@ obj-$(CONFIG_ZONE_DEVICE) += memremap.o obj-$(CONFIG_HMM_MIRROR) += hmm.o obj-$(CONFIG_MEMFD_CREATE) += memfd.o obj-$(CONFIG_MAPPING_DIRTY_HELPERS) += mapping_dirty_helpers.o +obj-$(CONFIG_DAMON) += damon.omm/damon.c new file +61
-0@@ -0,0 +1,224 @@ +// SPDX-License-Identifier: GPL-2.0 +/* +* Data Access Monitor +* +* Copyright 2019 Amazon.com, Inc. or its affiliates. All rights reserved. +* +* Author: SeongJae Park <[email protected]> +*/ + +#define pr_fmt (fmt) "damon: " fmt + +#include <linux/mm.h> +#include <linux/module.h> +#include <linux/random.h> +#include <linux/slab.h> + +#define damon_get_task_struct (t) \ + (get_pid_task(find_vpid(t->pid), PIDTYPE_PID)) + +#define damon_next_region (r) \ + (container_of(r->list.next, struct damon_region, list)) + +#define damon_prev_region (r) \ + (container_of(r->list.prev, struct damon_region, list)) + +#define damon_for_each_region (r, t) \ + list_for_each_entry(r, &t->regions_list, list) + +#define damon_for_each_region_safe (r, next, t) \ + list_for_each_entry_safe(r, next, &t->regions_list, list) + +#define damon_for_each_task (ctx, t) \ + list_for_each_entry(t, &(ctx)->tasks_list, list) + +#define damon_for_each_task_safe (ctx, t, next) \ + list_for_each_entry_safe(t, next, &(ctx)->tasks_list, list) + +/* Represents a monitoring target region on the virtual address space */ +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 { +unsigned long pid; +struct list_head regions_list; +struct list_head list; +}; + +struct damon_ctx { +struct rnd_state rndseed; + +struct list_head tasks_list;/* 'damon_task' objects */ +}; + +/* Get a random number in [l, r) */ +#define damon_rand (ctx, l, r) (l + prandom_u32_state(&ctx->rndseed) % (r - l))
mm/damon.c line 71
Quoted 10 lines
mm/damon.c new file +10
-0+ +/* +* Construct a damon_region struct +* +* Returns the pointer to the new struct if success, or NULL otherwise +*/ +static struct damon_region *damon_new_region (struct damon_ctx *ctx, +unsigned long vm_start,unsigned long vm_end) +{ +struct damon_region *ret;
I'd give this a different variable name. Expectation in kernel is often that ret is simply an magic handle to be passed on. Don't normally expect to set elements of it. I'd go long hand and call it region.
mm/damon.c line 73
Quoted 2 lines
mm/damon.c new file +2
-0+ + ret =kmalloc (sizeof (struct damon_region ),GFP_KERNEL );
sizeof(*ret)
mm/damon.c line 75
Quoted 2 lines
mm/damon.c new file +2
-0+if (!ret) +return NULL ;
blank line.
mm/damon.c line 86
Quoted 11 lines
mm/damon.c new file +11
-0+ ret->vm_start = vm_start; + ret->vm_end = vm_end; + ret->nr_accesses =0 ; + ret->sampling_addr =damon_rand (ctx, vm_start, vm_end); +INIT_LIST_HEAD (&ret->list); + +return ret; +} + +/* +* Add a region between two other regions
Interestingly even the list.h comments for __list_add call this
function "insert". No idea why it isn't simply called that..
Perhaps damon_insert_region would be clearer and avoid need for comment?
mm/damon.c line 95
Quoted 9 lines
mm/damon.c new file +9
-0+*/ +static inline void damon_add_region (struct damon_region *r, +struct damon_region *prev,struct damon_region *next) +{ +__list_add (&r->list, &prev->list, &next->list); +} + +/* +* Append a region to a task's list of regions
I'd argue the naming is sufficient that the comment adds little.
mm/damon.c line 103
Quoted 8 lines
mm/damon.c new file +8
-0+*/ +static void damon_add_region_tail (struct damon_region *r,struct damon_task *t) +{ +list_add_tail (&r->list, &t->regions_list); +} + +/* +* Delete a region from its list
The list is an implementation detail. I'd not mention that in the comments.
mm/damon.c line 111
Quoted 8 lines
mm/damon.c new file +8
-0+*/ +static void damon_del_region (struct damon_region *r) +{ +list_del (&r->list); +} + +/* +* De-allocate a region
Obvious comment - seem rot risk note below.
Quoted 12 lines
mm/damon.c new file +12
-0+*/ +static void damon_free_region (struct damon_region *r) +{ +kfree (r); +} + +static void damon_destroy_region (struct damon_region *r) +{ +damon_del_region (r); +damon_free_region (r); +} +
mm/damon.c line 133
Quoted 10 lines
mm/damon.c new file +10
-0+/* +* Construct a damon_task struct +* +* Returns the pointer to the new struct if success, or NULL otherwise +*/ +static struct damon_task *damon_new_task (unsigned long pid) +{ +struct damon_task *t; + + t =kmalloc (sizeof (struct damon_task ),GFP_KERNEL );
sizeof(*t) is probably less error prone if this code is maintained in the long run.
mm/damon.c line 135
Quoted 2 lines
mm/damon.c new file +2
-0+if (!t) +return NULL ;
blank line.
mm/damon.c line 148
Quoted 13 lines
mm/damon.c new file +13
-0+ t->pid = pid; +INIT_LIST_HEAD (&t->regions_list); + +return t; +} + +/* Returns n-th damon_region of the given task */ +struct damon_region *damon_nth_region_of (struct damon_task *t,unsigned int n) +{ +struct damon_region *r; +unsigned int i; + + i =0 ;
unsigned int i = 0;
mm/damon.c line 152
Quoted 4 lines
mm/damon.c new file +4
-0+damon_for_each_region (r, t) { +if (i++ == n) +return r; + }
blank line helps readability a little.
mm/damon.c line 156
Quoted 4 lines
mm/damon.c new file +4
-0+return NULL ; +} + +static void damon_add_task_tail (struct damon_ctx *ctx,struct damon_task *t)
I'm curious, do we care that it's on the tail? If not I'd look on that as an implementation detail and just call this
damon_add_task()
Quoted 16 lines
mm/damon.c new file +16
-0+{ +list_add_tail (&t->list, &ctx->tasks_list); +} + +static void damon_del_task (struct damon_task *t) +{ +list_del (&t->list); +} + +static void damon_free_task (struct damon_task *t) +{ +struct damon_region *r, *next; + +damon_for_each_region_safe (r, next, t) +damon_free_region (r); +kfree (t);
mm/damon.c line 182
Quoted 10 lines
mm/damon.c new file +10
-0+} + +static void damon_destroy_task (struct damon_task *t) +{ +damon_del_task (t); +damon_free_task (t); +} + +/* +* Returns number of monitoring target tasks
As below, kind of obvious so just room for rot.
mm/damon.c line 195
Quoted 13 lines
mm/damon.c new file +13
-0+*/ +static unsigned int nr_damon_tasks (struct damon_ctx *ctx) +{ +struct damon_task *t; +unsigned int ret =0 ; + +damon_for_each_task (ctx, t) + ret++; +return ret; +} + +/* +* Returns the number of target regions for a given target task
Always a trade off between useful comments and possibility of docs rotting. I'd drop this comment certainly.
The function name is self explanatory.
mm/damon.c line 203
Quoted 8 lines
mm/damon.c new file +8
-0+*/ +static unsigned int nr_damon_regions (struct damon_task *t) +{ +struct damon_region *r; +unsigned int ret =0 ; + +damon_for_each_region (r, t) + ret++;
Blank line here would help readability a tiny bit. Same in other places where we have something followed by a nice simple return statement.
mm/damon.c line 209
Quoted 6 lines
mm/damon.c new file +6
-0+return ret; +} + +static int __init damon_init (void ) +{ +pr_info ("init\n" );
Drop these. They are just noise.
Quoted 15 lines
mm/damon.c new file +15
-0+ +return 0 ; +} + +static void __exit damon_exit(void) +{ +pr_info ("exit\n" ); +} + +module_init (damon_init); +module_exit (damon_exit); + +MODULE_LICENSE ("GPL" ); +MODULE_AUTHOR ("SeongJae Park <[email protected]>" ); +MODULE_DESCRIPTION ("DAMON: Data Access MONitor" );
Re: Re: [PATCH v6 01/14] mm: Introduce Data Access MONitor (DAMON)
Quoted 14 lines · On Tue, 10 Mar 2020 08:54:05 +0000 Jonathan Cameron…
Apologies if anyone gets these twice. I had an email server throttling issue yesterday.
Quoted 7 lines · On Mon, 24 Feb 2020 13:30:34 +0100 SeongJae Park <[email protected]> wrote:
From: 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.
Quoted 4 lines
Interesting piece of work. I'm reviewing this partly as an exercise in understanding it, but I'll point out minor stuff on the basis I might as well whilst I'm here. ;) Note I review bottom up so some comments won't make much sense read from the top.
Thanks for review, Jonathan :) I added reply in line below, but agree to your whole suggestion. Will apply those in next spin.
Quoted 7 lines
Quoted 4 lines
Brief Introduction
==================I'd keep this level of intro for the cover letter / docs. It's not particularly useful in commit message it git.
Agreed.
Quoted 2 lines
Quoted 2 lines
[...]
Quoted 7 lines
mm/Kconfig config ARCH_HAS_HUGEPD · line 745
Quoted 5 lines
mm/Kconfig +4
-0+config DAMON + tristate "Data Access Monitor" + depends on MMU + default nNo need to specify a default of n.
Got it.
Quoted 10 lines
Quoted 10 lines
mm/Kconfig +8
-0+ 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. + endmenu
[...]
Quoted 5 lines
Quoted 5 lines
+/*
+ * Construct adamon_regionstruct
+ *
+ * Returns the pointer to the new struct if success, or NULL otherwise
+ */
Quoted 8 lines
mm/damon.c line 71
Quoted 4 lines
mm/damon.c new file +4
-0+static struct damon_region *damon_new_region (struct damon_ctx *ctx, +unsigned long vm_start,unsigned long vm_end) +{ +struct damon_region *ret;I'd give this a different variable name. Expectation in kernel is often that ret is simply an magic handle to be passed on. Don't normally expect to set elements of it. I'd go long hand and call it region.
Nice point, will change the name to 'region'.
Quoted 5 lines
Review
Quoted 3 lines
(quoted diff) +2
-0+ + ret = kmalloc(sizeof(struct damon_region), GFP_KERNEL);
sizeof(*ret)
Thanks for catching it! Will apply to other similar cases.
Quoted 5 lines
Review
Quoted 3 lines
(quoted diff) +2
-0+ if (!ret) + return NULL;blank line.
Good suggestion.
Quoted 15 lines
mm/damon.c line 86
Quoted 12 lines
mm/damon.c new file +11
-0+ ret->vm_start = vm_start; + ret->vm_end = vm_end; + ret->nr_accesses =0 ; + ret->sampling_addr =damon_rand (ctx, vm_start, vm_end); +INIT_LIST_HEAD (&ret->list); + +return ret; +} + +/* +* Add a region between two other regions Interestingly even the
list.hcomments for__list_addcall this
function "insert". No idea why it isn't simply called that..
Quoted 2 lines
Perhaps
damon_insert_regionwould be clearer and avoid need for comment?
I just wanted to make the name consistent with the 'list.h' file, but your suggestion sounds better. Will change so.
Quoted 12 lines
mm/damon.c line 95
Quoted 10 lines
+ */
mm/damon.c new file +8
-0+static inline void damon_add_region (struct damon_region *r, +struct damon_region *prev,struct damon_region *next) +{ +__list_add (&r->list, &prev->list, &next->list); +} + +/* +* Append a region to a task's list of regions I'd argue the naming is sufficient that the comment adds little.
Yes, will delete it.
Quoted 11 lines
mm/damon.c line 103
Quoted 9 lines
+ */
mm/damon.c new file +7
-0+static void damon_add_region_tail (struct damon_region *r,struct damon_task *t) +{ +list_add_tail (&r->list, &t->regions_list); +} + +/* +* Delete a region from its list The list is an implementation detail. I'd not mention that in the comments.
Nice suggestion.
Quoted 11 lines
mm/damon.c line 111
Quoted 9 lines
+ */
mm/damon.c new file +7
-0+static void damon_del_region (struct damon_region *r) +{ +list_del (&r->list); +} + +/* +* De-allocate a region Obvious comment - seem rot risk note below.
Agreed.
Quoted 18 lines
Quoted 18 lines
+ */
mm/damon.c new file +16
-0+static void damon_free_region (struct damon_region *r) +{ +kfree (r); +} + +static void damon_destroy_region (struct damon_region *r) +{ +damon_del_region (r); +damon_free_region (r); +} + +/* +* Construct a damon_task struct +* +* Returns the pointer to the new struct if success, or NULL otherwise +*/
Quoted 8 lines
mm/damon.c line 133
Quoted 5 lines
mm/damon.c new file +5
-0+static struct damon_task *damon_new_task (unsigned long pid) +{ +struct damon_task *t; + + t =kmalloc (sizeof (struct damon_task ),GFP_KERNEL );
sizeof(*t)is probably less error prone if this code is maintained in the long run.
Good point, will apply to other cases, either.
Quoted 5 lines
Review
Quoted 3 lines
(quoted diff) +2
-0+ if (!t) + return NULL;blank line.
Will add it.
Quoted 15 lines
Quoted 4 lines
mm/damon.c new file +3
-0+ t->pid = pid; +INIT_LIST_HEAD (&t->regions_list); +mm/damon.c line 148
Quoted 10 lines
mm/damon.c new file +10
-0+return t; +} + +/* Returns n-th damon_region of the given task */ +struct damon_region *damon_nth_region_of (struct damon_task *t,unsigned int n) +{ +struct damon_region *r; +unsigned int i; + + i =0 ;unsigned int i = 0;
Yes, it must be much better.
Quoted 7 lines
mm/damon.c line 152
Quoted 5 lines
mm/damon.c new file +4
-0+damon_for_each_region (r, t) { +if (i++ == n) +return r; + }blank line helps readability a little.
Yes, indeed.
Quoted 10 lines
mm/damon.c line 156
Quoted 5 lines
mm/damon.c new file +4
-0+return NULL ; +} + +static void damon_add_task_tail (struct damon_ctx *ctx,struct damon_task *t)I'm curious, do we care that it's on the tail? If not I'd look on that as an implementation detail and just call this
damon_add_task()
I named it to be consistent with 'damon_add_region[_tail]()' functions, but as you suggested renaming 'damon_add_region()', it doesn't need to. Will change the name.
Quoted 21 lines
Quoted 21 lines
mm/damon.c new file +20
-0+{ +list_add_tail (&t->list, &ctx->tasks_list); +} + +static void damon_del_task (struct damon_task *t) +{ +list_del (&t->list); +} + +static void damon_free_task (struct damon_task *t) +{ +struct damon_region *r, *next; + +damon_for_each_region_safe (r, next, t) +damon_free_region (r); +kfree (t); +} + +static void damon_destroy_task (struct damon_task *t) +{
Quoted 8 lines
mm/damon.c line 182
Quoted 6 lines
mm/damon.c new file +6
-0+damon_del_task (t); +damon_free_task (t); +} + +/* +* Returns number of monitoring target tasks As below, kind of obvious so just room for rot.
Agreed.
Quoted 10 lines
Quoted 10 lines
+ */
mm/damon.c new file +8
-0+static unsigned int nr_damon_tasks (struct damon_ctx *ctx) +{ +struct damon_task *t; +unsigned int ret =0 ; + +damon_for_each_task (ctx, t) + ret++; +return ret;
Quoted 8 lines
mm/damon.c line 195
Quoted 4 lines
mm/damon.c new file +4
-0+} + +/* +* Returns the number of target regions for a given target task Always a trade off between useful comments and possibility of docs rotting. I'd drop this comment certainly.
The function name is self explanatory.
Agreed!
Quoted 13 lines
mm/damon.c line 203
Quoted 9 lines
+ */
mm/damon.c new file +7
-0+static unsigned int nr_damon_regions (struct damon_task *t) +{ +struct damon_region *r; +unsigned int ret =0 ; + +damon_for_each_region (r, t) + ret++;Blank line here would help readability a tiny bit. Same in other places where we have something followed by a nice simple return statement.
Yes, indeed.
Quoted 9 lines
mm/damon.c line 209
Quoted 7 lines
mm/damon.c new file +6
-0+return ret; +} + +static int __init damon_init (void ) +{ +pr_info ("init\n" );Drop these. They are just noise.
Right, it's just noise, will remove.
Thank you again for kind review, Jonathan!
Thanks,
SeongJae Park
Quoted 17 lines
Quoted 16 lines
mm/damon.c new file +15
-0+ +return 0 ; +} + +static void __exit damon_exit(void) +{ +pr_info ("exit\n" ); +} + +module_init (damon_init); +module_exit (damon_exit); + +MODULE_LICENSE ("GPL" ); +MODULE_AUTHOR ("SeongJae Park <[email protected]>" ); +MODULE_DESCRIPTION ("DAMON: Data Access MONitor" );
PATCH v6 2/14 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.
This commit also exports lookup_page_ext() to GPL modules because DAMON uses the function but also supports the module build.
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.
--- mm/damon.c | 509 ++++++++++++++++++++++++++++++++++++++++++++++++++ mm/page_ext.c | 1 + 2 files changed, 510 insertions(+)
mm/damon.c +509 -0
@@ -9,9 +9,14 @@#define pr_fmt (fmt) "damon: " fmt +#include <linux/delay.h> +#include <linux/kthread.h> #include <linux/mm.h> #include <linux/module.h> +#include <linux/page_idle.h> #include <linux/random.h> +#include <linux/sched/mm.h> +#include <linux/sched/task.h> #include <linux/slab.h> #define damon_get_task_struct (t) \
@@ -51,7 +56,24 @@ 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; +spinlock_t kdamond_lock; +struct rnd_state rndseed;struct list_head tasks_list;/* 'damon_task' objects */
@@ -204,6 +226,493 @@ static unsigned int nr_damon_regions(struct damon_task *t)return ret; } +/* +* Get the mm_struct of the given task +* +* Callser should put the mm_struct after use, unless it is NULL. +* +* Returns the mm_struct of the task on success, NULL on failure +*/ +static struct mm_struct *damon_get_mm (struct damon_task *t) +{ +struct task_struct *task; +struct mm_struct *mm; + + task =damon_get_task_struct (t); +if (!task) +return NULL ; + + mm =get_task_mm (task); +put_task_struct (task); +return mm; +} + +/* +* Size-evenly split a region into 'nr_pieces' small regions +* +* Returns 0 on success, or negative error code otherwise. +*/ +static int damon_split_region_evenly (struct damon_ctx *ctx, +struct damon_region *r,unsigned int nr_pieces) +{ +unsigned long sz_orig, sz_piece, orig_end; +struct damon_region *piece =NULL , *next; +unsigned long start; + +if (!r || !nr_pieces) +return -EINVAL ; + + orig_end = r->vm_end; + sz_orig = r->vm_end - r->vm_start; + sz_piece = sz_orig / nr_pieces; + +if (!sz_piece) +return -EINVAL ; + + r->vm_end = r->vm_start + sz_piece; + next =damon_next_region (r); +for (start = r->vm_end; start + sz_piece <= orig_end; + start += sz_piece) { + piece =damon_new_region (ctx, start, start + sz_piece); +damon_add_region (piece, r, next); + r = piece; + } +if (piece) + piece->vm_end = orig_end; +return 0 ; +} + +struct region { +unsigned long start; +unsigned long end; +}; + +static unsigned long sz_region (struct region *r) +{ +return r->end - r->start; +} + +static void swap_regions (struct region *r1,struct region *r2) +{ +struct region tmp; + + tmp = *r1; + *r1 = *r2; + *r2 = tmp; +} + +/* +* Find the three regions in an address space +* +* vma the head vma of the target address space +* regions an array of three 'struct region's that results will be saved +* +* This function receives an address space and finds three regions in it which +* separated by the two biggest unmapped regions in the space. Please refer to +* below comments of 'damon_init_regions_of()' function to know why this is +* necessary. +* +* Returns 0 if success, or negative error code otherwise. +*/ +static int damon_three_regions_in_vmas (struct vm_area_struct *vma, +struct region regions[3 ]) +{ +struct region gap = {0 ,}, first_gap = {0 ,}, second_gap = {0 ,}; +struct vm_area_struct *last_vma =NULL ; +unsigned long start =0 ; + +/* Find two biggest gaps so that first_gap > second_gap > others */ +for (; vma; vma = vma->vm_next) { +if (!last_vma) { + start = vma->vm_start; + last_vma = vma; +continue ; + } + gap.start = last_vma->vm_end; + gap.end = vma->vm_start; +if (sz_region (&gap) >sz_region (&second_gap)) { +swap_regions (&gap, &second_gap); +if (sz_region (&second_gap) >sz_region (&first_gap)) +swap_regions (&second_gap, &first_gap); + } + last_vma = vma; + } + +if (!sz_region (&second_gap) || !sz_region (&first_gap)) +return -EINVAL ; + +/* Sort the two biggest gaps by address */ +if (first_gap.start > second_gap.start) +swap_regions (&first_gap, &second_gap); + +/* Store the result */ + regions[0 ].start = start; + regions[0 ].end = first_gap.start; + regions[1 ].start = first_gap.end; + regions[1 ].end = second_gap.start; + regions[2 ].start = second_gap.end; + regions[2 ].end = last_vma->vm_end; + +return 0 ; +} + +/* +* Get the three regions in the given task +* +* Returns 0 on success, negative error code otherwise. +*/ +static int damon_three_regions_of (struct damon_task *t, +struct region regions[3 ]) +{ +struct mm_struct *mm; +int ret; + + mm =damon_get_mm (t); +if (!mm) +return -EINVAL ; + +down_read (&mm->mmap_sem); + ret =damon_three_regions_in_vmas (mm->mmap, regions); +up_read (&mm->mmap_sem); + +mmput (mm); +return ret; +} + +/* +* Initialize the monitoring target regions for the given task +* +* t the given target task +* +* Because only a number of small portions of the entire address space +* is acutally mapped to the memory and accessed, monitoring the unmapped +* regions is wasteful. That said, because we can deal with small noises, +* tracking every mapping is not strictly required but could even incur a high +* overhead if the mapping frequently changes or the number of mappings is +* high. Nonetheless, this may seems very weird. DAMON's dynamic regions +* adjustment mechanism, which will be implemented with following commit will +* make this more sense. +* +* For the reason, we convert 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. In detail, this function first identifies the start and the +* end of the mappings and the two biggest unmapped areas of the address space. +* Then, it constructs the three regions as below: +* +* [mappings[0]->start, big_two_unmapped_areas[0]->start) +* [big_two_unmapped_areas[0]->end, big_two_unmapped_areas[1]->start) +* [big_two_unmapped_areas[1]->end, mappings[nr_mappings - 1]->end) +* +* As usual memory map of processes is as below, 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. +* +* <heap> +* <BIG UNMAPPED REGION 1> +* <uppermost mmap()-ed region> +* (other mmap()-ed regions and small unmapped regions) +* <lowermost mmap()-ed region> +* <BIG UNMAPPED REGION 2> +* <stack> +*/ +static void damon_init_regions_of (struct damon_ctx *c,struct damon_task *t) +{ +struct damon_region *r; +struct region regions[3 ]; +int i; + +if (damon_three_regions_of (t, regions)) { +pr_err ("Failed to get three regions of task %lu\n" , t->pid); +return ; + } + +/* Set the initial three regions of the task */ +for (i =0 ; i <3 ; i++) { + r =damon_new_region (c, regions[i].start, regions[i].end); +damon_add_region_tail (r, t); + } + +/* Split the middle region into 'min_nr_regions - 2' regions */ + r =damon_nth_region_of (t,1 ); +if (damon_split_region_evenly (c, r, c->min_nr_regions -2 )) +pr_warn ("Init middle region failed to be split\n" ); +} + +/* Initialize '->regions_list' of every task */ +static void kdamond_init_regions (struct damon_ctx *ctx) +{ +struct damon_task *t; + +damon_for_each_task (ctx, t) +damon_init_regions_of (ctx, t); +} + +/* +* Check whether the given region has accessed since the last check +* +* mm 'mm_struct' for the given virtual address space +* r the region to be checked +*/ +static void kdamond_check_access (struct damon_ctx *ctx, +struct mm_struct *mm,struct damon_region *r) +{ +pte_t *pte =NULL ; +pmd_t *pmd =NULL ; +spinlock_t *ptl; + +if (follow_pte_pmd (mm, r->sampling_addr,NULL , &pte, &pmd, &ptl)) + goto mkold; + +/* Read the page table access bit of the page */ +if (pte &&pte_young (*pte)) + r->nr_accesses++; +#ifdef CONFIG_TRANSPARENT_HUGEPAGE + else if (pmd && pmd_young(*pmd)) + r->nr_accesses++; +#endif /* CONFIG_TRANSPARENT_HUGEPAGE */ + +spin_unlock (ptl); + +mkold: +/* mkold next target */ + r->sampling_addr =damon_rand (ctx, r->vm_start, r->vm_end); + +if (follow_pte_pmd (mm, r->sampling_addr,NULL , &pte, &pmd, &ptl)) +return ; + +if (pte) { +if (pte_young (*pte)) { +clear_page_idle (pte_page (*pte)); +set_page_young (pte_page (*pte)); + } + *pte =pte_mkold (*pte); + } +#ifdef CONFIG_TRANSPARENT_HUGEPAGE + else if (pmd) { +if (pmd_young (*pmd)) { +clear_page_idle (pmd_page (*pmd)); +set_page_young (pmd_page (*pmd)); + } + *pmd =pmd_mkold (*pmd); + } +#endif + +spin_unlock (ptl); +} + +/* +* Check whether a time interval is elapsed +* +* baseline the time to check whether the interval has elapsed since +* interval the time interval (microseconds) +* +* See whether the given time interval has passed since the given baseline +* time. If so, it also updates the baseline to current time for next check. +* +* Returns true if the time interval has passed, or false otherwise. +*/ +static bool damon_check_reset_time_interval (struct timespec64 *baseline, +unsigned long interval) +{ +struct timespec64 now; + +ktime_get_coarse_ts64 (&now); +if ((timespec64_to_ns (&now) -timespec64_to_ns (baseline)) < + interval *1000 ) +return false; + *baseline = now; +return true; +} + +/* +* Check whether it is time to flush the aggregated information +*/ +static bool kdamond_aggregate_interval_passed (struct damon_ctx *ctx) +{ +return damon_check_reset_time_interval (&ctx->last_aggregation, + ctx->aggr_interval); +} + +/* +* Reset the aggregated monitoring results +*/ +static void kdamond_flush_aggregated (struct damon_ctx *c) +{ +struct damon_task *t; +struct damon_region *r; + +damon_for_each_task (c, t) { +damon_for_each_region (r, t) + r->nr_accesses =0 ; + } +} + +/* +* Check whether current monitoring should be stopped +* +* If users asked to stop, need stop. Even though no user has asked to stop, +* need stop if every target task has dead. +* +* Returns true if need to stop current monitoring. +*/ +static bool kdamond_need_stop (struct damon_ctx *ctx) +{ +struct damon_task *t; +struct task_struct *task; +bool stop; + +spin_lock (&ctx->kdamond_lock); + stop = ctx->kdamond_stop; +spin_unlock (&ctx->kdamond_lock); +if (stop) +return true; + +damon_for_each_task (ctx, t) { + task =damon_get_task_struct (t); +if (task) { +put_task_struct (task); +return false; + } + } + +return true; +} + +/* +* The monitoring daemon that runs as a kernel thread +*/ +static int kdamond_fn (void *data) +{ +struct damon_ctx *ctx = (struct damon_ctx *)data; +struct damon_task *t; +struct damon_region *r, *next; +struct mm_struct *mm; + +pr_info ("kdamond (%d) starts\n" , ctx->kdamond->pid); +kdamond_init_regions (ctx); +while (!kdamond_need_stop (ctx)) { +damon_for_each_task (ctx, t) { + mm =damon_get_mm (t); +if (!mm) +continue ; +damon_for_each_region (r, t) +kdamond_check_access (ctx, mm, r); +mmput (mm); + } + +if (kdamond_aggregate_interval_passed (ctx)) +kdamond_flush_aggregated (ctx); + +usleep_range (ctx->sample_interval, ctx->sample_interval +1 ); + } +damon_for_each_task (ctx, t) { +damon_for_each_region_safe (r, next, t) +damon_destroy_region (r); + } +pr_info ("kdamond (%d) finishes\n" , ctx->kdamond->pid); +spin_lock (&ctx->kdamond_lock); + ctx->kdamond =NULL ; +spin_unlock (&ctx->kdamond_lock); +return 0 ; +} + +/* +* Controller functions +*/ + +/* +* Start or stop the kdamond +* +* Returns 0 if success, negative error code otherwise. +*/ +static int damon_turn_kdamond (struct damon_ctx *ctx,bool on) +{ +spin_lock (&ctx->kdamond_lock); + ctx->kdamond_stop = !on; +if (!ctx->kdamond && on) { + ctx->kdamond =kthread_run (kdamond_fn, ctx,"kdamond" ); +if (!ctx->kdamond) + goto fail; + goto success; + } +if (ctx->kdamond && !on) { +spin_unlock (&ctx->kdamond_lock); +while (true) { +spin_lock (&ctx->kdamond_lock); +if (!ctx->kdamond) + goto success; +spin_unlock (&ctx->kdamond_lock); + +usleep_range (ctx->sample_interval, + ctx->sample_interval *2 ); + } + } + +/* tried to turn on while turned on, or turn off while turned off */ + +fail: +spin_unlock (&ctx->kdamond_lock); +return -EINVAL ; + +success: +spin_unlock (&ctx->kdamond_lock); +return 0 ; +} + +/* +* This function should not be called while the kdamond is running. +*/ +static int damon_set_pids (struct damon_ctx *ctx, +unsigned long *pids,ssize_t nr_pids) +{ +ssize_t i; +struct damon_task *t, *next; + +damon_for_each_task_safe (ctx, t, next) +damon_destroy_task (t); + +for (i =0 ; i < nr_pids; i++) { + t =damon_new_task (pids[i]); +if (!t) { +pr_err ("Failed to alloc damon_task\n" ); +return -ENOMEM ; + } +damon_add_task_tail (ctx, t); + } + +return 0 ; +} + +/* +* Set attributes for the monitoring +* +* sample_int time interval between samplings +* aggr_int time interval between aggregations +* min_nr_reg minimal number of regions +* +* This function should not be called while the kdamond is running. +* Every time interval is in micro-seconds. +* +* Returns 0 on success, negative error code otherwise. +*/ +static int damon_set_attrs (struct damon_ctx *ctx,unsigned long sample_int, +unsigned long aggr_int,unsigned long min_nr_reg) +{ +if (min_nr_reg <3 ) { +pr_err ("min_nr_regions (%lu) should be bigger than 2\n" , + min_nr_reg); +return -EINVAL ; + } + + ctx->sample_interval = sample_int; + ctx->aggr_interval = aggr_int; + ctx->min_nr_regions = min_nr_reg; +return 0 ; +} +static int __init damon_init (void ) {pr_info ("init\n" );
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
Re: [PATCH v6 02/14] mm/damon: Implement region based sampling
Quoted 9 lines · On Mon, 24 Feb 2020 13:30:35 +0100 SeongJae Park <[email protected]> wrote:
From: 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.
This commit also exports
lookup_page_ext()to GPL modules because DAMON uses the function but also supports the module build.
Do that as a separate patch before this one. Makes it easy to spot.
Quoted 33 lines
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.
Quoted 5 lines
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.
Signed-off-by SeongJae Park <[email protected]>
Various things inline. In particularly can you make use of standard kthread_stop infrastructure rather than rolling your own?
Quoted 50 lines
--- mm/damon.c | 509 ++++++++++++++++++++++++++++++++++++++++++++++++++ mm/page_ext.c | 1 + 2 files changed, 510 insertions(+)mm/damon.c +22
-0@@ -9,9 +9,14 @@#define pr_fmt (fmt) "damon: " fmt +#include <linux/delay.h> +#include <linux/kthread.h> #include <linux/mm.h> #include <linux/module.h> +#include <linux/page_idle.h> #include <linux/random.h> +#include <linux/sched/mm.h> +#include <linux/sched/task.h> #include <linux/slab.h> #define damon_get_task_struct (t) \@@ -51,7 +56,24 @@ 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; +spinlock_t kdamond_lock; +struct rnd_state rndseed;struct list_head tasks_list;/* 'damon_task' objects */
mm/damon.c static unsigned int nr_damon_regions(struct damon_task *t) · line 232
Quoted 7 lines
mm/damon.c +4
-0@@ -204,6 +226,493 @@ static unsigned int nr_damon_regions(struct damon_task *t)return ret; } +/* +* Get the mm_struct of the given task +* +* Callser should put the mm_struct after use, unless it is NULL.
Caller
Quoted 37 lines
mm/damon.c +37
-0+* +* Returns the mm_struct of the task on success, NULL on failure +*/ +static struct mm_struct *damon_get_mm (struct damon_task *t) +{ +struct task_struct *task; +struct mm_struct *mm; + + task =damon_get_task_struct (t); +if (!task) +return NULL ; + + mm =get_task_mm (task); +put_task_struct (task); +return mm; +} + +/* +* Size-evenly split a region into 'nr_pieces' small regions +* +* Returns 0 on success, or negative error code otherwise. +*/ +static int damon_split_region_evenly (struct damon_ctx *ctx, +struct damon_region *r,unsigned int nr_pieces) +{ +unsigned long sz_orig, sz_piece, orig_end; +struct damon_region *piece =NULL , *next; +unsigned long start; + +if (!r || !nr_pieces) +return -EINVAL ; + + orig_end = r->vm_end; + sz_orig = r->vm_end - r->vm_start; + sz_piece = sz_orig / nr_pieces; + +if (!sz_piece)
mm/damon.c static unsigned int nr_damon_regions(struct damon_task *t) · line 279
Quoted 10 lines
mm/damon.c +10
-0+return -EINVAL ; + + r->vm_end = r->vm_start + sz_piece; + next =damon_next_region (r); +for (start = r->vm_end; start + sz_piece <= orig_end; + start += sz_piece) { + piece =damon_new_region (ctx, start, start + sz_piece); +damon_add_region (piece, r, next); + r = piece; + }
I'd add a comment here. I think this next bit is to catch any rounding error holes, but I'm not 100% sure.
mm/damon.c static unsigned int nr_damon_regions(struct damon_task *t) · line 281
Quoted 2 lines
mm/damon.c +2
-0+if (piece) + piece->vm_end = orig_end;
blank line here.
Quoted 97 lines
mm/damon.c +97
-0+return 0 ; +} + +struct region { +unsigned long start; +unsigned long end; +}; + +static unsigned long sz_region (struct region *r) +{ +return r->end - r->start; +} + +static void swap_regions (struct region *r1,struct region *r2) +{ +struct region tmp; + + tmp = *r1; + *r1 = *r2; + *r2 = tmp; +} + +/* +* Find the three regions in an address space +* +* vma the head vma of the target address space +* regions an array of three 'struct region's that results will be saved +* +* This function receives an address space and finds three regions in it which +* separated by the two biggest unmapped regions in the space. Please refer to +* below comments of 'damon_init_regions_of()' function to know why this is +* necessary. +* +* Returns 0 if success, or negative error code otherwise. +*/ +static int damon_three_regions_in_vmas (struct vm_area_struct *vma, +struct region regions[3 ]) +{ +struct region gap = {0 ,}, first_gap = {0 ,}, second_gap = {0 ,}; +struct vm_area_struct *last_vma =NULL ; +unsigned long start =0 ; + +/* Find two biggest gaps so that first_gap > second_gap > others */ +for (; vma; vma = vma->vm_next) { +if (!last_vma) { + start = vma->vm_start; + last_vma = vma; +continue ; + } + gap.start = last_vma->vm_end; + gap.end = vma->vm_start; +if (sz_region (&gap) >sz_region (&second_gap)) { +swap_regions (&gap, &second_gap); +if (sz_region (&second_gap) >sz_region (&first_gap)) +swap_regions (&second_gap, &first_gap); + } + last_vma = vma; + } + +if (!sz_region (&second_gap) || !sz_region (&first_gap)) +return -EINVAL ; + +/* Sort the two biggest gaps by address */ +if (first_gap.start > second_gap.start) +swap_regions (&first_gap, &second_gap); + +/* Store the result */ + regions[0 ].start = start; + regions[0 ].end = first_gap.start; + regions[1 ].start = first_gap.end; + regions[1 ].end = second_gap.start; + regions[2 ].start = second_gap.end; + regions[2 ].end = last_vma->vm_end; + +return 0 ; +} + +/* +* Get the three regions in the given task +* +* Returns 0 on success, negative error code otherwise. +*/ +static int damon_three_regions_of (struct damon_task *t, +struct region regions[3 ]) +{ +struct mm_struct *mm; +int ret; + + mm =damon_get_mm (t); +if (!mm) +return -EINVAL ; + +down_read (&mm->mmap_sem); + ret =damon_three_regions_in_vmas (mm->mmap, regions); +up_read (&mm->mmap_sem); + +mmput (mm);
mm/damon.c static unsigned int nr_damon_regions(struct damon_task *t) · line 388
Quoted 10 lines
mm/damon.c +10
-0+return ret; +} + +/* +* Initialize the monitoring target regions for the given task +* +* t the given target task +* +* Because only a number of small portions of the entire address space +* is acutally mapped to the memory and accessed, monitoring the unmapped
actually
Quoted 56 lines
mm/damon.c +56
-0+* regions is wasteful. That said, because we can deal with small noises, +* tracking every mapping is not strictly required but could even incur a high +* overhead if the mapping frequently changes or the number of mappings is +* high. Nonetheless, this may seems very weird. DAMON's dynamic regions +* adjustment mechanism, which will be implemented with following commit will +* make this more sense. +* +* For the reason, we convert 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. In detail, this function first identifies the start and the +* end of the mappings and the two biggest unmapped areas of the address space. +* Then, it constructs the three regions as below: +* +* [mappings[0]->start, big_two_unmapped_areas[0]->start) +* [big_two_unmapped_areas[0]->end, big_two_unmapped_areas[1]->start) +* [big_two_unmapped_areas[1]->end, mappings[nr_mappings - 1]->end) +* +* As usual memory map of processes is as below, 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. +* +* <heap> +* <BIG UNMAPPED REGION 1> +* <uppermost mmap()-ed region> +* (other mmap()-ed regions and small unmapped regions) +* <lowermost mmap()-ed region> +* <BIG UNMAPPED REGION 2> +* <stack> +*/ +static void damon_init_regions_of (struct damon_ctx *c,struct damon_task *t) +{ +struct damon_region *r; +struct region regions[3 ]; +int i; + +if (damon_three_regions_of (t, regions)) { +pr_err ("Failed to get three regions of task %lu\n" , t->pid); +return ; + } + +/* Set the initial three regions of the task */ +for (i =0 ; i <3 ; i++) { + r =damon_new_region (c, regions[i].start, regions[i].end); +damon_add_region_tail (r, t); + } + +/* Split the middle region into 'min_nr_regions - 2' regions */ + r =damon_nth_region_of (t,1 ); +if (damon_split_region_evenly (c, r, c->min_nr_regions -2 )) +pr_warn ("Init middle region failed to be split\n" ); +} + +/* Initialize '->regions_list' of every task */
mm/damon.c static unsigned int nr_damon_regions(struct damon_task *t) · line 454
Quoted 10 lines
mm/damon.c +10
-0+static void kdamond_init_regions (struct damon_ctx *ctx) +{ +struct damon_task *t; + +damon_for_each_task (ctx, t) +damon_init_regions_of (ctx, t); +} + +/* +* Check whether the given region has accessed since the last check
Should also make clear that this sets us up for the next access check at a different memory address it the region.
Given the lack of connection between activities perhaps just split this into two functions that are always called next to each other.
Quoted 8 lines
mm/damon.c +8
-0+* +* mm 'mm_struct' for the given virtual address space +* r the region to be checked +*/ +static void kdamond_check_access (struct damon_ctx *ctx, +struct mm_struct *mm,struct damon_region *r) +{ +pte_t *pte =NULL ;
mm/damon.c static unsigned int nr_damon_regions(struct damon_task *t) · line 472
Quoted 10 lines
mm/damon.c +10
-0+pmd_t *pmd =NULL ; +spinlock_t *ptl; + +if (follow_pte_pmd (mm, r->sampling_addr,NULL , &pte, &pmd, &ptl)) + goto mkold; + +/* Read the page table access bit of the page */ +if (pte &&pte_young (*pte)) + r->nr_accesses++; +#ifdef CONFIG_TRANSPARENT_HUGEPAGE
Is it worth having this protection? Seems likely to have only a very small influence on performance and makes it a little harder to reason about the code.
Quoted 25 lines
mm/damon.c +25
-0+ else if (pmd && pmd_young(*pmd)) + r->nr_accesses++; +#endif /* CONFIG_TRANSPARENT_HUGEPAGE */ + +spin_unlock (ptl); + +mkold: +/* mkold next target */ + r->sampling_addr =damon_rand (ctx, r->vm_start, r->vm_end); + +if (follow_pte_pmd (mm, r->sampling_addr,NULL , &pte, &pmd, &ptl)) +return ; + +if (pte) { +if (pte_young (*pte)) { +clear_page_idle (pte_page (*pte)); +set_page_young (pte_page (*pte)); + } + *pte =pte_mkold (*pte); + } +#ifdef CONFIG_TRANSPARENT_HUGEPAGE + else if (pmd) { +if (pmd_young (*pmd)) { +clear_page_idle (pmd_page (*pmd)); +set_page_young (pmd_page (*pmd));
mm/damon.c static unsigned int nr_damon_regions(struct damon_task *t) · line 507
Quoted 10 lines
mm/damon.c +10
-0+ } + *pmd =pmd_mkold (*pmd); + } +#endif + +spin_unlock (ptl); +} + +/* +* Check whether a time interval is elapsed
Another comment block that would be clearer if it was kernel-doc rather than nearly kernel-doc
Quoted 25 lines
mm/damon.c +25
-0+* +* baseline the time to check whether the interval has elapsed since +* interval the time interval (microseconds) +* +* See whether the given time interval has passed since the given baseline +* time. If so, it also updates the baseline to current time for next check. +* +* Returns true if the time interval has passed, or false otherwise. +*/ +static bool damon_check_reset_time_interval (struct timespec64 *baseline, +unsigned long interval) +{ +struct timespec64 now; + +ktime_get_coarse_ts64 (&now); +if ((timespec64_to_ns (&now) -timespec64_to_ns (baseline)) < + interval *1000 ) +return false; + *baseline = now; +return true; +} + +/* +* Check whether it is time to flush the aggregated information +*/
mm/damon.c static unsigned int nr_damon_regions(struct damon_task *t) · line 542
Quoted 10 lines
mm/damon.c +10
-0+static bool kdamond_aggregate_interval_passed (struct damon_ctx *ctx) +{ +return damon_check_reset_time_interval (&ctx->last_aggregation, + ctx->aggr_interval); +} + +/* +* Reset the aggregated monitoring results +*/ +static void kdamond_flush_aggregated (struct damon_ctx *c)
I wouldn't expect a reset function to be called flush.
Quoted 14 lines
mm/damon.c +14
-0+{ +struct damon_task *t; +struct damon_region *r; + +damon_for_each_task (c, t) { +damon_for_each_region (r, t) + r->nr_accesses =0 ; + } +} + +/* +* Check whether current monitoring should be stopped +* +* If users asked to stop, need stop. Even though no user has asked to stop,
mm/damon.c static unsigned int nr_damon_regions(struct damon_task *t) · line 566
Quoted 10 lines
mm/damon.c +10
-0+* need stop if every target task has dead. +* +* Returns true if need to stop current monitoring. +*/ +static bool kdamond_need_stop (struct damon_ctx *ctx) +{ +struct damon_task *t; +struct task_struct *task; +bool stop; +
As below comment asks, can you use kthread_should_stop?
Quoted 13 lines
mm/damon.c +13
-0+spin_lock (&ctx->kdamond_lock); + stop = ctx->kdamond_stop; +spin_unlock (&ctx->kdamond_lock); +if (stop) +return true; + +damon_for_each_task (ctx, t) { + task =damon_get_task_struct (t); +if (task) { +put_task_struct (task); +return false; + } + }
mm/damon.c static unsigned int nr_damon_regions(struct damon_task *t) · line 589
Quoted 10 lines
mm/damon.c +10
-0+ +return true; +} + +/* +* The monitoring daemon that runs as a kernel thread +*/ +static int kdamond_fn (void *data) +{ +struct damon_ctx *ctx = (struct damon_ctx *)data;
Never any need to explicitly cast a void * to some other pointer type. (C spec)
struct damon_ctx *ctx = data;
Quoted 10 lines
mm/damon.c +10
-0+struct damon_task *t; +struct damon_region *r, *next; +struct mm_struct *mm; + +pr_info ("kdamond (%d) starts\n" , ctx->kdamond->pid); +kdamond_init_regions (ctx); +while (!kdamond_need_stop (ctx)) { +damon_for_each_task (ctx, t) { + mm =damon_get_mm (t); +if (!mm)
mm/damon.c static unsigned int nr_damon_regions(struct damon_task *t) · line 609
Quoted 10 lines
mm/damon.c +10
-0+continue ; +damon_for_each_region (r, t) +kdamond_check_access (ctx, mm, r); +mmput (mm); + } + +if (kdamond_aggregate_interval_passed (ctx)) +kdamond_flush_aggregated (ctx); + +usleep_range (ctx->sample_interval, ctx->sample_interval +1 );
Is there any purpose in using a range for such a narrow window?
mm/damon.c static unsigned int nr_damon_regions(struct damon_task *t) · line 615
Quoted 6 lines
mm/damon.c +6
-0+ } +damon_for_each_task (ctx, t) { +damon_for_each_region_safe (r, next, t) +damon_destroy_region (r); + } +pr_info ("kdamond (%d) finishes\n" , ctx->kdamond->pid);
Feels like noise. I'd drop tis to pr_debug.
mm/damon.c static unsigned int nr_damon_regions(struct damon_task *t) · line 618
Quoted 3 lines
mm/damon.c +3
-0+spin_lock (&ctx->kdamond_lock); + ctx->kdamond =NULL ; +spin_unlock (&ctx->kdamond_lock);
blank line.
Quoted 6 lines
mm/damon.c +6
-0+return 0 ; +} + +/* +* Controller functions +*/
mm/damon.c static unsigned int nr_damon_regions(struct damon_task *t) · line 634
Quoted 10 lines
mm/damon.c +10
-0+ +/* +* Start or stop the kdamond +* +* Returns 0 if success, negative error code otherwise. +*/ +static int damon_turn_kdamond (struct damon_ctx *ctx,bool on) +{ +spin_lock (&ctx->kdamond_lock); + ctx->kdamond_stop = !on;
Can't use the kthread_stop / kthread_should_stop approach?
mm/damon.c static unsigned int nr_damon_regions(struct damon_task *t) · line 639
Quoted 5 lines
mm/damon.c +5
-0+if (!ctx->kdamond && on) { + ctx->kdamond =kthread_run (kdamond_fn, ctx,"kdamond" ); +if (!ctx->kdamond) + goto fail; + goto success;
cleaner as
int ret = 0; above then
if (!ctx->kdamond) ret = -EINVAL; goto unlock;
with
unlock:
spin_unlock(&ctx->dmanond_lock); return ret;
mm/damon.c static unsigned int nr_damon_regions(struct damon_task *t) · line 643
Quoted 4 lines
mm/damon.c +4
-0+ } +if (ctx->kdamond && !on) { +spin_unlock (&ctx->kdamond_lock); +while (true) {
An unbounded loop is probably a bad idea.
Quoted 36 lines
mm/damon.c +36
-0+spin_lock (&ctx->kdamond_lock); +if (!ctx->kdamond) + goto success; +spin_unlock (&ctx->kdamond_lock); + +usleep_range (ctx->sample_interval, + ctx->sample_interval *2 ); + } + } + +/* tried to turn on while turned on, or turn off while turned off */ + +fail: +spin_unlock (&ctx->kdamond_lock); +return -EINVAL ; + +success: +spin_unlock (&ctx->kdamond_lock); +return 0 ; +} + +/* +* This function should not be called while the kdamond is running. +*/ +static int damon_set_pids (struct damon_ctx *ctx, +unsigned long *pids,ssize_t nr_pids) +{ +ssize_t i; +struct damon_task *t, *next; + +damon_for_each_task_safe (ctx, t, next) +damon_destroy_task (t); + +for (i =0 ; i < nr_pids; i++) { + t =damon_new_task (pids[i]); +if (!t) {
mm/damon.c static unsigned int nr_damon_regions(struct damon_task *t) · line 689
Quoted 10 lines
mm/damon.c +10
-0+pr_err ("Failed to alloc damon_task\n" ); +return -ENOMEM ; + } +damon_add_task_tail (ctx, t); + } + +return 0 ; +} + +/*
This is kind of similar to kernel-doc formatting. Might as well just make it kernel-doc!
Quoted 13 lines
mm/damon.c +13
-0+* Set attributes for the monitoring +* +* sample_int time interval between samplings +* aggr_int time interval between aggregations +* min_nr_reg minimal number of regions +* +* This function should not be called while the kdamond is running. +* Every time interval is in micro-seconds. +* +* Returns 0 on success, negative error code otherwise. +*/ +static int damon_set_attrs (struct damon_ctx *ctx,unsigned long sample_int, +unsigned long aggr_int,unsigned long min_nr_reg)
mm/damon.c static unsigned int nr_damon_regions(struct damon_task *t) · line 712
Quoted 10 lines
mm/damon.c +10
-0+{ +if (min_nr_reg <3 ) { +pr_err ("min_nr_regions (%lu) should be bigger than 2\n" , + min_nr_reg); +return -EINVAL ; + } + + ctx->sample_interval = sample_int; + ctx->aggr_interval = aggr_int; + ctx->min_nr_regions = min_nr_reg;
blank line helps readability a tiny little bit.
Quoted 18 lines
mm/damon.c +3
-0+return 0 ; +} +static int __init damon_init (void ) {pr_info ("init\n" );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) {
Re: Re: [PATCH v6 02/14] mm/damon: Implement region based sampling
Added replies to your every comment in line below. I agree to your whole opinions, will apply those in next spin! :)
Quoted 10 lines · On Tue, 10 Mar 2020 08:57:21 +0000 Jonathan Cameron…
Quoted 7 lines · On Mon, 24 Feb 2020 13:30:35 +0100 SeongJae Park <[email protected]> wrote:
From: 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.
Quoted 4 lines
Quoted 2 lines
This commit also exports
lookup_page_ext()to GPL modules because DAMON uses the function but also supports the module build.Do that as a separate patch before this one. Makes it easy to spot.
Agreed, will do so.
Quoted 2 lines
Quoted 2 lines
[...]
Quoted 3 lines
Various things inline. In particularly can you make use of standard
kthread_stopinfrastructure rather than rolling your own?
Nice suggestion! That will be much better, will use it.
Quoted 12 lines
Quoted 12 lines
--- mm/damon.c | 509 ++++++++++++++++++++++++++++++++++++++++++++++++++ mm/page_ext.c | 1 + 2 files changed, 510 insertions(+)mm/damon.c +0
-0@@ -9,9 +9,14 @@
[...]
Quoted 6 lines
Quoted 4 lines
+/*
+ * Get themm_structof the given task
+ *
+ * Callser should put themm_structafter use, unless it is NULL.Caller
Good eye! Will fix it.
Quoted 43 lines
Quoted 43 lines
+ *
+ * Returns themm_structof the task on success, NULL on failure
+ */mm/damon.c +39
-0+static struct mm_struct *damon_get_mm (struct damon_task *t) +{ +struct task_struct *task; +struct mm_struct *mm; + + task =damon_get_task_struct (t); +if (!task) +return NULL ; + + mm =get_task_mm (task); +put_task_struct (task); +return mm; +} + +/* +* Size-evenly split a region into 'nr_pieces' small regions +* +* Returns 0 on success, or negative error code otherwise. +*/ +static int damon_split_region_evenly (struct damon_ctx *ctx, +struct damon_region *r,unsigned int nr_pieces) +{ +unsigned long sz_orig, sz_piece, orig_end; +struct damon_region *piece =NULL , *next; +unsigned long start; + +if (!r || !nr_pieces) +return -EINVAL ; + + orig_end = r->vm_end; + sz_orig = r->vm_end - r->vm_start; + sz_piece = sz_orig / nr_pieces; + +if (!sz_piece) +return -EINVAL ; + + r->vm_end = r->vm_start + sz_piece; + next =damon_next_region (r); + for (start = r->vm_end; start + sz_piece <= orig_end;
Quoted 8 lines
mm/damon.c static unsigned int nr_damon_regions(struct damon_task *t) · line 279
Quoted 5 lines
mm/damon.c +5
-0+ start += sz_piece) { + piece =damon_new_region (ctx, start, start + sz_piece); +damon_add_region (piece, r, next); + r = piece; + }I'd add a comment here. I think this next bit is to catch any rounding error holes, but I'm not 100% sure.
Yes, will make it clearer.
Quoted 5 lines
mm/damon.c static unsigned int nr_damon_regions(struct damon_task *t) · line 281
Quoted 3 lines
mm/damon.c +2
-0+if (piece) + piece->vm_end = orig_end;blank line here.
Will add.
Quoted 3 lines
Quoted 3 lines
mm/damon.c +2
-0+return 0 ; +}
[...]
Quoted 9 lines
Quoted 7 lines
+/*
+ * Initialize the monitoring target regions for the given task
+ *
+ * t the given target task
+ *
+ * Because only a number of small portions of the entire address space
+ * is acutally mapped to the memory and accessed, monitoring the unmappedactually
Good eye! Will consider adding these in 'scripts/spelling.txt'.
Quoted 1 line
[...]
Quoted 8 lines
Quoted 2 lines
+/*
+ * Check whether the given region has accessed since the last checkShould also make clear that this sets us up for the next access check at a different memory address it the region.
Given the lack of connection between activities perhaps just split this into two functions that are always called next to each other.
Will make the description more clearer as suggested.
Also, I found that I'm not clearing *pte and *pmd before going 'mkold', thanks to this comment. Will fix it, either.
Quoted 14 lines
Quoted 14 lines
+ *
+ * mm 'mm_struct' for the given virtual address space
+ * r the region to be checked
+ */mm/damon.c +9
-0+static void kdamond_check_access (struct damon_ctx *ctx, +struct mm_struct *mm,struct damon_region *r) +{ +pte_t *pte =NULL ; +pmd_t *pmd =NULL ; +spinlock_t *ptl; + +if (follow_pte_pmd (mm, r->sampling_addr,NULL , &pte, &pmd, &ptl)) + goto mkold;
Quoted 8 lines
mm/damon.c static unsigned int nr_damon_regions(struct damon_task *t) · line 472
Quoted 5 lines
mm/damon.c +5
-0+ +/* Read the page table access bit of the page */ +if (pte &&pte_young (*pte)) + r->nr_accesses++; +#ifdef CONFIG_TRANSPARENT_HUGEPAGE Is it worth having this protection? Seems likely to have only a very small influence on performance and makes it a little harder to reason about the code.
It was necessary for addressing 'implicit declaration' problem of 'pmd_young()' and 'pmd_mkold()' for build of DAMON on several architectures including User Mode Linux.
Will modularize the code for better readability.
Quoted 31 lines
Quoted 31 lines
mm/damon.c +30
-0+ else if (pmd && pmd_young(*pmd)) + r->nr_accesses++; +#endif /* CONFIG_TRANSPARENT_HUGEPAGE */ + +spin_unlock (ptl); + +mkold: +/* mkold next target */ + r->sampling_addr =damon_rand (ctx, r->vm_start, r->vm_end); + +if (follow_pte_pmd (mm, r->sampling_addr,NULL , &pte, &pmd, &ptl)) +return ; + +if (pte) { +if (pte_young (*pte)) { +clear_page_idle (pte_page (*pte)); +set_page_young (pte_page (*pte)); + } + *pte =pte_mkold (*pte); + } +#ifdef CONFIG_TRANSPARENT_HUGEPAGE + else if (pmd) { +if (pmd_young (*pmd)) { +clear_page_idle (pmd_page (*pmd)); +set_page_young (pmd_page (*pmd)); + } + *pmd =pmd_mkold (*pmd); + } +#endif +
Quoted 8 lines
mm/damon.c static unsigned int nr_damon_regions(struct damon_task *t) · line 507
Quoted 5 lines
mm/damon.c +5
-0+spin_unlock (ptl); +} + +/* +* Check whether a time interval is elapsed Another comment block that would be clearer if it was kernel-doc rather than nearly kernel-doc
Will apply the kernel-doc syntax.
Quoted 30 lines
Quoted 30 lines
+ *
+ * baseline the time to check whether the interval has elapsed since
+ * interval the time interval (microseconds)
+ *
+ * See whether the given time interval has passed since the given baseline
+ * time. If so, it also updates the baseline to current time for next check.
+ *
+ * Returns true if the time interval has passed, or false otherwise.
+ */mm/damon.c +20
-0+static bool damon_check_reset_time_interval (struct timespec64 *baseline, +unsigned long interval) +{ +struct timespec64 now; + +ktime_get_coarse_ts64 (&now); +if ((timespec64_to_ns (&now) -timespec64_to_ns (baseline)) < + interval *1000 ) +return false; + *baseline = now; +return true; +} + +/* +* Check whether it is time to flush the aggregated information +*/ +static bool kdamond_aggregate_interval_passed (struct damon_ctx *ctx) +{ +return damon_check_reset_time_interval (&ctx->last_aggregation, + ctx->aggr_interval);
Quoted 8 lines
mm/damon.c static unsigned int nr_damon_regions(struct damon_task *t) · line 542
Quoted 6 lines
mm/damon.c +6
-0+} + +/* +* Reset the aggregated monitoring results +*/ +static void kdamond_flush_aggregated (struct damon_ctx *c)I wouldn't expect a reset function to be called flush.
It will work as flushing in next commit, but it makes no sense now. Will rename it.
Quoted 19 lines
Quoted 19 lines
mm/damon.c +18
-0+{ +struct damon_task *t; +struct damon_region *r; + +damon_for_each_task (c, t) { +damon_for_each_region (r, t) + r->nr_accesses =0 ; + } +} + +/* +* Check whether current monitoring should be stopped +* +* If users asked to stop, need stop. Even though no user has asked to stop, +* need stop if every target task has dead. +* +* Returns true if need to stop current monitoring. +*/
Quoted 8 lines
mm/damon.c static unsigned int nr_damon_regions(struct damon_task *t) · line 566
Quoted 6 lines
mm/damon.c +6
-0+static bool kdamond_need_stop (struct damon_ctx *ctx) +{ +struct damon_task *t; +struct task_struct *task; +bool stop; +As below comment asks, can you use
kthread_should_stop?
Yes, I will.
Quoted 19 lines
Quoted 19 lines
mm/damon.c +18
-0+spin_lock (&ctx->kdamond_lock); + stop = ctx->kdamond_stop; +spin_unlock (&ctx->kdamond_lock); +if (stop) +return true; + +damon_for_each_task (ctx, t) { + task =damon_get_task_struct (t); +if (task) { +put_task_struct (task); +return false; + } + } + +return true; +} + +/*
Quoted 8 lines
mm/damon.c static unsigned int nr_damon_regions(struct damon_task *t) · line 589
Quoted 5 lines
+ * The monitoring daemon that runs as a kernel thread
+ */mm/damon.c +3
-0+static int kdamond_fn (void *data) +{ +struct damon_ctx *ctx = (struct damon_ctx *)data;Never any need to explicitly cast a void * to some other pointer type. (C spec)
Ah, you're right.
Quoted 16 lines
struct damon_ctx *ctx = data;Quoted 14 lines
mm/damon.c +14
-0+struct damon_task *t; +struct damon_region *r, *next; +struct mm_struct *mm; + +pr_info ("kdamond (%d) starts\n" , ctx->kdamond->pid); +kdamond_init_regions (ctx); +while (!kdamond_need_stop (ctx)) { +damon_for_each_task (ctx, t) { + mm =damon_get_mm (t); +if (!mm) +continue ; +damon_for_each_region (r, t) +kdamond_check_access (ctx, mm, r); +mmput (mm);
Quoted 8 lines
mm/damon.c static unsigned int nr_damon_regions(struct damon_task *t) · line 609
Quoted 6 lines
mm/damon.c +6
-0+ } + +if (kdamond_aggregate_interval_passed (ctx)) +kdamond_flush_aggregated (ctx); + +usleep_range (ctx->sample_interval, ctx->sample_interval +1 );Is there any purpose in using a range for such a narrow window?
Actually, it needs to sleep only 'ctx->sample_interval', and thus I set the interval so narrow.
Quoted 9 lines
mm/damon.c static unsigned int nr_damon_regions(struct damon_task *t) · line 615
Quoted 7 lines
mm/damon.c +6
-0+ } +damon_for_each_task (ctx, t) { +damon_for_each_region_safe (r, next, t) +damon_destroy_region (r); + } +pr_info ("kdamond (%d) finishes\n" , ctx->kdamond->pid);Feels like noise. I'd drop tis to
pr_debug.
Agreed, will remove it.
Quoted 6 lines
mm/damon.c static unsigned int nr_damon_regions(struct damon_task *t) · line 618
Quoted 4 lines
mm/damon.c +3
-0+spin_lock (&ctx->kdamond_lock); + ctx->kdamond =NULL ; +spin_unlock (&ctx->kdamond_lock);blank line.
Yup!
Quoted 11 lines
Quoted 11 lines
mm/damon.c +10
-0+return 0 ; +} + +/* +* Controller functions +*/ + +/* +* Start or stop the kdamond +*
Quoted 8 lines
mm/damon.c static unsigned int nr_damon_regions(struct damon_task *t) · line 634
Quoted 6 lines
+ * Returns 0 if success, negative error code otherwise.
+ */mm/damon.c +4
-0+static int damon_turn_kdamond (struct damon_ctx *ctx,bool on) +{ +spin_lock (&ctx->kdamond_lock); + ctx->kdamond_stop = !on;Can't use the
kthread_stop/kthread_should_stopapproach?
Will use it.
Quoted 14 lines
mm/damon.c static unsigned int nr_damon_regions(struct damon_task *t) · line 639
Quoted 6 lines
mm/damon.c +5
-0+if (!ctx->kdamond && on) { + ctx->kdamond =kthread_run (kdamond_fn, ctx,"kdamond" ); +if (!ctx->kdamond) + goto fail; + goto success;cleaner as
int ret = 0; above thenif (!ctx->kdamond) ret = -EINVAL; goto unlock;
Quoted 5 lines
with
unlock:
spin_unlock(&ctx->dmanond_lock); return ret;
Agreed, will change so.
Quoted 7 lines
mm/damon.c static unsigned int nr_damon_regions(struct damon_task *t) · line 643
Quoted 5 lines
mm/damon.c +4
-0+ } +if (ctx->kdamond && !on) { +spin_unlock (&ctx->kdamond_lock); +while (true) {An unbounded loop is probably a bad idea.
Will add clear condition here.
Quoted 42 lines
Quoted 42 lines
mm/damon.c +41
-0+spin_lock (&ctx->kdamond_lock); +if (!ctx->kdamond) + goto success; +spin_unlock (&ctx->kdamond_lock); + +usleep_range (ctx->sample_interval, + ctx->sample_interval *2 ); + } + } + +/* tried to turn on while turned on, or turn off while turned off */ + +fail: +spin_unlock (&ctx->kdamond_lock); +return -EINVAL ; + +success: +spin_unlock (&ctx->kdamond_lock); +return 0 ; +} + +/* +* This function should not be called while the kdamond is running. +*/ +static int damon_set_pids (struct damon_ctx *ctx, +unsigned long *pids,ssize_t nr_pids) +{ +ssize_t i; +struct damon_task *t, *next; + +damon_for_each_task_safe (ctx, t, next) +damon_destroy_task (t); + +for (i =0 ; i < nr_pids; i++) { + t =damon_new_task (pids[i]); +if (!t) { +pr_err ("Failed to alloc damon_task\n" ); +return -ENOMEM ; + } +damon_add_task_tail (ctx, t); + }
Quoted 8 lines
mm/damon.c static unsigned int nr_damon_regions(struct damon_task *t) · line 304
Quoted 5 lines
mm/damon.c +5
-0+ +return 0 ; +} + +/* This is kind of similar to kernel-doc formatting. Might as well just make it kernel-doc!
Agreed, will do so!
Quoted 18 lines
Quoted 18 lines
+ * Set attributes for the monitoring
+ *
+ *sample_inttime interval between samplings
+ *aggr_inttime interval between aggregations
+ *min_nr_regminimal number of regions
+ *
+ * This function should not be called while the kdamond is running.
+ * Every time interval is in micro-seconds.
+ *
+ * Returns 0 on success, negative error code otherwise.
+ */mm/damon.c +6
-0+static int damon_set_attrs (struct damon_ctx *ctx,unsigned long sample_int, +unsigned long aggr_int,unsigned long min_nr_reg) +{ +if (min_nr_reg <3 ) { +pr_err ("min_nr_regions (%lu) should be bigger than 2\n" , + min_nr_reg);
Quoted 8 lines
mm/damon.c static unsigned int nr_damon_regions(struct damon_task *t) · line 712
Quoted 6 lines
mm/damon.c +6
-0+return -EINVAL ; + } + + ctx->sample_interval = sample_int; + ctx->aggr_interval = aggr_int; + ctx->min_nr_regions = min_nr_reg;blank line helps readability a tiny little bit.
Agreed!
Thanks,
SeongJae Park
Quoted 19 lines
Quoted 19 lines
mm/damon.c +3
-0+return 0 ; +} +static int __init damon_init (void ) {pr_info ("init\n" );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) {
Re: [PATCH v6 02/14] mm/damon: Implement region based sampling
Quoted 3 lines · On Tue, 10 Mar 2020 12:52:33 +0100 SeongJae Park <[email protected]> wrote:
Added replies to your every comment in line below. I agree to your whole opinions, will apply those in next spin! :)
One additional question inline that came to mind. Using a single statistic to monitor huge page and normal page hits is going to give us problems I think.
Perhaps I'm missing something?
Quoted 41 lines
Quoted 8 lines
Quoted 2 lines
+/*
+ * Check whether the given region has accessed since the last checkShould also make clear that this sets us up for the next access check at a different memory address it the region.
Given the lack of connection between activities perhaps just split this into two functions that are always called next to each other.
Will make the description more clearer as suggested.
Also, I found that I'm not clearing *pte and *pmd before going 'mkold', thanks to this comment. Will fix it, either.
Quoted 14 lines
Quoted 14 lines
+ *
+ * mm 'mm_struct' for the given virtual address space
+ * r the region to be checked
+ */mm/damon.c +9
-0+static void kdamond_check_access (struct damon_ctx *ctx, +struct mm_struct *mm,struct damon_region *r) +{ +pte_t *pte =NULL ; +pmd_t *pmd =NULL ; +spinlock_t *ptl; + +if (follow_pte_pmd (mm, r->sampling_addr,NULL , &pte, &pmd, &ptl)) + goto mkold;Quoted 8 lines
mm/damon.c static unsigned int nr_damon_regions(struct damon_task *t) · line 472
Quoted 5 lines
mm/damon.c +5
-0+ +/* Read the page table access bit of the page */ +if (pte &&pte_young (*pte)) + r->nr_accesses++; +#ifdef CONFIG_TRANSPARENT_HUGEPAGE Is it worth having this protection? Seems likely to have only a very small influence on performance and makes it a little harder to reason about the code.
It was necessary for addressing 'implicit declaration' problem of '
pmd_young()' and 'pmd_mkold()' for build of DAMON on several architectures including User Mode Linux.
Quoted 5 lines
Will modularize the code for better readability.
Quoted 3 lines
mm/damon.c static unsigned int nr_damon_regions(struct damon_task *t) · line 474
Quoted 3 lines
mm/damon.c +2
-0+else if (pmd &&pmd_young (*pmd)) + r->nr_accesses++;
So we increment a region count by one if we have an access in a huge page, or in a normal page.
If we get a region that has a mixture of the two, this seems likely to give a bad approximation.
Assume the region is accessed 'evenly' but each " 4k page" is only hit 10% of the time (where a hit is in one check period)
If our address in a page, then we'll hit 10% of the time, but if it is in a 2M huge page then we'll hit a much higher percentage of the time.
1 - (0.9^512) ~= 1
Should we look to somehow account for this?
Quoted 31 lines
Quoted 31 lines
Quoted 31 lines
mm/damon.c +31
-0+#endif /* CONFIG_TRANSPARENT_HUGEPAGE */ + +spin_unlock (ptl); + +mkold: +/* mkold next target */ + r->sampling_addr =damon_rand (ctx, r->vm_start, r->vm_end); + +if (follow_pte_pmd (mm, r->sampling_addr,NULL , &pte, &pmd, &ptl)) +return ; + +if (pte) { +if (pte_young (*pte)) { +clear_page_idle (pte_page (*pte)); +set_page_young (pte_page (*pte)); + } + *pte =pte_mkold (*pte); + } +#ifdef CONFIG_TRANSPARENT_HUGEPAGE + else if (pmd) { +if (pmd_young (*pmd)) { +clear_page_idle (pmd_page (*pmd)); +set_page_young (pmd_page (*pmd)); + } + *pmd =pmd_mkold (*pmd); + } +#endif + +spin_unlock (ptl); +} +
Re: Re: [PATCH v6 02/14] mm/damon: Implement region based sampling
Quoted 10 lines · On Tue, 10 Mar 2020 15:55:10 +0000 Jonathan Cameron…
Quoted 3 lines · On Tue, 10 Mar 2020 12:52:33 +0100 SeongJae Park <[email protected]> wrote:
Added replies to your every comment in line below. I agree to your whole opinions, will apply those in next spin! :)
One additional question inline that came to mind. Using a single statistic to monitor huge page and normal page hits is going to give us problems I think.
Ah, you're right!!! This is indeed a critical bug!
Quoted 56 lines
Perhaps I'm missing something?
Quoted 41 lines
Quoted 8 lines
Quoted 2 lines
+/*
+ * Check whether the given region has accessed since the last checkShould also make clear that this sets us up for the next access check at a different memory address it the region.
Given the lack of connection between activities perhaps just split this into two functions that are always called next to each other.
Will make the description more clearer as suggested.
Also, I found that I'm not clearing *pte and *pmd before going 'mkold', thanks to this comment. Will fix it, either.
Quoted 14 lines
Quoted 14 lines
+ *
+ * mm 'mm_struct' for the given virtual address space
+ * r the region to be checked
+ */mm/damon.c +9
-0+static void kdamond_check_access (struct damon_ctx *ctx, +struct mm_struct *mm,struct damon_region *r) +{ +pte_t *pte =NULL ; +pmd_t *pmd =NULL ; +spinlock_t *ptl; + +if (follow_pte_pmd (mm, r->sampling_addr,NULL , &pte, &pmd, &ptl)) + goto mkold;Quoted 8 lines
mm/damon.c static unsigned int nr_damon_regions(struct damon_task *t) · line 472
Quoted 5 lines
mm/damon.c +5
-0+ +/* Read the page table access bit of the page */ +if (pte &&pte_young (*pte)) + r->nr_accesses++; +#ifdef CONFIG_TRANSPARENT_HUGEPAGE Is it worth having this protection? Seems likely to have only a very small influence on performance and makes it a little harder to reason about the code.
It was necessary for addressing 'implicit declaration' problem of '
pmd_young()' and 'pmd_mkold()' for build of DAMON on several architectures including User Mode Linux.Quoted 5 lines
Will modularize the code for better readability.
Quoted 3 lines
mm/damon.c static unsigned int nr_damon_regions(struct damon_task *t) · line 474
Quoted 3 lines
mm/damon.c +2
-0+else if (pmd &&pmd_young (*pmd)) + r->nr_accesses++;So we increment a region count by one if we have an access in a huge page, or in a normal page.
If we get a region that has a mixture of the two, this seems likely to give a bad approximation.
Quoted 8 lines
Assume the region is accessed 'evenly' but each " 4k page" is only hit 10% of the time (where a hit is in one check period)
If our address in a page, then we'll hit 10% of the time, but if it is in a 2M huge page then we'll hit a much higher percentage of the time.
1 - (0.9^512) ~= 1Should we look to somehow account for this?
Yes, this is really critical bug and we should fix this! Thank you so much for finding this!
Quoted 19 lines
Quoted 19 lines
Quoted 19 lines
Quoted 19 lines
mm/damon.c +18
-0+#endif /* CONFIG_TRANSPARENT_HUGEPAGE */ + +spin_unlock (ptl); + +mkold: +/* mkold next target */ + r->sampling_addr =damon_rand (ctx, r->vm_start, r->vm_end); + +if (follow_pte_pmd (mm, r->sampling_addr,NULL , &pte, &pmd, &ptl)) +return ; + +if (pte) { +if (pte_young (*pte)) { +clear_page_idle (pte_page (*pte)); +set_page_young (pte_page (*pte)); + } + *pte =pte_mkold (*pte); + }
Quoted 8 lines
Quoted 8 lines
Quoted 8 lines
mm/damon.c static unsigned int nr_damon_regions(struct damon_task *t) · line 500
Quoted 8 lines
mm/damon.c +8
-0+#ifdef CONFIG_TRANSPARENT_HUGEPAGE + else if (pmd) { +if (pmd_young (*pmd)) { +clear_page_idle (pmd_page (*pmd)); +set_page_young (pmd_page (*pmd)); + } + *pmd =pmd_mkold (*pmd); + }
This is also very problematic if several regions are backed by a single huge page, as only one region in the huge page will be checked as accessed.
Will address these problems in next spin!
Thanks,
SeongJae Park
Quoted 7 lines
Quoted 5 lines
Quoted 5 lines
Quoted 5 lines
mm/damon.c +5
-0+#endif + +spin_unlock (ptl); +} +
Re: [PATCH v6 02/14] mm/damon: Implement region based sampling
Quoted 114 lines · On Tue, 10 Mar 2020 17:22:40 +0100 SeongJae Park <[email protected]> wrote:
Quoted 10 lines · On Tue, 10 Mar 2020 15:55:10 +0000 Jonathan Cameron…
Quoted 3 lines · On Tue, 10 Mar 2020 12:52:33 +0100 SeongJae Park <[email protected]> wrote:
Added replies to your every comment in line below. I agree to your whole opinions, will apply those in next spin! :)
One additional question inline that came to mind. Using a single statistic to monitor huge page and normal page hits is going to give us problems I think.
Ah, you're right!!! This is indeed a critical bug!
Quoted 56 lines
Perhaps I'm missing something?
Quoted 41 lines
Quoted 8 lines
Quoted 2 lines
+/*
+ * Check whether the given region has accessed since the last checkShould also make clear that this sets us up for the next access check at a different memory address it the region.
Given the lack of connection between activities perhaps just split this into two functions that are always called next to each other.
Will make the description more clearer as suggested.
Also, I found that I'm not clearing *pte and *pmd before going 'mkold', thanks to this comment. Will fix it, either.
Quoted 14 lines
Quoted 14 lines
+ *
+ * mm 'mm_struct' for the given virtual address space
+ * r the region to be checked
+ */mm/damon.c +9
-0+static void kdamond_check_access (struct damon_ctx *ctx, +struct mm_struct *mm,struct damon_region *r) +{ +pte_t *pte =NULL ; +pmd_t *pmd =NULL ; +spinlock_t *ptl; + +if (follow_pte_pmd (mm, r->sampling_addr,NULL , &pte, &pmd, &ptl)) + goto mkold;Quoted 8 lines
mm/damon.c static unsigned int nr_damon_regions(struct damon_task *t) · line 472
Quoted 5 lines
mm/damon.c +5
-0+ +/* Read the page table access bit of the page */ +if (pte &&pte_young (*pte)) + r->nr_accesses++; +#ifdef CONFIG_TRANSPARENT_HUGEPAGE Is it worth having this protection? Seems likely to have only a very small influence on performance and makes it a little harder to reason about the code.
It was necessary for addressing 'implicit declaration' problem of '
pmd_young()' and 'pmd_mkold()' for build of DAMON on several architectures including User Mode Linux.Quoted 5 lines
Will modularize the code for better readability.
Quoted 3 lines
mm/damon.c static unsigned int nr_damon_regions(struct damon_task *t) · line 474
Quoted 3 lines
mm/damon.c +2
-0+else if (pmd &&pmd_young (*pmd)) + r->nr_accesses++;So we increment a region count by one if we have an access in a huge page, or in a normal page.
If we get a region that has a mixture of the two, this seems likely to give a bad approximation.
Quoted 8 lines
Assume the region is accessed 'evenly' but each " 4k page" is only hit 10% of the time (where a hit is in one check period)
If our address in a page, then we'll hit 10% of the time, but if it is in a 2M huge page then we'll hit a much higher percentage of the time.
1 - (0.9^512) ~= 1Should we look to somehow account for this?
Yes, this is really critical bug and we should fix this! Thank you so much for finding this!
Quoted 19 lines
Quoted 19 lines
Quoted 19 lines
Quoted 19 lines
mm/damon.c +18
-0+#endif /* CONFIG_TRANSPARENT_HUGEPAGE */ + +spin_unlock (ptl); + +mkold: +/* mkold next target */ + r->sampling_addr =damon_rand (ctx, r->vm_start, r->vm_end); + +if (follow_pte_pmd (mm, r->sampling_addr,NULL , &pte, &pmd, &ptl)) +return ; + +if (pte) { +if (pte_young (*pte)) { +clear_page_idle (pte_page (*pte)); +set_page_young (pte_page (*pte)); + } + *pte =pte_mkold (*pte); + }Quoted 8 lines
Quoted 8 lines
Quoted 8 lines
mm/damon.c static unsigned int nr_damon_regions(struct damon_task *t) · line 500
Quoted 8 lines
mm/damon.c +8
-0+#ifdef CONFIG_TRANSPARENT_HUGEPAGE + else if (pmd) { +if (pmd_young (*pmd)) { +clear_page_idle (pmd_page (*pmd)); +set_page_young (pmd_page (*pmd)); + } + *pmd =pmd_mkold (*pmd); + }This is also very problematic if several regions are backed by a single huge page, as only one region in the huge page will be checked as accessed.
Quoted 1 line
Will address these problems in next spin!
Good point. There is little point in ever having multiple regions including a single huge page. Would it be possible to tweak the region splitting algorithm to not do this?
Jonathan
Quoted 12 lines
Thanks,
SeongJae ParkQuoted 7 lines
Quoted 5 lines
Quoted 5 lines
Quoted 5 lines
mm/damon.c +5
-0+#endif + +spin_unlock (ptl); +} +
Re: Re: [PATCH v6 02/14] mm/damon: Implement region based sampling
Quoted 117 lines · On Tue, 10 Mar 2020 17:39:38 +0000 Jonathan Cameron…
Quoted 114 lines · On Tue, 10 Mar 2020 17:22:40 +0100 SeongJae Park <[email protected]> wrote:
Quoted 10 lines · On Tue, 10 Mar 2020 15:55:10 +0000 Jonathan Cameron…
Quoted 3 lines · On Tue, 10 Mar 2020 12:52:33 +0100 SeongJae Park <[email protected]> wrote:
Added replies to your every comment in line below. I agree to your whole opinions, will apply those in next spin! :)
One additional question inline that came to mind. Using a single statistic to monitor huge page and normal page hits is going to give us problems I think.
Ah, you're right!!! This is indeed a critical bug!
Quoted 56 lines
Perhaps I'm missing something?
Quoted 41 lines
Quoted 8 lines
Quoted 2 lines
+/*
+ * Check whether the given region has accessed since the last checkShould also make clear that this sets us up for the next access check at a different memory address it the region.
Given the lack of connection between activities perhaps just split this into two functions that are always called next to each other.
Will make the description more clearer as suggested.
Also, I found that I'm not clearing *pte and *pmd before going 'mkold', thanks to this comment. Will fix it, either.
Quoted 14 lines
Quoted 14 lines
+ *
+ * mm 'mm_struct' for the given virtual address space
+ * r the region to be checked
+ */mm/damon.c +9
-0+static void kdamond_check_access (struct damon_ctx *ctx, +struct mm_struct *mm,struct damon_region *r) +{ +pte_t *pte =NULL ; +pmd_t *pmd =NULL ; +spinlock_t *ptl; + +if (follow_pte_pmd (mm, r->sampling_addr,NULL , &pte, &pmd, &ptl)) + goto mkold;Quoted 8 lines
mm/damon.c static unsigned int nr_damon_regions(struct damon_task *t) · line 472
Quoted 5 lines
mm/damon.c +5
-0+ +/* Read the page table access bit of the page */ +if (pte &&pte_young (*pte)) + r->nr_accesses++; +#ifdef CONFIG_TRANSPARENT_HUGEPAGE Is it worth having this protection? Seems likely to have only a very small influence on performance and makes it a little harder to reason about the code.
It was necessary for addressing 'implicit declaration' problem of '
pmd_young()' and 'pmd_mkold()' for build of DAMON on several architectures including User Mode Linux.Quoted 5 lines
Will modularize the code for better readability.
Quoted 3 lines
mm/damon.c static unsigned int nr_damon_regions(struct damon_task *t) · line 474
Quoted 3 lines
mm/damon.c +2
-0+else if (pmd &&pmd_young (*pmd)) + r->nr_accesses++;So we increment a region count by one if we have an access in a huge page, or in a normal page.
If we get a region that has a mixture of the two, this seems likely to give a bad approximation.
Quoted 8 lines
Assume the region is accessed 'evenly' but each " 4k page" is only hit 10% of the time (where a hit is in one check period)
If our address in a page, then we'll hit 10% of the time, but if it is in a 2M huge page then we'll hit a much higher percentage of the time.
1 - (0.9^512) ~= 1Should we look to somehow account for this?
Yes, this is really critical bug and we should fix this! Thank you so much for finding this!
Quoted 19 lines
Quoted 19 lines
Quoted 19 lines
Quoted 19 lines
mm/damon.c +18
-0+#endif /* CONFIG_TRANSPARENT_HUGEPAGE */ + +spin_unlock (ptl); + +mkold: +/* mkold next target */ + r->sampling_addr =damon_rand (ctx, r->vm_start, r->vm_end); + +if (follow_pte_pmd (mm, r->sampling_addr,NULL , &pte, &pmd, &ptl)) +return ; + +if (pte) { +if (pte_young (*pte)) { +clear_page_idle (pte_page (*pte)); +set_page_young (pte_page (*pte)); + } + *pte =pte_mkold (*pte); + }Quoted 8 lines
Quoted 8 lines
Quoted 8 lines
mm/damon.c static unsigned int nr_damon_regions(struct damon_task *t) · line 500
Quoted 8 lines
mm/damon.c +8
-0+#ifdef CONFIG_TRANSPARENT_HUGEPAGE + else if (pmd) { +if (pmd_young (*pmd)) { +clear_page_idle (pmd_page (*pmd)); +set_page_young (pmd_page (*pmd)); + } + *pmd =pmd_mkold (*pmd); + }This is also very problematic if several regions are backed by a single huge page, as only one region in the huge page will be checked as accessed.
Quoted 5 lines
Quoted 1 line
Will address these problems in next spin!
Good point. There is little point in ever having multiple regions including a single huge page. Would it be possible to tweak the region splitting algorithm to not do this?
Yes, it would be a good solution. However, I believe this is a problem of the access checking mechanism, as the definition of the region is only 'memory area having similar access frequency'. Adding more rules such as 'it should be aligned by HUGE PAGE size' might make things more complex. Also, we're currently using page table Accessed bits as the primitive for the access check,
but it could be extended to other primitives in future. Therefore, I would
like to modify the access checking mechanism to aware the huge pages existance.
For regions containing both regular pages and huge pages, the huge pages will make some errorneous high access frequency as you noted before, but the adaptive regions adjustment will eventually split them.
If you have other concerns or opinions, please let me know.
Thanks,
SeongJae Park
Quoted 17 lines
Jonathan
Quoted 12 lines
Thanks,
SeongJae ParkQuoted 7 lines
Quoted 5 lines
Quoted 5 lines
Quoted 5 lines
mm/damon.c +5
-0+#endif + +spin_unlock (ptl); +} +
Re: [PATCH v6 02/14] mm/damon: Implement region based sampling
In reply to SeongJae ParkQuoted 42 lines · On Mon, 24 Feb 2020 13:30:35 +0100 SeongJae Park <[email protected]> wrote:
From: 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.
This commit also exports
lookup_page_ext()to GPL modules because DAMON uses the function but also supports the module build.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.
Quoted 5 lines
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.
Signed-off-by SeongJae Park <[email protected]>
Came across a minor issue inline. kthread_run calls kthread_create. That gives a potential sleep while atomic issue given the spin lock.
Can probably be fixed by preallocating the thread then starting it later.
Jonathan
Quoted 451 lines
--- mm/damon.c | 509 ++++++++++++++++++++++++++++++++++++++++++++++++++ mm/page_ext.c | 1 + 2 files changed, 510 insertions(+)mm/damon.c +420
-0@@ -9,9 +9,14 @@#define pr_fmt (fmt) "damon: " fmt +#include <linux/delay.h> +#include <linux/kthread.h> #include <linux/mm.h> #include <linux/module.h> +#include <linux/page_idle.h> #include <linux/random.h> +#include <linux/sched/mm.h> +#include <linux/sched/task.h> #include <linux/slab.h> #define damon_get_task_struct (t) \@@ -51,7 +56,24 @@ 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; +spinlock_t kdamond_lock; +struct rnd_state rndseed;struct list_head tasks_list;/* 'damon_task' objects */ @@ -204,6 +226,493 @@ static unsigned int nr_damon_regions(struct damon_task *t)return ret; } +/* +* Get the mm_struct of the given task +* +* Callser should put the mm_struct after use, unless it is NULL. +* +* Returns the mm_struct of the task on success, NULL on failure +*/ +static struct mm_struct *damon_get_mm (struct damon_task *t) +{ +struct task_struct *task; +struct mm_struct *mm; + + task =damon_get_task_struct (t); +if (!task) +return NULL ; + + mm =get_task_mm (task); +put_task_struct (task); +return mm; +} + +/* +* Size-evenly split a region into 'nr_pieces' small regions +* +* Returns 0 on success, or negative error code otherwise. +*/ +static int damon_split_region_evenly (struct damon_ctx *ctx, +struct damon_region *r,unsigned int nr_pieces) +{ +unsigned long sz_orig, sz_piece, orig_end; +struct damon_region *piece =NULL , *next; +unsigned long start; + +if (!r || !nr_pieces) +return -EINVAL ; + + orig_end = r->vm_end; + sz_orig = r->vm_end - r->vm_start; + sz_piece = sz_orig / nr_pieces; + +if (!sz_piece) +return -EINVAL ; + + r->vm_end = r->vm_start + sz_piece; + next =damon_next_region (r); +for (start = r->vm_end; start + sz_piece <= orig_end; + start += sz_piece) { + piece =damon_new_region (ctx, start, start + sz_piece); +damon_add_region (piece, r, next); + r = piece; + } +if (piece) + piece->vm_end = orig_end; +return 0 ; +} + +struct region { +unsigned long start; +unsigned long end; +}; + +static unsigned long sz_region (struct region *r) +{ +return r->end - r->start; +} + +static void swap_regions (struct region *r1,struct region *r2) +{ +struct region tmp; + + tmp = *r1; + *r1 = *r2; + *r2 = tmp; +} + +/* +* Find the three regions in an address space +* +* vma the head vma of the target address space +* regions an array of three 'struct region's that results will be saved +* +* This function receives an address space and finds three regions in it which +* separated by the two biggest unmapped regions in the space. Please refer to +* below comments of 'damon_init_regions_of()' function to know why this is +* necessary. +* +* Returns 0 if success, or negative error code otherwise. +*/ +static int damon_three_regions_in_vmas (struct vm_area_struct *vma, +struct region regions[3 ]) +{ +struct region gap = {0 ,}, first_gap = {0 ,}, second_gap = {0 ,}; +struct vm_area_struct *last_vma =NULL ; +unsigned long start =0 ; + +/* Find two biggest gaps so that first_gap > second_gap > others */ +for (; vma; vma = vma->vm_next) { +if (!last_vma) { + start = vma->vm_start; + last_vma = vma; +continue ; + } + gap.start = last_vma->vm_end; + gap.end = vma->vm_start; +if (sz_region (&gap) >sz_region (&second_gap)) { +swap_regions (&gap, &second_gap); +if (sz_region (&second_gap) >sz_region (&first_gap)) +swap_regions (&second_gap, &first_gap); + } + last_vma = vma; + } + +if (!sz_region (&second_gap) || !sz_region (&first_gap)) +return -EINVAL ; + +/* Sort the two biggest gaps by address */ +if (first_gap.start > second_gap.start) +swap_regions (&first_gap, &second_gap); + +/* Store the result */ + regions[0 ].start = start; + regions[0 ].end = first_gap.start; + regions[1 ].start = first_gap.end; + regions[1 ].end = second_gap.start; + regions[2 ].start = second_gap.end; + regions[2 ].end = last_vma->vm_end; + +return 0 ; +} + +/* +* Get the three regions in the given task +* +* Returns 0 on success, negative error code otherwise. +*/ +static int damon_three_regions_of (struct damon_task *t, +struct region regions[3 ]) +{ +struct mm_struct *mm; +int ret; + + mm =damon_get_mm (t); +if (!mm) +return -EINVAL ; + +down_read (&mm->mmap_sem); + ret =damon_three_regions_in_vmas (mm->mmap, regions); +up_read (&mm->mmap_sem); + +mmput (mm); +return ret; +} + +/* +* Initialize the monitoring target regions for the given task +* +* t the given target task +* +* Because only a number of small portions of the entire address space +* is acutally mapped to the memory and accessed, monitoring the unmapped +* regions is wasteful. That said, because we can deal with small noises, +* tracking every mapping is not strictly required but could even incur a high +* overhead if the mapping frequently changes or the number of mappings is +* high. Nonetheless, this may seems very weird. DAMON's dynamic regions +* adjustment mechanism, which will be implemented with following commit will +* make this more sense. +* +* For the reason, we convert 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. In detail, this function first identifies the start and the +* end of the mappings and the two biggest unmapped areas of the address space. +* Then, it constructs the three regions as below: +* +* [mappings[0]->start, big_two_unmapped_areas[0]->start) +* [big_two_unmapped_areas[0]->end, big_two_unmapped_areas[1]->start) +* [big_two_unmapped_areas[1]->end, mappings[nr_mappings - 1]->end) +* +* As usual memory map of processes is as below, 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. +* +* <heap> +* <BIG UNMAPPED REGION 1> +* <uppermost mmap()-ed region> +* (other mmap()-ed regions and small unmapped regions) +* <lowermost mmap()-ed region> +* <BIG UNMAPPED REGION 2> +* <stack> +*/ +static void damon_init_regions_of (struct damon_ctx *c,struct damon_task *t) +{ +struct damon_region *r; +struct region regions[3 ]; +int i; + +if (damon_three_regions_of (t, regions)) { +pr_err ("Failed to get three regions of task %lu\n" , t->pid); +return ; + } + +/* Set the initial three regions of the task */ +for (i =0 ; i <3 ; i++) { + r =damon_new_region (c, regions[i].start, regions[i].end); +damon_add_region_tail (r, t); + } + +/* Split the middle region into 'min_nr_regions - 2' regions */ + r =damon_nth_region_of (t,1 ); +if (damon_split_region_evenly (c, r, c->min_nr_regions -2 )) +pr_warn ("Init middle region failed to be split\n" ); +} + +/* Initialize '->regions_list' of every task */ +static void kdamond_init_regions (struct damon_ctx *ctx) +{ +struct damon_task *t; + +damon_for_each_task (ctx, t) +damon_init_regions_of (ctx, t); +} + +/* +* Check whether the given region has accessed since the last check +* +* mm 'mm_struct' for the given virtual address space +* r the region to be checked +*/ +static void kdamond_check_access (struct damon_ctx *ctx, +struct mm_struct *mm,struct damon_region *r) +{ +pte_t *pte =NULL ; +pmd_t *pmd =NULL ; +spinlock_t *ptl; + +if (follow_pte_pmd (mm, r->sampling_addr,NULL , &pte, &pmd, &ptl)) + goto mkold; + +/* Read the page table access bit of the page */ +if (pte &&pte_young (*pte)) + r->nr_accesses++; +#ifdef CONFIG_TRANSPARENT_HUGEPAGE + else if (pmd && pmd_young(*pmd)) + r->nr_accesses++; +#endif /* CONFIG_TRANSPARENT_HUGEPAGE */ + +spin_unlock (ptl); + +mkold: +/* mkold next target */ + r->sampling_addr =damon_rand (ctx, r->vm_start, r->vm_end); + +if (follow_pte_pmd (mm, r->sampling_addr,NULL , &pte, &pmd, &ptl)) +return ; + +if (pte) { +if (pte_young (*pte)) { +clear_page_idle (pte_page (*pte)); +set_page_young (pte_page (*pte)); + } + *pte =pte_mkold (*pte); + } +#ifdef CONFIG_TRANSPARENT_HUGEPAGE + else if (pmd) { +if (pmd_young (*pmd)) { +clear_page_idle (pmd_page (*pmd)); +set_page_young (pmd_page (*pmd)); + } + *pmd =pmd_mkold (*pmd); + } +#endif + +spin_unlock (ptl); +} + +/* +* Check whether a time interval is elapsed +* +* baseline the time to check whether the interval has elapsed since +* interval the time interval (microseconds) +* +* See whether the given time interval has passed since the given baseline +* time. If so, it also updates the baseline to current time for next check. +* +* Returns true if the time interval has passed, or false otherwise. +*/ +static bool damon_check_reset_time_interval (struct timespec64 *baseline, +unsigned long interval) +{ +struct timespec64 now; + +ktime_get_coarse_ts64 (&now); +if ((timespec64_to_ns (&now) -timespec64_to_ns (baseline)) < + interval *1000 ) +return false; + *baseline = now; +return true; +} + +/* +* Check whether it is time to flush the aggregated information +*/ +static bool kdamond_aggregate_interval_passed (struct damon_ctx *ctx) +{ +return damon_check_reset_time_interval (&ctx->last_aggregation, + ctx->aggr_interval); +} + +/* +* Reset the aggregated monitoring results +*/ +static void kdamond_flush_aggregated (struct damon_ctx *c) +{ +struct damon_task *t; +struct damon_region *r; + +damon_for_each_task (c, t) { +damon_for_each_region (r, t) + r->nr_accesses =0 ; + } +} + +/* +* Check whether current monitoring should be stopped +* +* If users asked to stop, need stop. Even though no user has asked to stop, +* need stop if every target task has dead. +* +* Returns true if need to stop current monitoring. +*/ +static bool kdamond_need_stop (struct damon_ctx *ctx) +{ +struct damon_task *t; +struct task_struct *task; +bool stop; + +spin_lock (&ctx->kdamond_lock); + stop = ctx->kdamond_stop; +spin_unlock (&ctx->kdamond_lock); +if (stop) +return true; + +damon_for_each_task (ctx, t) { + task =damon_get_task_struct (t); +if (task) { +put_task_struct (task); +return false; + } + } + +return true; +} + +/* +* The monitoring daemon that runs as a kernel thread +*/ +static int kdamond_fn (void *data) +{ +struct damon_ctx *ctx = (struct damon_ctx *)data; +struct damon_task *t; +struct damon_region *r, *next; +struct mm_struct *mm; + +pr_info ("kdamond (%d) starts\n" , ctx->kdamond->pid); +kdamond_init_regions (ctx); +while (!kdamond_need_stop (ctx)) { +damon_for_each_task (ctx, t) { + mm =damon_get_mm (t); +if (!mm) +continue ; +damon_for_each_region (r, t) +kdamond_check_access (ctx, mm, r); +mmput (mm); + } + +if (kdamond_aggregate_interval_passed (ctx)) +kdamond_flush_aggregated (ctx); + +usleep_range (ctx->sample_interval, ctx->sample_interval +1 ); + } +damon_for_each_task (ctx, t) { +damon_for_each_region_safe (r, next, t) +damon_destroy_region (r); + } +pr_info ("kdamond (%d) finishes\n" , ctx->kdamond->pid); +spin_lock (&ctx->kdamond_lock); + ctx->kdamond =NULL ; +spin_unlock (&ctx->kdamond_lock); +return 0 ; +} + +/* +* Controller functions +*/ + +/*
mm/damon.c static unsigned int nr_damon_regions(struct damon_task *t) · line 636
Quoted 10 lines
mm/damon.c +10
-0+* Start or stop the kdamond +* +* Returns 0 if success, negative error code otherwise. +*/ +static int damon_turn_kdamond (struct damon_ctx *ctx,bool on) +{ +spin_lock (&ctx->kdamond_lock); + ctx->kdamond_stop = !on; +if (!ctx->kdamond && on) { + ctx->kdamond =kthread_run (kdamond_fn, ctx,"kdamond" );
Can't do this under a spin lock.
Quoted 94 lines
mm/damon.c +79
-0+if (!ctx->kdamond) + goto fail; + goto success; + } +if (ctx->kdamond && !on) { +spin_unlock (&ctx->kdamond_lock); +while (true) { +spin_lock (&ctx->kdamond_lock); +if (!ctx->kdamond) + goto success; +spin_unlock (&ctx->kdamond_lock); + +usleep_range (ctx->sample_interval, + ctx->sample_interval *2 ); + } + } + +/* tried to turn on while turned on, or turn off while turned off */ + +fail: +spin_unlock (&ctx->kdamond_lock); +return -EINVAL ; + +success: +spin_unlock (&ctx->kdamond_lock); +return 0 ; +} + +/* +* This function should not be called while the kdamond is running. +*/ +static int damon_set_pids (struct damon_ctx *ctx, +unsigned long *pids,ssize_t nr_pids) +{ +ssize_t i; +struct damon_task *t, *next; + +damon_for_each_task_safe (ctx, t, next) +damon_destroy_task (t); + +for (i =0 ; i < nr_pids; i++) { + t =damon_new_task (pids[i]); +if (!t) { +pr_err ("Failed to alloc damon_task\n" ); +return -ENOMEM ; + } +damon_add_task_tail (ctx, t); + } + +return 0 ; +} + +/* +* Set attributes for the monitoring +* +* sample_int time interval between samplings +* aggr_int time interval between aggregations +* min_nr_reg minimal number of regions +* +* This function should not be called while the kdamond is running. +* Every time interval is in micro-seconds. +* +* Returns 0 on success, negative error code otherwise. +*/ +static int damon_set_attrs (struct damon_ctx *ctx,unsigned long sample_int, +unsigned long aggr_int,unsigned long min_nr_reg) +{ +if (min_nr_reg <3 ) { +pr_err ("min_nr_regions (%lu) should be bigger than 2\n" , + min_nr_reg); +return -EINVAL ; + } + + ctx->sample_interval = sample_int; + ctx->aggr_interval = aggr_int; + ctx->min_nr_regions = min_nr_reg; +return 0 ; +} +static int __init damon_init (void ) {pr_info ("init\n" );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) {
Re: Re: [PATCH v6 02/14] mm/damon: Implement region based sampling
Quoted 10 lines · On Fri, 13 Mar 2020 17:29:54 +0000 Jonathan Cameron…
Quoted 7 lines · On Mon, 24 Feb 2020 13:30:35 +0100 SeongJae Park <[email protected]> wrote:
From: 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.
[...]
Quoted 7 lines
Came across a minor issue inline.
kthread_runcallskthread_create. That gives a potential sleep while atomic issue given the spin lock.Can probably be fixed by preallocating the thread then starting it later.
Jonathan
[...]
Quoted 5 lines
Quoted 5 lines
+/*
+ * Start or stop the kdamond
+ *
+ * Returns 0 if success, negative error code otherwise.
+ */
Quoted 8 lines
mm/damon.c static unsigned int nr_damon_regions(struct damon_task *t) · line 636
Quoted 6 lines
mm/damon.c +6
-0+static int damon_turn_kdamond (struct damon_ctx *ctx,bool on) +{ +spin_lock (&ctx->kdamond_lock); + ctx->kdamond_stop = !on; +if (!ctx->kdamond && on) { + ctx->kdamond =kthread_run (kdamond_fn, ctx,"kdamond" );Can't do this under a spin lock.
Good catch! And, agree to your suggestion. I will fix this in that way!
Thanks,
SeongJae Park
Re: Re: Re: [PATCH v6 02/14] mm/damon: Implement region based sampling
Quoted 35 lines · On Fri, 13 Mar 2020 21:16:49 +0100 SeongJae Park <[email protected]> wrote:
Quoted 10 lines · On Fri, 13 Mar 2020 17:29:54 +0000 Jonathan Cameron…
Quoted 7 lines · On Mon, 24 Feb 2020 13:30:35 +0100 SeongJae Park <[email protected]> wrote:
From: 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.
[...]
Quoted 7 lines
Came across a minor issue inline.
kthread_runcallskthread_create. That gives a potential sleep while atomic issue given the spin lock.Can probably be fixed by preallocating the thread then starting it later.
Jonathan
[...]
Quoted 5 lines
Quoted 5 lines
+/*
+ * Start or stop the kdamond
+ *
+ * Returns 0 if success, negative error code otherwise.
+ */Quoted 8 lines
mm/damon.c static unsigned int nr_damon_regions(struct damon_task *t) · line 636
Quoted 6 lines
mm/damon.c +6
-0+static int damon_turn_kdamond (struct damon_ctx *ctx,bool on) +{ +spin_lock (&ctx->kdamond_lock); + ctx->kdamond_stop = !on; +if (!ctx->kdamond && on) { + ctx->kdamond =kthread_run (kdamond_fn, ctx,"kdamond" );Can't do this under a spin lock.
Quoted 1 line
Good catch! And, agree to your suggestion. I will fix this in that way!
I changed my mind. I would like to simply use mutex instead of spinlock, as khugepaged also does. If you have different opinion, please let me know.
Thanks,
SeongJae Park
Quoted 4 lines
Thanks,
SeongJae Park
PATCH v6 3/14 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.
--- mm/damon.c | 151 ++++++++++++++++++++++++++++++++++++++++++++++++++--- 1 file changed, 144 insertions(+), 7 deletions(-)
mm/damon.c +144 -7
@@ -67,6 +67,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;
@@ -389,9 +390,12 @@ static int damon_three_regions_of(struct damon_task *t,* regions is wasteful. That said, because we can deal with small noises, * tracking every mapping is not strictly required but could even incur a high * overhead if the mapping frequently changes or the number of mappings is -* high. Nonetheless, this may seems very weird. DAMON's dynamic regions -* adjustment mechanism, which will be implemented with following commit will -* make this more sense. +* high. The adaptive regions adjustment mechanism will further help to deal +* with the noises by simply identifying the unmapped areas as a region that +* has no access. Moreover, applying the real mappings that would have many +* unmapped areas inside will make the adaptive mechanism quite complex. 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, we convert the complex mappings to three distinct regions * that cover every mapped areas of the address space. Also the two gaps
@@ -550,6 +554,123 @@ static void kdamond_flush_aggregated(struct damon_ctx *c) } } +#define sz_damon_region (r) (r->vm_end - r->vm_start) + +/* +* Merge two adjacent regions into one region +*/ +static void damon_merge_two_regions (struct damon_region *l, +struct damon_region *r) +{ + l->nr_accesses = (l->nr_accesses *sz_damon_region (l) + + r->nr_accesses *sz_damon_region (r)) / + (sz_damon_region (l) +sz_damon_region (r)); + l->vm_end = r->vm_end; +damon_destroy_region (r); +} + +#define diff_of (a, b) (a > b ? a - b : b - a) + +/* +* Merge adjacent regions having similar access frequencies +* +* t task that merge operation will make change +* thres merge regions having '->nr_accesses' diff smaller than this +*/ +static void damon_merge_regions_of (struct damon_task *t,unsigned int thres) +{ +struct damon_region *r, *prev =NULL , *next; + +damon_for_each_region_safe (r, next, t) { +if (!prev || prev->vm_end != r->vm_start) + goto next; +if (diff_of (prev->nr_accesses, r->nr_accesses) > thres) + goto next; +damon_merge_two_regions (prev, r); +continue ; +next: + prev = r; + } +} + +/* +* Merge adjacent regions having similar access frequencies +* +* threshold merge regions havind nr_accesses diff larger than this +* +* This function merges monitoring target regions which are adjacent and their +* access frequencies are similar. This is for minimizing the monitoring +* overhead under the dynamically changeable access pattern. If a merge was +* unnecessarily made, later 'kdamond_split_regions()' will revert it. +*/ +static void kdamond_merge_regions (struct damon_ctx *c,unsigned int threshold) +{ +struct damon_task *t; + +damon_for_each_task (c, t) +damon_merge_regions_of (t, threshold); +} + +/* +* Split a region into two small regions +* +* r the region to be split +* sz_r size of the first sub-region that will be made +*/ +static void damon_split_region_at (struct damon_ctx *ctx, +struct damon_region *r,unsigned long sz_r) +{ +struct damon_region *new; + + new =damon_new_region (ctx, r->vm_start + sz_r, r->vm_end); + r->vm_end = new->vm_start; + +damon_add_region (new, r,damon_next_region (r)); +} + +static void damon_split_regions_of (struct damon_ctx *ctx,struct damon_task *t) +{ +struct damon_region *r, *next; +unsigned long sz_left_region; + +damon_for_each_region_safe (r, next, t) { +/* +* Randomly select size of left sub-region to be at least +* 10 percent and at most 90% of original region +*/ + sz_left_region = (prandom_u32_state (&ctx->rndseed) %9 +1 ) * + (r->vm_end - r->vm_start) /10 ; +/* Do not allow blank region */ +if (sz_left_region ==0 ) +continue ; +damon_split_region_at (ctx, r, sz_left_region); + } +} + +/* +* splits every target regions into two randomly-sized regions +* +* This function splits every target regions into two random-sized regions if +* current total number of the regions is smaller than the half of the +* user-specified maximum number of regions. This is for maximizing the +* monitoring accuracy under the dynamically changeable access patterns. If a +* split was unnecessarily made, later 'kdamond_merge_regions()' will revert +* it. +*/ +static void kdamond_split_regions (struct damon_ctx *ctx) +{ +struct damon_task *t; +unsigned int nr_regions =0 ; + +damon_for_each_task (ctx, t) + nr_regions +=nr_damon_regions (t); +if (nr_regions > ctx->max_nr_regions /2 ) +return ; + +damon_for_each_task (ctx, t) +damon_split_regions_of (ctx, t); +} +/* * Check whether current monitoring should be stopped *
@@ -590,21 +711,29 @@ static int kdamond_fn(void *data)struct damon_task *t;struct damon_region *r, *next;struct mm_struct *mm; +unsigned long max_nr_accesses;pr_info ("kdamond (%d) starts\n" , ctx->kdamond->pid);kdamond_init_regions (ctx);while (!kdamond_need_stop (ctx)) { + max_nr_accesses =0 ;damon_for_each_task (ctx, t) { mm =damon_get_mm (t);if (!mm)continue ; -damon_for_each_region (r, t) +damon_for_each_region (r, t) {kdamond_check_access (ctx, mm, r); +if (r->nr_accesses > max_nr_accesses) + max_nr_accesses = r->nr_accesses; + }mmput (mm); } -if (kdamond_aggregate_interval_passed (ctx)) +if (kdamond_aggregate_interval_passed (ctx)) { +kdamond_merge_regions (ctx, max_nr_accesses /10 );kdamond_flush_aggregated (ctx); +kdamond_split_regions (ctx); + }usleep_range (ctx->sample_interval, ctx->sample_interval +1 ); }
@@ -692,24 +821,32 @@ static int damon_set_pids(struct damon_ctx *ctx,* sample_int time interval between samplings * aggr_int time interval between aggregations * min_nr_reg minimal number of regions +* max_nr_reg maximum number of regions * * This function should not be called while the kdamond is running. * Every time interval is in micro-seconds. * * Returns 0 on success, negative error code otherwise. */ -static int damon_set_attrs (struct damon_ctx *ctx,unsigned long sample_int, -unsigned long aggr_int,unsigned long min_nr_reg) +static 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) {if (min_nr_reg <3 ) {pr_err ("min_nr_regions (%lu) should be bigger than 2\n" , min_nr_reg);return -EINVAL ; } +if (min_nr_reg >= ctx->max_nr_regions) { +pr_err ("invalid nr_regions. min (%lu) >= max (%lu)\n" , + min_nr_reg, max_nr_reg); +return -EINVAL ; + } ctx->sample_interval = sample_int; ctx->aggr_interval = aggr_int; ctx->min_nr_regions = min_nr_reg; + ctx->max_nr_regions = max_nr_reg;return 0 ; }
Signature · 1 line
2.17.1
Re: [PATCH v6 03/14] mm/damon: Adaptively adjust regions
Quoted 17 lines · On Mon, 24 Feb 2020 13:30:36 +0100 SeongJae Park <[email protected]> wrote:
From: 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.
Quoted 4 lines
In this way, DAMON provides its best-effort quality and minimal overhead while keeping the bounds users set for their trade-off.
Signed-off-by SeongJae Park <[email protected]>
Really minor comments inline.
Quoted 58 lines
--- mm/damon.c | 151 ++++++++++++++++++++++++++++++++++++++++++++++++++--- 1 file changed, 144 insertions(+), 7 deletions(-)mm/damon.c +29
-3@@ -67,6 +67,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;@@ -389,9 +390,12 @@ static int damon_three_regions_of(struct damon_task *t,* regions is wasteful. That said, because we can deal with small noises, * tracking every mapping is not strictly required but could even incur a high * overhead if the mapping frequently changes or the number of mappings is -* high. Nonetheless, this may seems very weird. DAMON's dynamic regions -* adjustment mechanism, which will be implemented with following commit will -* make this more sense. +* high. The adaptive regions adjustment mechanism will further help to deal +* with the noises by simply identifying the unmapped areas as a region that +* has no access. Moreover, applying the real mappings that would have many +* unmapped areas inside will make the adaptive mechanism quite complex. 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, we convert the complex mappings to three distinct regions * that cover every mapped areas of the address space. Also the two gaps @@ -550,6 +554,123 @@ static void kdamond_flush_aggregated(struct damon_ctx *c) } } +#define sz_damon_region (r) (r->vm_end - r->vm_start) + +/* +* Merge two adjacent regions into one region +*/ +static void damon_merge_two_regions (struct damon_region *l, +struct damon_region *r) +{ + l->nr_accesses = (l->nr_accesses *sz_damon_region (l) + + r->nr_accesses *sz_damon_region (r)) / + (sz_damon_region (l) +sz_damon_region (r)); + l->vm_end = r->vm_end; +damon_destroy_region (r); +} + +#define diff_of (a, b) (a > b ? a - b : b - a) + +/* +* Merge adjacent regions having similar access frequencies +* +* t task that merge operation will make change +* thres merge regions having '->nr_accesses' diff smaller than this
mm/damon.c static void kdamond_flush_aggregated(struct damon_ctx *c) · line 588
Quoted 10 lines
mm/damon.c +10
-0+*/ +static void damon_merge_regions_of (struct damon_task *t,unsigned int thres) +{ +struct damon_region *r, *prev =NULL , *next; + +damon_for_each_region_safe (r, next, t) { +if (!prev || prev->vm_end != r->vm_start) + goto next; +if (diff_of (prev->nr_accesses, r->nr_accesses) > thres) + goto next;
if (!prev || prev->vm_end != r->vm_start ||
diff_of(prev->nr_accesses, r->nr_accesses) > thres) {
prev = r;
continue;
}Seems more logical to my head. Maybe it's just me though. A goto inside a loop isn't pretty to my mind.
Quoted 97 lines
mm/damon.c +86
-0+damon_merge_two_regions (prev, r); +continue ; +next: + prev = r; + } +} + +/* +* Merge adjacent regions having similar access frequencies +* +* threshold merge regions havind nr_accesses diff larger than this +* +* This function merges monitoring target regions which are adjacent and their +* access frequencies are similar. This is for minimizing the monitoring +* overhead under the dynamically changeable access pattern. If a merge was +* unnecessarily made, later 'kdamond_split_regions()' will revert it. +*/ +static void kdamond_merge_regions (struct damon_ctx *c,unsigned int threshold) +{ +struct damon_task *t; + +damon_for_each_task (c, t) +damon_merge_regions_of (t, threshold); +} + +/* +* Split a region into two small regions +* +* r the region to be split +* sz_r size of the first sub-region that will be made +*/ +static void damon_split_region_at (struct damon_ctx *ctx, +struct damon_region *r,unsigned long sz_r) +{ +struct damon_region *new; + + new =damon_new_region (ctx, r->vm_start + sz_r, r->vm_end); + r->vm_end = new->vm_start; + +damon_add_region (new, r,damon_next_region (r)); +} + +static void damon_split_regions_of (struct damon_ctx *ctx,struct damon_task *t) +{ +struct damon_region *r, *next; +unsigned long sz_left_region; + +damon_for_each_region_safe (r, next, t) { +/* +* Randomly select size of left sub-region to be at least +* 10 percent and at most 90% of original region +*/ + sz_left_region = (prandom_u32_state (&ctx->rndseed) %9 +1 ) * + (r->vm_end - r->vm_start) /10 ; +/* Do not allow blank region */ +if (sz_left_region ==0 ) +continue ; +damon_split_region_at (ctx, r, sz_left_region); + } +} + +/* +* splits every target regions into two randomly-sized regions +* +* This function splits every target regions into two random-sized regions if +* current total number of the regions is smaller than the half of the +* user-specified maximum number of regions. This is for maximizing the +* monitoring accuracy under the dynamically changeable access patterns. If a +* split was unnecessarily made, later 'kdamond_merge_regions()' will revert +* it. +*/ +static void kdamond_split_regions (struct damon_ctx *ctx) +{ +struct damon_task *t; +unsigned int nr_regions =0 ; + +damon_for_each_task (ctx, t) + nr_regions +=nr_damon_regions (t); +if (nr_regions > ctx->max_nr_regions /2 ) +return ; + +damon_for_each_task (ctx, t) +damon_split_regions_of (ctx, t); +} +/* * Check whether current monitoring should be stopped * @@ -590,21 +711,29 @@ static int kdamond_fn(void *data)struct damon_task *t;struct damon_region *r, *next;struct mm_struct *mm; +unsigned long max_nr_accesses;pr_info ("kdamond (%d) starts\n" , ctx->kdamond->pid);kdamond_init_regions (ctx);while (!kdamond_need_stop (ctx)) {
mm/damon.c static int kdamond_fn(void *data) · line 727
Quoted 10 lines
mm/damon.c +4
-1+ max_nr_accesses =0 ;damon_for_each_task (ctx, t) { mm =damon_get_mm (t);if (!mm)continue ; -damon_for_each_region (r, t) +damon_for_each_region (r, t) {kdamond_check_access (ctx, mm, r); +if (r->nr_accesses > max_nr_accesses) + max_nr_accesses = r->nr_accesses;
max_nr_accesses = max(r->nr_accesses, max_nr_accesses)
Quoted 48 lines
mm/damon.c +15
-3+ }mmput (mm); } -if (kdamond_aggregate_interval_passed (ctx)) +if (kdamond_aggregate_interval_passed (ctx)) { +kdamond_merge_regions (ctx, max_nr_accesses /10 );kdamond_flush_aggregated (ctx); +kdamond_split_regions (ctx); + }usleep_range (ctx->sample_interval, ctx->sample_interval +1 ); }@@ -692,24 +821,32 @@ static int damon_set_pids(struct damon_ctx *ctx,* sample_int time interval between samplings * aggr_int time interval between aggregations * min_nr_reg minimal number of regions +* max_nr_reg maximum number of regions * * This function should not be called while the kdamond is running. * Every time interval is in micro-seconds. * * Returns 0 on success, negative error code otherwise. */ -static int damon_set_attrs (struct damon_ctx *ctx,unsigned long sample_int, -unsigned long aggr_int,unsigned long min_nr_reg) +static 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) {if (min_nr_reg <3 ) {pr_err ("min_nr_regions (%lu) should be bigger than 2\n" , min_nr_reg);return -EINVAL ; } +if (min_nr_reg >= ctx->max_nr_regions) { +pr_err ("invalid nr_regions. min (%lu) >= max (%lu)\n" , + min_nr_reg, max_nr_reg); +return -EINVAL ; + } ctx->sample_interval = sample_int; ctx->aggr_interval = aggr_int; ctx->min_nr_regions = min_nr_reg; + ctx->max_nr_regions = max_nr_reg;return 0 ; }
Re: Re: [PATCH v6 03/14] mm/damon: Adaptively adjust regions
Quoted 20 lines · On Tue, 10 Mar 2020 08:57:47 +0000 Jonathan Cameron…
Quoted 17 lines · On Mon, 24 Feb 2020 13:30:36 +0100 SeongJae Park <[email protected]> wrote:
From: 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.
Quoted 6 lines
Quoted 4 lines
In this way, DAMON provides its best-effort quality and minimal overhead while keeping the bounds users set for their trade-off.
Signed-off-by SeongJae Park <[email protected]>Really minor comments inline.
Very helpful comments for me. You are indeed making this much better! Will apply whole your comments below in the next spin.
Quoted 9 lines
Quoted 9 lines
--- mm/damon.c | 151 ++++++++++++++++++++++++++++++++++++++++++++++++++--- 1 file changed, 144 insertions(+), 7 deletions(-)mm/damon.c +0
-0
[...]
Quoted 22 lines
Quoted 5 lines
mm/damon.c +5
-0+/* +* Merge adjacent regions having similar access frequencies +* +* t task that merge operation will make change +* thres merge regions having '->nr_accesses' diff smaller than this mm/damon.c static void kdamond_flush_aggregated(struct damon_ctx *c) · line 588
Quoted 10 lines
mm/damon.c +10
-0+*/ +static void damon_merge_regions_of (struct damon_task *t,unsigned int thres) +{ +struct damon_region *r, *prev =NULL , *next; + +damon_for_each_region_safe (r, next, t) { +if (!prev || prev->vm_end != r->vm_start) + goto next; +if (diff_of (prev->nr_accesses, r->nr_accesses) > thres) + goto next;if (!prev || prev->vm_end != r->vm_start || diff_of(prev->nr_accesses, r->nr_accesses) > thres) { prev = r; continue; }
Quoted 2 lines
Seems more logical to my head. Maybe it's just me though. A goto inside a loop isn't pretty to my mind.
Yes, your version seems much prettier to me, either :)
Quoted 8 lines
Quoted 8 lines
mm/damon.c +7
-0+damon_merge_two_regions (prev, r); +continue ; +next: + prev = r; + } +} +
[...]
Quoted 6 lines
Quoted 6 lines
mm/damon.c +1
-0@@ -590,21 +711,29 @@ static int kdamond_fn(void *data)struct damon_task *t;struct damon_region *r, *next;struct mm_struct *mm; +unsigned long max_nr_accesses;
Quoted 15 lines
mm/damon.c static int kdamond_fn(void *data) · line 727
Quoted 13 lines
mm/damon.c +4
-1pr_info ("kdamond (%d) starts\n" , ctx->kdamond->pid);kdamond_init_regions (ctx);while (!kdamond_need_stop (ctx)) { + max_nr_accesses =0 ;damon_for_each_task (ctx, t) { mm =damon_get_mm (t);if (!mm)continue ; -damon_for_each_region (r, t) +damon_for_each_region (r, t) {kdamond_check_access (ctx, mm, r); +if (r->nr_accesses > max_nr_accesses) + max_nr_accesses = r->nr_accesses;
max_nr_accesses=max(r->nr_accesses, max_nr_accesses)
Good point!
Thanks,
SeongJae Park
[...]
PATCH v6 4/14 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``).
--- mm/damon.c | 99 +++++++++++++++++++++++++++++++++++++++++++++++++++--- 1 file changed, 95 insertions(+), 4 deletions(-)
mm/damon.c +95 -4
@@ -59,17 +59,22 @@ 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 each 'aggr_interval' time. And for each +* 'regions_update_interval', damon checks whether the memory mapping of the +* target tasks has changed (e.g., by mmap() calls from the applications) and +* applies the changes. * * 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;
@@ -671,6 +676,87 @@ static void kdamond_split_regions(struct damon_ctx *ctx)damon_split_regions_of (ctx, t); } +/* +* Check whether it is time to check and apply the dynamic mmap changes +* +* Returns true if it is. +*/ +static bool kdamond_need_update_regions (struct damon_ctx *ctx) +{ +return damon_check_reset_time_interval (&ctx->last_regions_update, + ctx->regions_update_interval); +} + +static bool damon_intersect (struct damon_region *r,struct region *re) +{ +return !(r->vm_end <= re->start || re->end <= r->vm_start); +} + +/* +* Update damon regions for the three big regions of the given task +* +* t the given task +* bregions the three big regions of the task +*/ +static void damon_apply_three_regions (struct damon_ctx *ctx, +struct damon_task *t,struct region bregions[3 ]) +{ +struct damon_region *r, *next; +unsigned int i =0 ; + +/* Remove regions which isn't in the three big regions now */ +damon_for_each_region_safe (r, next, t) { +for (i =0 ; i <3 ; i++) { +if (damon_intersect (r, &bregions[i])) +break ; + } +if (i ==3 ) +damon_destroy_region (r); + } + +/* Adjust intersecting regions to fit with the threee big regions */ +for (i =0 ; i <3 ; i++) { +struct damon_region *first =NULL , *last; +struct damon_region *newr; +struct region *br; + + br = &bregions[i]; +/* Get the first and last regions which intersects with br */ +damon_for_each_region (r, t) { +if (damon_intersect (r, br)) { +if (!first) + first = r; + last = r; + } +if (r->vm_start >= br->end) +break ; + } +if (!first) { +/* no damon_region intersects with this big region */ + newr =damon_new_region (ctx, br->start, br->end); +damon_add_region (newr,damon_prev_region (r), r); + }else { + first->vm_start = br->start; + last->vm_end = br->end; + } + } +} + +/* +* Update regions for current memory mappings +*/ +static void kdamond_update_regions (struct damon_ctx *ctx) +{ +struct region three_regions[3 ]; +struct damon_task *t; + +damon_for_each_task (ctx, t) { +if (damon_three_regions_of (t, three_regions)) +continue ; +damon_apply_three_regions (ctx, t, three_regions); + } +} +/* * Check whether current monitoring should be stopped *
@@ -735,6 +821,9 @@ static int kdamond_fn(void *data)kdamond_split_regions (ctx); } +if (kdamond_need_update_regions (ctx)) +kdamond_update_regions (ctx); +usleep_range (ctx->sample_interval, ctx->sample_interval +1 ); }damon_for_each_task (ctx, t) {
@@ -820,6 +909,7 @@ static int damon_set_pids(struct damon_ctx *ctx,* * sample_int time interval between samplings * aggr_int time interval between aggregations +* regions_update_int time interval between vma update checks * min_nr_reg minimal number of regions * max_nr_reg maximum number of regions *
@@ -828,9 +918,9 @@ static int damon_set_pids(struct damon_ctx *ctx,* * Returns 0 on success, negative error code otherwise. */ -static 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) +static 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) {if (min_nr_reg <3 ) { pr_err("min_nr_regions (%lu) should be bigger than 2\n",
@@ -845,6 +935,7 @@ static int damon_set_attrs(struct damon_ctx *ctx, ctx->sample_interval = sample_int; ctx->aggr_interval = aggr_int; + ctx->regions_update_interval = regions_update_int; ctx->min_nr_regions = min_nr_reg; ctx->max_nr_regions = max_nr_reg;return 0 ;
Signature · 1 line
2.17.1
Re: [PATCH v6 04/14] mm/damon: Apply dynamic memory mapping changes
Quoted 10 lines · On Mon, 24 Feb 2020 13:30:37 +0100 SeongJae Park <[email protected]> wrote:
From: 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``).
Signed-off-by SeongJae Park <[email protected]>
Trivial inline. Otherwise makes sense to me.
Quoted 65 lines
--- mm/damon.c | 99 +++++++++++++++++++++++++++++++++++++++++++++++++++--- 1 file changed, 95 insertions(+), 4 deletions(-)mm/damon.c +35
-1@@ -59,17 +59,22 @@ 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 each 'aggr_interval' time. And for each +* 'regions_update_interval', damon checks whether the memory mapping of the +* target tasks has changed (e.g., by mmap() calls from the applications) and +* applies the changes. * * 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;@@ -671,6 +676,87 @@ static void kdamond_split_regions(struct damon_ctx *ctx)damon_split_regions_of (ctx, t); } +/* +* Check whether it is time to check and apply the dynamic mmap changes +* +* Returns true if it is. +*/ +static bool kdamond_need_update_regions (struct damon_ctx *ctx) +{ +return damon_check_reset_time_interval (&ctx->last_regions_update, + ctx->regions_update_interval); +} + +static bool damon_intersect (struct damon_region *r,struct region *re) +{ +return !(r->vm_end <= re->start || re->end <= r->vm_start); +} + +/* +* Update damon regions for the three big regions of the given task +* +* t the given task +* bregions the three big regions of the task +*/ +static void damon_apply_three_regions (struct damon_ctx *ctx, +struct damon_task *t,struct region bregions[3 ]) +{ +struct damon_region *r, *next; +unsigned int i =0 ; + +/* Remove regions which isn't in the three big regions now */
mm/damon.c static void kdamond_split_regions(struct damon_ctx *ctx) · line 717
Quoted 10 lines
mm/damon.c +10
-0+damon_for_each_region_safe (r, next, t) { +for (i =0 ; i <3 ; i++) { +if (damon_intersect (r, &bregions[i])) +break ; + } +if (i ==3 ) +damon_destroy_region (r); + } + +/* Adjust intersecting regions to fit with the threee big regions */
three
Quoted 84 lines
mm/damon.c +50
-3+for (i =0 ; i <3 ; i++) { +struct damon_region *first =NULL , *last; +struct damon_region *newr; +struct region *br; + + br = &bregions[i]; +/* Get the first and last regions which intersects with br */ +damon_for_each_region (r, t) { +if (damon_intersect (r, br)) { +if (!first) + first = r; + last = r; + } +if (r->vm_start >= br->end) +break ; + } +if (!first) { +/* no damon_region intersects with this big region */ + newr =damon_new_region (ctx, br->start, br->end); +damon_add_region (newr,damon_prev_region (r), r); + }else { + first->vm_start = br->start; + last->vm_end = br->end; + } + } +} + +/* +* Update regions for current memory mappings +*/ +static void kdamond_update_regions (struct damon_ctx *ctx) +{ +struct region three_regions[3 ]; +struct damon_task *t; + +damon_for_each_task (ctx, t) { +if (damon_three_regions_of (t, three_regions)) +continue ; +damon_apply_three_regions (ctx, t, three_regions); + } +} +/* * Check whether current monitoring should be stopped * @@ -735,6 +821,9 @@ static int kdamond_fn(void *data)kdamond_split_regions (ctx); } +if (kdamond_need_update_regions (ctx)) +kdamond_update_regions (ctx); +usleep_range (ctx->sample_interval, ctx->sample_interval +1 ); }damon_for_each_task (ctx, t) {@@ -820,6 +909,7 @@ static int damon_set_pids(struct damon_ctx *ctx,* * sample_int time interval between samplings * aggr_int time interval between aggregations +* regions_update_int time interval between vma update checks * min_nr_reg minimal number of regions * max_nr_reg maximum number of regions * @@ -828,9 +918,9 @@ static int damon_set_pids(struct damon_ctx *ctx,* * Returns 0 on success, negative error code otherwise. */ -static 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) +static 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) {if (min_nr_reg <3 ) { pr_err("min_nr_regions (%lu) should be bigger than 2\n",@@ -845,6 +935,7 @@ static int damon_set_attrs(struct damon_ctx *ctx, ctx->sample_interval = sample_int; ctx->aggr_interval = aggr_int; + ctx->regions_update_interval = regions_update_int; ctx->min_nr_regions = min_nr_reg; ctx->max_nr_regions = max_nr_reg;return 0 ;
Re: Re: [PATCH v6 04/14] mm/damon: Apply dynamic memory mapping changes
Quoted 15 lines · On Tue, 10 Mar 2020 09:00:26 +0000 Jonathan Cameron…
Quoted 10 lines · On Mon, 24 Feb 2020 13:30:37 +0100 SeongJae Park <[email protected]> wrote:
From: 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``).
Signed-off-by SeongJae Park <[email protected]>Trivial inline. Otherwise makes sense to me.
[...]
Quoted 11 lines
Quoted 11 lines
mm/damon.c +11
-0+static void damon_apply_three_regions (struct damon_ctx *ctx, +struct damon_task *t,struct region bregions[3 ]) +{ +struct damon_region *r, *next; +unsigned int i =0 ; + +/* Remove regions which isn't in the three big regions now */ +damon_for_each_region_safe (r, next, t) { +for (i =0 ; i <3 ; i++) { +if (damon_intersect (r, &bregions[i])) +break ;
Quoted 8 lines
mm/damon.c static void kdamond_split_regions(struct damon_ctx *ctx) · line 717
Quoted 6 lines
mm/damon.c +6
-0+ } +if (i ==3 ) +damon_destroy_region (r); + } + +/* Adjust intersecting regions to fit with the threee big regions */ three
Good eye! Thanks for finding :)
[...]
PATCH v6 5/14 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 pattrns 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.
--- mm/damon.c | 8 ++++++++ 1 file changed, 8 insertions(+)
mm/damon.c +8 -0
@@ -83,6 +83,10 @@ struct damon_ctx {struct rnd_state rndseed;struct list_head tasks_list;/* 'damon_task' objects */ + +/* callbacks */ +void (*sample_cb)(struct damon_ctx *context); +void (*aggregate_cb)(struct damon_ctx *context); };/* Get a random number in [l, r) */
@@ -814,9 +818,13 @@ static int kdamond_fn(void *data) }mmput (mm); } +if (ctx->sample_cb) + ctx->sample_cb (ctx);if (kdamond_aggregate_interval_passed (ctx)) {kdamond_merge_regions (ctx, max_nr_accesses /10 ); +if (ctx->aggregate_cb) + ctx->aggregate_cb (ctx);kdamond_flush_aggregated (ctx);kdamond_split_regions (ctx); }
Signature · 1 line
2.17.1
Re: [PATCH v6 05/14] mm/damon: Implement callbacks
Quoted 5 lines · On Mon, 24 Feb 2020 13:30:38 +0100 SeongJae Park <[email protected]> wrote:
From: 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 pattrns
patterns
Quoted 39 lines
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.
Signed-off-by SeongJae Park <[email protected]>--- mm/damon.c | 8 ++++++++ 1 file changed, 8 insertions(+)mm/damon.c +8
-0@@ -83,6 +83,10 @@ struct damon_ctx {struct rnd_state rndseed;struct list_head tasks_list;/* 'damon_task' objects */ + +/* callbacks */ +void (*sample_cb)(struct damon_ctx *context); +void (*aggregate_cb)(struct damon_ctx *context); };/* Get a random number in [l, r) */ @@ -814,9 +818,13 @@ static int kdamond_fn(void *data) }mmput (mm); } +if (ctx->sample_cb) + ctx->sample_cb (ctx);if (kdamond_aggregate_interval_passed (ctx)) {kdamond_merge_regions (ctx, max_nr_accesses /10 ); +if (ctx->aggregate_cb) + ctx->aggregate_cb (ctx);kdamond_flush_aggregated (ctx);kdamond_split_regions (ctx); }
Re: Re: [PATCH v6 05/14] mm/damon: Implement callbacks
Quoted 10 lines · On Tue, 10 Mar 2020 09:01:16 +0000 Jonathan Cameron…
Quoted 5 lines · On Mon, 24 Feb 2020 13:30:38 +0100 SeongJae Park <[email protected]> wrote:
From: 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 pattrns
patterns
Thank you for finding!
Quoted 1 line
[...]
PATCH v6 6/14 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.
--- mm/damon.c | 126 +++++++++++++++++++++++++++++++++++++++++++++++++++-- 1 file changed, 123 insertions(+), 3 deletions(-)
mm/damon.c +123 -3
@@ -76,6 +76,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;spinlock_t kdamond_lock;
@@ -89,6 +94,8 @@ struct damon_ctx {void (*aggregate_cb)(struct damon_ctx *context); }; +#define MAX_RFILE_PATH_LEN 256 +/* Get a random number in [l, r) */ #define damon_rand (ctx, l, r) (l + prandom_u32_state(&ctx->rndseed) % (r - l))
@@ -550,16 +557,81 @@ static bool kdamond_aggregate_interval_passed(struct damon_ctx *ctx) }/* -* Reset the aggregated monitoring results +* Flush the content in the result buffer to the result file +*/ +static void damon_flush_rbuffer (struct damon_ctx *ctx) +{ +ssize_t sz; +loff_t pos; +struct file *rfile; + +while (ctx->rbuf_offset) { + pos =0 ; + rfile =filp_open (ctx->rfile_path,O_CREAT |O_RDWR |O_APPEND , +0644 ); +if (IS_ERR (rfile)) { +pr_err ("Cannot open the result file %s\n" , + ctx->rfile_path); +return ; + } + + sz =kernel_write (rfile, ctx->rbuf, ctx->rbuf_offset, &pos); +filp_close (rfile,NULL ); + + ctx->rbuf_offset -= sz; + } +} + +/* +* Write a data into the result buffer +*/ +static void damon_write_rbuf (struct damon_ctx *ctx,void *data,ssize_t size) +{ +if (!ctx->rbuf_len || !ctx->rbuf) +return ; +if (ctx->rbuf_offset + size > ctx->rbuf_len) +damon_flush_rbuffer (ctx); + +memcpy (&ctx->rbuf[ctx->rbuf_offset], data, size); + ctx->rbuf_offset += size; +} + +/* +* Flush the aggregated monitoring results to the result buffer +* +* Stores current tracking results to the result buffer and reset 'nr_accesses' +* of each regions. The format for the result buffer is as below: +* +* <time> <number of tasks> <array of task infos> +* +* task info: <pid> <number of regions> <array of region infos> +* region info: <start address> <end address> <nr_accesses> */ static void kdamond_flush_aggregated (struct damon_ctx *c) {struct damon_task *t; -struct damon_region *r; +struct timespec64 now; +unsigned int nr; + +ktime_get_coarse_ts64 (&now); + +damon_write_rbuf (c, &now,sizeof (struct timespec64 )); + nr =nr_damon_tasks (c); +damon_write_rbuf (c, &nr,sizeof (nr));damon_for_each_task (c, t) { -damon_for_each_region (r, t) +struct damon_region *r; + +damon_write_rbuf (c, &t->pid,sizeof (t->pid)); + nr =nr_damon_regions (t); +damon_write_rbuf (c, &nr,sizeof (nr)); +damon_for_each_region (r, t) { +damon_write_rbuf (c, &r->vm_start,sizeof (r->vm_start)); +damon_write_rbuf (c, &r->vm_end,sizeof (r->vm_end)); +damon_write_rbuf (c, &r->nr_accesses, +sizeof (r->nr_accesses)); r->nr_accesses =0 ; + } } }
@@ -834,6 +906,7 @@ static int kdamond_fn(void *data)usleep_range (ctx->sample_interval, ctx->sample_interval +1 ); } +damon_flush_rbuffer (ctx);damon_for_each_task (ctx, t) {damon_for_each_region_safe (r, next, t)damon_destroy_region (r);
@@ -912,6 +985,53 @@ static int damon_set_pids(struct damon_ctx *ctx,return 0 ; } +/* +* Set attributes for the recording +* +* ctx target kdamond context +* rbuf_len length of the result buffer +* rfile_path path to the monitor result files +* +* Setting 'rbuf_len' 0 disables recording. +* +* This function should not be called while the kdamond is running. +* +* Returns 0 on success, negative error code otherwise. +*/ +static int damon_set_recording (struct damon_ctx *ctx, +unsigned int rbuf_len,char *rfile_path) +{ +size_t rfile_path_len; + +if (rbuf_len >4 *1024 *1024 ) { +pr_err ("too long (>%d) result buffer length\n" , +4 *1024 *1024 ); +return -EINVAL ; + } + rfile_path_len =strnlen (rfile_path,MAX_RFILE_PATH_LEN ); +if (rfile_path_len >=MAX_RFILE_PATH_LEN ) { +pr_err ("too long (>%d) result file path %s\n" , +MAX_RFILE_PATH_LEN , rfile_path); +return -EINVAL ; + } + ctx->rbuf_len = rbuf_len; +kfree (ctx->rbuf); +kfree (ctx->rfile_path); + ctx->rfile_path =NULL ; +if (!rbuf_len) { + ctx->rbuf =NULL ; + }else { + ctx->rbuf =kvmalloc (rbuf_len,GFP_KERNEL ); +if (!ctx->rbuf) +return -ENOMEM ; + } + ctx->rfile_path =kmalloc (rfile_path_len +1 ,GFP_KERNEL ); +if (!ctx->rfile_path) +return -ENOMEM ; +strncpy (ctx->rfile_path, rfile_path, rfile_path_len +1 ); +return 0 ; +} +/* * Set attributes for the monitoring *
Signature · 1 line
2.17.1
Re: [PATCH v6 06/14] mm/damon: Implement access pattern recording
Quoted 10 lines · On Mon, 24 Feb 2020 13:30:39 +0100 SeongJae Park <[email protected]> wrote:
From: 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.
Signed-off-by SeongJae Park <[email protected]>
I guess this work whilst you are still developing, but I'm not convinced writing to a file should be a standard feature...
Quoted 176 lines
--- mm/damon.c | 126 +++++++++++++++++++++++++++++++++++++++++++++++++++-- 1 file changed, 123 insertions(+), 3 deletions(-)mm/damon.c +123
-3@@ -76,6 +76,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;spinlock_t kdamond_lock;@@ -89,6 +94,8 @@ struct damon_ctx {void (*aggregate_cb)(struct damon_ctx *context); }; +#define MAX_RFILE_PATH_LEN 256 +/* Get a random number in [l, r) */ #define damon_rand (ctx, l, r) (l + prandom_u32_state(&ctx->rndseed) % (r - l))@@ -550,16 +557,81 @@ static bool kdamond_aggregate_interval_passed(struct damon_ctx *ctx) }/* -* Reset the aggregated monitoring results +* Flush the content in the result buffer to the result file +*/ +static void damon_flush_rbuffer (struct damon_ctx *ctx) +{ +ssize_t sz; +loff_t pos; +struct file *rfile; + +while (ctx->rbuf_offset) { + pos =0 ; + rfile =filp_open (ctx->rfile_path,O_CREAT |O_RDWR |O_APPEND , +0644 ); +if (IS_ERR (rfile)) { +pr_err ("Cannot open the result file %s\n" , + ctx->rfile_path); +return ; + } + + sz =kernel_write (rfile, ctx->rbuf, ctx->rbuf_offset, &pos); +filp_close (rfile,NULL ); + + ctx->rbuf_offset -= sz; + } +} + +/* +* Write a data into the result buffer +*/ +static void damon_write_rbuf (struct damon_ctx *ctx,void *data,ssize_t size) +{ +if (!ctx->rbuf_len || !ctx->rbuf) +return ; +if (ctx->rbuf_offset + size > ctx->rbuf_len) +damon_flush_rbuffer (ctx); + +memcpy (&ctx->rbuf[ctx->rbuf_offset], data, size); + ctx->rbuf_offset += size; +} + +/* +* Flush the aggregated monitoring results to the result buffer +* +* Stores current tracking results to the result buffer and reset 'nr_accesses' +* of each regions. The format for the result buffer is as below: +* +* <time> <number of tasks> <array of task infos> +* +* task info: <pid> <number of regions> <array of region infos> +* region info: <start address> <end address> <nr_accesses> */ static void kdamond_flush_aggregated (struct damon_ctx *c) {struct damon_task *t; -struct damon_region *r; +struct timespec64 now; +unsigned int nr; + +ktime_get_coarse_ts64 (&now); + +damon_write_rbuf (c, &now,sizeof (struct timespec64 )); + nr =nr_damon_tasks (c); +damon_write_rbuf (c, &nr,sizeof (nr));damon_for_each_task (c, t) { -damon_for_each_region (r, t) +struct damon_region *r; + +damon_write_rbuf (c, &t->pid,sizeof (t->pid)); + nr =nr_damon_regions (t); +damon_write_rbuf (c, &nr,sizeof (nr)); +damon_for_each_region (r, t) { +damon_write_rbuf (c, &r->vm_start,sizeof (r->vm_start)); +damon_write_rbuf (c, &r->vm_end,sizeof (r->vm_end)); +damon_write_rbuf (c, &r->nr_accesses, +sizeof (r->nr_accesses)); r->nr_accesses =0 ; + } } }@@ -834,6 +906,7 @@ static int kdamond_fn(void *data)usleep_range (ctx->sample_interval, ctx->sample_interval +1 ); } +damon_flush_rbuffer (ctx);damon_for_each_task (ctx, t) {damon_for_each_region_safe (r, next, t)damon_destroy_region (r);@@ -912,6 +985,53 @@ static int damon_set_pids(struct damon_ctx *ctx,return 0 ; } +/* +* Set attributes for the recording +* +* ctx target kdamond context +* rbuf_len length of the result buffer +* rfile_path path to the monitor result files +* +* Setting 'rbuf_len' 0 disables recording. +* +* This function should not be called while the kdamond is running. +* +* Returns 0 on success, negative error code otherwise. +*/ +static int damon_set_recording (struct damon_ctx *ctx, +unsigned int rbuf_len,char *rfile_path) +{ +size_t rfile_path_len; + +if (rbuf_len >4 *1024 *1024 ) { +pr_err ("too long (>%d) result buffer length\n" , +4 *1024 *1024 ); +return -EINVAL ; + } + rfile_path_len =strnlen (rfile_path,MAX_RFILE_PATH_LEN ); +if (rfile_path_len >=MAX_RFILE_PATH_LEN ) { +pr_err ("too long (>%d) result file path %s\n" , +MAX_RFILE_PATH_LEN , rfile_path); +return -EINVAL ; + } + ctx->rbuf_len = rbuf_len; +kfree (ctx->rbuf); +kfree (ctx->rfile_path); + ctx->rfile_path =NULL ; +if (!rbuf_len) { + ctx->rbuf =NULL ; + }else { + ctx->rbuf =kvmalloc (rbuf_len,GFP_KERNEL ); +if (!ctx->rbuf) +return -ENOMEM ; + } + ctx->rfile_path =kmalloc (rfile_path_len +1 ,GFP_KERNEL ); +if (!ctx->rfile_path) +return -ENOMEM ; +strncpy (ctx->rfile_path, rfile_path, rfile_path_len +1 ); +return 0 ; +} +/* * Set attributes for the monitoring *
Re: Re: [PATCH v6 06/14] mm/damon: Implement access pattern recording
Quoted 12 lines · On Tue, 10 Mar 2020 09:01:34 +0000 Jonathan Cameron…
Quoted 9 lines · On Mon, 24 Feb 2020 13:30:39 +0100 SeongJae Park <[email protected]> wrote:
From: 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.
Quoted 4 lines
Quoted 1 line
Signed-off-by SeongJae Park <[email protected]>I guess this work whilst you are still developing, but I'm not convinced writing to a file should be a standard feature...
I also not sure whether this is right feature of the kernel or not, but this would minimize many efforts in user space. I also thought that this might be not out of the intention of the 'kernel_write()'.
Nonetheless, this patch could be simply removed, as DAMON supports tracepoints and the recording can be implemented on user space using it.
Could I ask your other suggestions for this feature?
Thanks,
SeongJae Park
Quoted 2 lines
Quoted 2 lines
---
[...]
PATCH v6 7/14 mm/damon: Implement kernel space API
In reply to SeongJae ParkFrom: SeongJae Park <[email protected]>
This commit implements the DAMON api for the kernel. Other kernel code can use DAMON by calling damon_start() and damon_stop() with their own 'struct damon_ctx'.
--- include/linux/damon.h | 71 +++++++++++++++++++++++++++++++++++++++++++ mm/damon.c | 71 +++++++++---------------------------------- 2 files changed, 85 insertions(+), 57 deletions(-) create mode 100644 include/linux/damon.h
include/linux/damon.h new file +71 -0
@@ -0,0 +1,71 @@ +/* SPDX-License-Identifier: GPL-2.0 */ +/* +* DAMON api +* +* Copyright 2019 Amazon.com, Inc. or its affiliates. All rights reserved. +* +* Author: SeongJae Park <[email protected]> +*/ + +#ifndef _DAMON_H_ +#define _DAMON_H_ + +#include <linux/random.h> +#include <linux/spinlock_types.h> +#include <linux/time64.h> +#include <linux/types.h> + +/* Represents a monitoring target region on the virtual address space */ +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 { +unsigned long pid; +struct list_head regions_list; +struct list_head list; +}; + +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; + +unsigned char *rbuf; +unsigned int rbuf_len; +unsigned int rbuf_offset; +char *rfile_path; + +struct task_struct *kdamond; +bool kdamond_stop; +spinlock_t kdamond_lock; + +struct rnd_state rndseed; + +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, +unsigned long *pids,ssize_t nr_pids); +int damon_set_recording (struct damon_ctx *ctx, +unsigned int rbuf_len,char *rfile_path); +int damon_set_attrs (struct damon_ctx *ctx,unsigned long s,unsigned long a, +unsigned long r,unsigned long min,unsigned long max); +int damon_start (struct damon_ctx *ctx); +int damon_stop (struct damon_ctx *ctx); + +#endif
mm/damon.c +14 -57
104 lines not on this page · raw message
Signature · 1 line
2.17.1
Re: [PATCH v6 07/14] mm/damon: Implement kernel space API
Quoted 7 lines · On Mon, 24 Feb 2020 13:30:40 +0100 SeongJae Park <[email protected]> wrote:
From: SeongJae Park <[email protected]>
This commit implements the DAMON api for the kernel. Other kernel code can use DAMON by calling
damon_start()anddamon_stop()with their own 'structdamon_ctx'.Signed-off-by SeongJae Park <[email protected]>
Seems like it would have been easier to create the header as you went along and avoid the need to have the bits here dropping static.
Or the moves for that matter.
Also, ideally have full kernel-doc for anything that forms part of an interface that is intended for use by others.
Jonathan
Quoted 196 lines
--- include/linux/damon.h | 71 +++++++++++++++++++++++++++++++++++++++++++ mm/damon.c | 71 +++++++++---------------------------------- 2 files changed, 85 insertions(+), 57 deletions(-) create mode 100644 include/linux/damon.hinclude/linux/damon.h new file +71
-0@@ -0,0 +1,71 @@ +/* SPDX-License-Identifier: GPL-2.0 */ +/* +* DAMON api +* +* Copyright 2019 Amazon.com, Inc. or its affiliates. All rights reserved. +* +* Author: SeongJae Park <[email protected]> +*/ + +#ifndef _DAMON_H_ +#define _DAMON_H_ + +#include <linux/random.h> +#include <linux/spinlock_types.h> +#include <linux/time64.h> +#include <linux/types.h> + +/* Represents a monitoring target region on the virtual address space */ +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 { +unsigned long pid; +struct list_head regions_list; +struct list_head list; +}; + +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; + +unsigned char *rbuf; +unsigned int rbuf_len; +unsigned int rbuf_offset; +char *rfile_path; + +struct task_struct *kdamond; +bool kdamond_stop; +spinlock_t kdamond_lock; + +struct rnd_state rndseed; + +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, +unsigned long *pids,ssize_t nr_pids); +int damon_set_recording (struct damon_ctx *ctx, +unsigned int rbuf_len,char *rfile_path); +int damon_set_attrs (struct damon_ctx *ctx,unsigned long s,unsigned long a, +unsigned long r,unsigned long min,unsigned long max); +int damon_start (struct damon_ctx *ctx); +int damon_stop (struct damon_ctx *ctx); + +#endif mm/damon.c +14
-57@@ -9,6 +9,7 @@#define pr_fmt (fmt) "damon: " fmt +#include <linux/damon.h> #include <linux/delay.h> #include <linux/kthread.h> #include <linux/mm.h> @@ -40,60 +41,6 @@#define damon_for_each_task_safe (ctx, t, next) \ list_for_each_entry_safe(t, next, &(ctx)->tasks_list, list) -/* Represents a monitoring target region on the virtual address space */ -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 { -unsigned long pid; -struct list_head regions_list; -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. And for each -* 'regions_update_interval', damon checks whether the memory mapping of the -* target tasks has changed (e.g., by mmap() calls from the applications) and -* applies the changes. -* -* 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; - -unsigned char *rbuf; -unsigned int rbuf_len; -unsigned int rbuf_offset; -char *rfile_path; - -struct task_struct *kdamond; -bool kdamond_stop; -spinlock_t kdamond_lock; - -struct rnd_state rndseed; - -struct list_head tasks_list;/* 'damon_task' objects */ - -/* callbacks */ -void (*sample_cb)(struct damon_ctx *context); -void (*aggregate_cb)(struct damon_ctx *context); -}; -#define MAX_RFILE_PATH_LEN 256/* Get a random number in [l, r) */ @@ -961,10 +908,20 @@ static int damon_turn_kdamond(struct damon_ctx *ctx, bool on)return 0 ; } +int damon_start (struct damon_ctx *ctx) +{ +return damon_turn_kdamond (ctx, true); +} + +int damon_stop (struct damon_ctx *ctx) +{ +return damon_turn_kdamond (ctx, false); +} +/* * This function should not be called while the kdamond is running. */ -static int damon_set_pids (struct damon_ctx *ctx, +int damon_set_pids (struct damon_ctx *ctx,unsigned long *pids,ssize_t nr_pids) {ssize_t i;@@ -998,7 +955,7 @@ static int damon_set_pids(struct damon_ctx *ctx,* * Returns 0 on success, negative error code otherwise. */ -static int damon_set_recording (struct damon_ctx *ctx, +int damon_set_recording (struct damon_ctx *ctx,unsigned int rbuf_len,char *rfile_path) {size_t rfile_path_len;@@ -1046,7 +1003,7 @@ static int damon_set_recording(struct damon_ctx *ctx,* * Returns 0 on success, negative error code otherwise. */ -static int damon_set_attrs (struct damon_ctx *ctx,unsigned long sample_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) {
Re: Re: [PATCH v6 07/14] mm/damon: Implement kernel space API
Quoted 5 lines · On Tue, 10 Mar 2020 09:01:52 +0000 Jonathan Cameron…
Quoted 2 lines · On Mon, 24 Feb 2020 13:30:40 +0100 SeongJae Park <[email protected]> wrote:
From: SeongJae Park <[email protected]>
Quoted 8 lines
Quoted 5 lines
This commit implements the DAMON api for the kernel. Other kernel code can use DAMON by calling
damon_start()anddamon_stop()with their own 'structdamon_ctx'.Signed-off-by SeongJae Park <[email protected]>Seems like it would have been easier to create the header as you went along and avoid the need to have the bits here dropping static.
Yes, exporing the API from the beginning must be much simpler and easy to review!
Quoted 5 lines
Or the moves for that matter.
Also, ideally have full kernel-doc for anything that forms part of an interface that is intended for use by others.
Agreed, will use the kernel-doc comments!
Thanks,
SeongJae Park
Quoted 4 lines
Jonathan
Quoted 1 line
---
[...]
PATCH v6 8/14 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 starts the monitoring.
Record
------
DAMON support 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 be 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 | 377 ++++++++++++++++++++++++++++++++++++++++++++++++++++- 1 file changed, 376 insertions(+), 1 deletion(-)
mm/damon.c +376 -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>
@@ -46,6 +47,24 @@/* Get a random number in [l, r) */ #define damon_rand (ctx, l, r) (l + prandom_u32_state(&ctx->rndseed) % (r - l)) +/* +* 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 'aggr_interval' and then flushes it to the result buffer if +* an 'aggr_interval' surpassed. And for each 'regions_update_interval', damon +* checks whether the memory mapping of the target tasks has changed (e.g., by +* mmap() calls from the applications) and applies the changes. +* +* All time intervals are in micro-seconds. +*/ +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 *
@@ -1026,15 +1045,371 @@ int damon_set_attrs(struct damon_ctx *ctx, unsigned long sample_int,return 0 ; } +/* +* debugfs functions +*/ + +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 ret; + +spin_lock (&ctx->kdamond_lock); + monitor_on = ctx->kdamond !=NULL ; +spin_unlock (&ctx->kdamond_lock); + + ret =snprintf (monitor_on_buf,5 , monitor_on ?"on\n" :"off\n" ); + +return simple_read_from_buffer (buf, count, ppos, monitor_on_buf, ret); +} + +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; +bool on = false; +char cmdbuf[5 ]; + + 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 )) + on = true; +else if (!strncmp (cmdbuf,"off" ,5 )) + on = false; +else +return -EINVAL ; + +if (damon_turn_kdamond (ctx, on)) +return -EINVAL ; + +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,"%lu " , 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 unsigned long *str_to_pids (const char *str,ssize_t len, +ssize_t *nr_pids) +{ +unsigned long *pids; +const int max_nr_pids =32 ; +unsigned long pid; +int pos =0 , parsed, ret; + + *nr_pids =0 ; + pids =kmalloc_array (max_nr_pids,sizeof (unsigned long ),GFP_KERNEL ); +if (!pids) +return NULL ; +while (*nr_pids < max_nr_pids && pos < len) { + ret =sscanf (&str[pos],"%lu%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; +unsigned long *targets; +ssize_t nr_targets; +ssize_t ret; + + kbuf =kmalloc_array (count,sizeof (char ),GFP_KERNEL ); +if (!kbuf) +return -ENOMEM ; + + ret =simple_write_to_buffer (kbuf,512 , ppos, buf, count); +if (ret <0 ) + goto out; + + targets =str_to_pids (kbuf, ret, &nr_targets); +if (!targets) { + ret = -ENOMEM ; + goto out; + } + +spin_lock (&ctx->kdamond_lock); +if (ctx->kdamond) + goto monitor_running; + +damon_set_pids (ctx, targets, nr_targets); +spin_unlock (&ctx->kdamond_lock); + + goto free_targets_out; + +monitor_running: +spin_unlock (&ctx->kdamond_lock); +pr_err ("%s: kdamond is running. Turn it off first.\n" , __func__); + ret = -EINVAL ; +free_targets_out: +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; + + kbuf =kmalloc_array (count +1 ,sizeof (char ),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; + } + +spin_lock (&ctx->kdamond_lock); +if (ctx->kdamond) + goto monitor_running; + +damon_set_recording (ctx, rbuf_len, rfile_path); +spin_unlock (&ctx->kdamond_lock); + + goto out; + +monitor_running: +spin_unlock (&ctx->kdamond_lock); +pr_err ("%s: kdamond is running. Turn it off first.\n" , __func__); + ret = -EINVAL ; +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; + + kbuf =kmalloc_array (count,sizeof (char ),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; + } + +spin_lock (&ctx->kdamond_lock); +if (ctx->kdamond) + goto monitor_running; + +damon_set_attrs (ctx, s, a, r, minr, maxr); +spin_unlock (&ctx->kdamond_lock); + + goto out; + +monitor_running: +spin_unlock (&ctx->kdamond_lock); +pr_err ("%s: kdamond is running. Turn it off first.\n" , __func__); + ret = -EINVAL ; +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 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; + + ctx->rbuf_offset =0 ; + rc =damon_set_recording (ctx,1024 *1024 ,"/damon.data" ); +if (rc) +return rc; + + ctx->kdamond =NULL ; + ctx->kdamond_stop = false; +spin_lock_init (&ctx->kdamond_lock); + +prandom_seed_state (&ctx->rndseed,42 ); +INIT_LIST_HEAD (&ctx->tasks_list); + + ctx->sample_cb =NULL ; + ctx->aggregate_cb =NULL ; + +return 0 ; +} +static int __init damon_init (void ) { +int rc; +pr_info ("init\n" ); -return 0 ; + rc =damon_init_user_ctx (); +if (rc) +return rc; + +return debugfs_init (); } static void __exit damon_exit(void) { +damon_turn_kdamond (&damon_user_ctx, false); +debugfs_remove_recursive (debugfs_root); + +kfree (damon_user_ctx.rbuf); +kfree (damon_user_ctx.rfile_path); +pr_info ("exit\n" ); }
Signature · 1 line
2.17.1
Re: [PATCH v6 08/14] mm/damon: Add debugfs interface
Quoted 67 lines · On Mon, 24 Feb 2020 13:30:41 +0100 SeongJae Park <[email protected]> wrote:
From: 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 starts the monitoring.
Record
------DAMON support 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 be 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
Quoted 5 lines
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, ``-EINVAL`` will be returned.
Signed-off-by SeongJae Park <[email protected]>
Some of the code in here seems a bit fragile and convoluted.
Quoted 42 lines
--- mm/damon.c | 377 ++++++++++++++++++++++++++++++++++++++++++++++++++++- 1 file changed, 376 insertions(+), 1 deletion(-)mm/damon.c +19
-0@@ -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> @@ -46,6 +47,24 @@/* Get a random number in [l, r) */ #define damon_rand (ctx, l, r) (l + prandom_u32_state(&ctx->rndseed) % (r - l)) +/* +* 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 'aggr_interval' and then flushes it to the result buffer if +* an 'aggr_interval' surpassed. And for each 'regions_update_interval', damon +* checks whether the memory mapping of the target tasks has changed (e.g., by +* mmap() calls from the applications) and applies the changes. +* +* All time intervals are in micro-seconds. +*/ +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 *
mm/damon.c int damon_set_attrs(struct damon_ctx *ctx, unsigned long sample_int, · line 1049
Quoted 5 lines
mm/damon.c +2
-0@@ -1026,15 +1045,371 @@ int damon_set_attrs(struct damon_ctx *ctx, unsigned long sample_int,return 0 ; } +/* +* debugfs functions
Seems unnecessary when their naming makes this clear.
Quoted 116 lines
mm/damon.c +116
-0+*/ + +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 ret; + +spin_lock (&ctx->kdamond_lock); + monitor_on = ctx->kdamond !=NULL ; +spin_unlock (&ctx->kdamond_lock); + + ret =snprintf (monitor_on_buf,5 , monitor_on ?"on\n" :"off\n" ); + +return simple_read_from_buffer (buf, count, ppos, monitor_on_buf, ret); +} + +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; +bool on = false; +char cmdbuf[5 ]; + + 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 )) + on = true; +else if (!strncmp (cmdbuf,"off" ,5 )) + on = false; +else +return -EINVAL ; + +if (damon_turn_kdamond (ctx, on)) +return -EINVAL ; + +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,"%lu " , 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 unsigned long *str_to_pids (const char *str,ssize_t len, +ssize_t *nr_pids) +{ +unsigned long *pids; +const int max_nr_pids =32 ; +unsigned long pid; +int pos =0 , parsed, ret; + + *nr_pids =0 ; + pids =kmalloc_array (max_nr_pids,sizeof (unsigned long ),GFP_KERNEL ); +if (!pids) +return NULL ; +while (*nr_pids < max_nr_pids && pos < len) { + ret =sscanf (&str[pos],"%lu%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;
mm/damon.c int damon_set_attrs(struct damon_ctx *ctx, unsigned long sample_int, · line 1175
Quoted 10 lines
mm/damon.c +10
-0+char *kbuf; +unsigned long *targets; +ssize_t nr_targets; +ssize_t ret; + + kbuf =kmalloc_array (count,sizeof (char ),GFP_KERNEL ); +if (!kbuf) +return -ENOMEM ; + + ret =simple_write_to_buffer (kbuf,512 , ppos, buf, count);
Why only 512?
Quoted 97 lines
mm/damon.c +97
-0+if (ret <0 ) + goto out; + + targets =str_to_pids (kbuf, ret, &nr_targets); +if (!targets) { + ret = -ENOMEM ; + goto out; + } + +spin_lock (&ctx->kdamond_lock); +if (ctx->kdamond) + goto monitor_running; + +damon_set_pids (ctx, targets, nr_targets); +spin_unlock (&ctx->kdamond_lock); + + goto free_targets_out; + +monitor_running: +spin_unlock (&ctx->kdamond_lock); +pr_err ("%s: kdamond is running. Turn it off first.\n" , __func__); + ret = -EINVAL ; +free_targets_out: +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; + + kbuf =kmalloc_array (count +1 ,sizeof (char ),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; + } + +spin_lock (&ctx->kdamond_lock); +if (ctx->kdamond) + goto monitor_running; + +damon_set_recording (ctx, rbuf_len, rfile_path); +spin_unlock (&ctx->kdamond_lock); + + goto out; + +monitor_running: +spin_unlock (&ctx->kdamond_lock); +pr_err ("%s: kdamond is running. Turn it off first.\n" , __func__); + ret = -EINVAL ; +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); +}
mm/damon.c int damon_set_attrs(struct damon_ctx *ctx, unsigned long sample_int, · line 1282
Quoted 10 lines
mm/damon.c +10
-0+ +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; + + kbuf =kmalloc_array (count,sizeof (char ),GFP_KERNEL );
malloc fine for array of characters. The checks on overflow etc cannot be
relevant here.
Quoted 16 lines
mm/damon.c +16
-0+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; + } + +spin_lock (&ctx->kdamond_lock); +if (ctx->kdamond) + goto monitor_running;
mm/damon.c int damon_set_attrs(struct damon_ctx *ctx, unsigned long sample_int, · line 1308
Quoted 10 lines
mm/damon.c +10
-0+ +damon_set_attrs (ctx, s, a, r, minr, maxr); +spin_unlock (&ctx->kdamond_lock); + + goto out; + +monitor_running: +spin_unlock (&ctx->kdamond_lock); +pr_err ("%s: kdamond is running. Turn it off first.\n" , __func__); + ret = -EINVAL ;
This complex exit path is a bad idea from maintainability point of view... Just put the pr_err and spin_unlock in the error path above.
Quoted 22 lines
mm/damon.c +22
-0+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, +};
mm/damon.c int damon_set_attrs(struct damon_ctx *ctx, unsigned long sample_int, · line 1340
Quoted 10 lines
mm/damon.c +10
-0+ +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 debugfs_init (void )
Prefix this function. Chances of sometime getting a header that includes debugfs_init feels rather too high!
Quoted 33 lines
mm/damon.c +33
-0+{ +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; +
mm/damon.c int damon_set_attrs(struct damon_ctx *ctx, unsigned long sample_int, · line 1383
Quoted 10 lines
mm/damon.c +10
-0+ ctx->rbuf_offset =0 ; + rc =damon_set_recording (ctx,1024 *1024 ,"/damon.data" ); +if (rc) +return rc; + + ctx->kdamond =NULL ; + ctx->kdamond_stop = false; +spin_lock_init (&ctx->kdamond_lock); + +prandom_seed_state (&ctx->rndseed,42 );
:)
mm/damon.c int damon_set_attrs(struct damon_ctx *ctx, unsigned long sample_int, · line 1387
Quoted 4 lines
mm/damon.c +4
-0+INIT_LIST_HEAD (&ctx->tasks_list); + + ctx->sample_cb =NULL ; + ctx->aggregate_cb =NULL ;
Should already be set to 0.
Quoted 6 lines
mm/damon.c +4
-0+ +return 0 ; +} +static int __init damon_init (void ) {
mm/damon.c int damon_set_attrs(struct damon_ctx *ctx, unsigned long sample_int, · line 1402
Quoted 10 lines
mm/damon.c +7
-1+int rc; +pr_info ("init\n" ); -return 0 ; + rc =damon_init_user_ctx (); +if (rc) +return rc; + +return debugfs_init ();
In theory no code should ever be dependent on debugfs succeeding.. There might be other daemon users so you should just eat the return code.
Quoted 13 lines
mm/damon.c +6
-0} static void __exit damon_exit(void) { +damon_turn_kdamond (&damon_user_ctx, false); +debugfs_remove_recursive (debugfs_root); + +kfree (damon_user_ctx.rbuf); +kfree (damon_user_ctx.rfile_path); +pr_info ("exit\n" ); }
Re: Re: [PATCH v6 08/14] mm/damon: Add debugfs interface
Quoted 6 lines · On Tue, 10 Mar 2020 09:02:09 +0000 Jonathan Cameron…
Quoted 3 lines · On Mon, 24 Feb 2020 13:30:41 +0100 SeongJae Park <[email protected]> wrote:
From: SeongJae Park <[email protected]>
This commit adds a debugfs interface for DAMON.
[...]
Quoted 4 lines
Quoted 2 lines
Signed-off-by SeongJae Park <[email protected]>Some of the code in here seems a bit fragile and convoluted.
Indeed, it needs many fixes.
Quoted 10 lines
Quoted 10 lines
--- mm/damon.c | 377 ++++++++++++++++++++++++++++++++++++++++++++++++++++- 1 file changed, 376 insertions(+), 1 deletion(-)mm/damon.c +0
-0@@ -10,6 +10,7 @@
[...]
Quoted 5 lines
Quoted 3 lines
+/*
+ * debugfs functionsSeems unnecessary when their naming makes this clear.
Agreed, will remove it.
Quoted 1 line
[...]
Quoted 8 lines
Quoted 8 lines
mm/damon.c +8
-0+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; +unsigned long *targets; +ssize_t nr_targets; +ssize_t ret;
Quoted 8 lines
mm/damon.c int damon_set_attrs(struct damon_ctx *ctx, unsigned long sample_int, · line 1175
Quoted 6 lines
mm/damon.c +6
-0+ + kbuf =kmalloc_array (count,sizeof (char ),GFP_KERNEL ); +if (!kbuf) +return -ENOMEM ; + + ret =simple_write_to_buffer (kbuf,512 , ppos, buf, count);Why only 512?
I might lost my mind at that time :'(
Good catch, it should be 'count'.
Quoted 1 line
[...]
Quoted 5 lines
Quoted 5 lines
mm/damon.c +5
-0+ +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;
Quoted 8 lines
mm/damon.c int damon_set_attrs(struct damon_ctx *ctx, unsigned long sample_int, · line 1282
Quoted 5 lines
mm/damon.c +5
-0+unsigned long s, a, r, minr, maxr; +char *kbuf; +ssize_t ret; + + kbuf =kmalloc_array (count,sizeof (char ),GFP_KERNEL );malloc fine for array of characters. The checks on overflow etc cannot be
relevant here.
You're right, will use 'kamlloc()' instead.
Quoted 22 lines
Quoted 22 lines
mm/damon.c +21
-0+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; + } + +spin_lock (&ctx->kdamond_lock); +if (ctx->kdamond) + goto monitor_running; + +damon_set_attrs (ctx, s, a, r, minr, maxr); +spin_unlock (&ctx->kdamond_lock); + + goto out;
Quoted 8 lines
mm/damon.c int damon_set_attrs(struct damon_ctx *ctx, unsigned long sample_int, · line 1197
Quoted 5 lines
mm/damon.c +5
-0+ +monitor_running: +spin_unlock (&ctx->kdamond_lock); +pr_err ("%s: kdamond is running. Turn it off first.\n" , __func__); + ret = -EINVAL ;This complex exit path is a bad idea from maintainability point of view... Just put the
pr_errandspin_unlockin the error path above.
Agreed, will do so.
Quoted 28 lines
Quoted 28 lines
mm/damon.c +27
-0+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,
Quoted 8 lines
mm/damon.c int damon_set_attrs(struct damon_ctx *ctx, unsigned long sample_int, · line 1340
Quoted 5 lines
mm/damon.c +5
-0+}; + +static struct dentry *debugfs_root; + +static int __init debugfs_init (void )Prefix this function. Chances of sometime getting a header that includes
debugfs_initfeels rather too high!
That's right, I will rename it.
Quoted 38 lines
Quoted 38 lines
mm/damon.c +37
-0+{ +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; + + ctx->rbuf_offset =0 ; + rc =damon_set_recording (ctx,1024 *1024 ,"/damon.data" ); +if (rc) +return rc;
Quoted 8 lines
mm/damon.c int damon_set_attrs(struct damon_ctx *ctx, unsigned long sample_int, · line 1383
Quoted 6 lines
mm/damon.c +6
-0+ + ctx->kdamond =NULL ; + ctx->kdamond_stop = false; +spin_lock_init (&ctx->kdamond_lock); + +prandom_seed_state (&ctx->rndseed,42 );:)
You got the answer ;)
Quoted 7 lines
mm/damon.c int damon_set_attrs(struct damon_ctx *ctx, unsigned long sample_int, · line 1387
Quoted 5 lines
mm/damon.c +4
-0+INIT_LIST_HEAD (&ctx->tasks_list); + + ctx->sample_cb =NULL ; + ctx->aggregate_cb =NULL ;Should already be set to 0.
Oops, right!
Quoted 11 lines
Quoted 11 lines
mm/damon.c +6
-0+ +return 0 ; +} +static int __init damon_init (void ) { +int rc; +pr_info ("init\n" );
Quoted 10 lines
mm/damon.c int damon_set_attrs(struct damon_ctx *ctx, unsigned long sample_int, · line 1402
Quoted 6 lines
mm/damon.c +5
-1-return 0 ; + rc =damon_init_user_ctx (); +if (rc) +return rc; + +return debugfs_init ();In theory no code should ever be dependent on debugfs succeeding.. There might be other daemon users so you should just eat the return code.
Right! Thank you for catching this!
Thanks,
SeongJae Park
Quoted 16 lines
Quoted 15 lines
}
static void
__exitdamon_exit(void)
{mm/damon.c +6
-0+damon_turn_kdamond (&damon_user_ctx, false); +debugfs_remove_recursive (debugfs_root); + +kfree (damon_user_ctx.rbuf); +kfree (damon_user_ctx.rfile_path); +pr_info ("exit\n" ); }
PATCH v6 9/14 mm/damon: Add a tracepoint for result writing
In reply to SeongJae ParkFrom: SeongJae Park <[email protected]>
This commit adds a tracepoint for DAMON's result buffer writing. It is called for each writing of the DAMON results and print the result data. Therefore, it would be used to easily integrated with other tracepoint supporting tracers such as perf.
--- include/trace/events/damon.h | 32 ++++++++++++++++++++++++++++++++ mm/damon.c | 4 ++++ 2 files changed, 36 insertions(+) create mode 100644 include/trace/events/damon.h
include/trace/events/damon.h new file +32 -0
@@ -0,0 +1,32 @@ +/* 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_write_rbuf, + + TP_PROTO(void *buf, const ssize_t sz), + +TP_ARGS (buf, sz), + +TP_STRUCT__entry ( +__dynamic_array (char, buf, sz) + ), + +TP_fast_assign ( + memcpy(__get_dynamic_array(buf), buf, sz); + ), + +TP_printk ("dat=%s" ,__print_hex (__get_dynamic_array (buf), +__get_dynamic_array_len (buf))) +); + +#endif /* _TRACE_DAMON_H */ + +/* This part must be outside protection */ +#include <trace/define_trace.h>
mm/damon.c +4 -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> #define damon_get_task_struct (t) \ (get_pid_task(find_vpid(t->pid), PIDTYPE_PID))
@@ -553,6 +556,7 @@ static void damon_flush_rbuffer(struct damon_ctx *ctx)*/ static void damon_write_rbuf (struct damon_ctx *ctx,void *data,ssize_t size) { +trace_damon_write_rbuf (data, size);if (!ctx->rbuf_len || !ctx->rbuf)return ;if (ctx->rbuf_offset + size > ctx->rbuf_len)
Signature · 1 line
2.17.1
Re: [PATCH v6 09/14] mm/damon: Add a tracepoint for result writing
Quoted 8 lines · On Mon, 24 Feb 2020 13:30:42 +0100 SeongJae Park <[email protected]> wrote:
From: SeongJae Park <[email protected]>
This commit adds a tracepoint for DAMON's result buffer writing. It is called for each writing of the DAMON results and print the result data. Therefore, it would be used to easily integrated with other tracepoint supporting tracers such as perf.
Signed-off-by SeongJae Park <[email protected]>
I'm curious, why at the flush of rbuf rather than using a more structured trace point for each of the writes into rbuf?
Seems it would make more sense to have a tracepoint for each record write out. Probably at the level of each task, though might be more elegant to do it at the level of each region within a task and duplicate the header stuff.
Quoted 73 lines
--- include/trace/events/damon.h | 32 ++++++++++++++++++++++++++++++++ mm/damon.c | 4 ++++ 2 files changed, 36 insertions(+) create mode 100644 include/trace/events/damon.hinclude/trace/events/damon.h new file +32
-0@@ -0,0 +1,32 @@ +/* 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_write_rbuf, + + TP_PROTO(void *buf, const ssize_t sz), + +TP_ARGS (buf, sz), + +TP_STRUCT__entry ( +__dynamic_array (char, buf, sz) + ), + +TP_fast_assign ( + memcpy(__get_dynamic_array(buf), buf, sz); + ), + +TP_printk ("dat=%s" ,__print_hex (__get_dynamic_array (buf), +__get_dynamic_array_len (buf))) +); + +#endif /* _TRACE_DAMON_H */ + +/* This part must be outside protection */ +#include <trace/define_trace.h> mm/damon.c +4
-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> #define damon_get_task_struct (t) \ (get_pid_task(find_vpid(t->pid), PIDTYPE_PID))@@ -553,6 +556,7 @@ static void damon_flush_rbuffer(struct damon_ctx *ctx)*/ static void damon_write_rbuf (struct damon_ctx *ctx,void *data,ssize_t size) { +trace_damon_write_rbuf (data, size);if (!ctx->rbuf_len || !ctx->rbuf)return ;if (ctx->rbuf_offset + size > ctx->rbuf_len)
Re: Re: [PATCH v6 09/14] mm/damon: Add a tracepoint for result writing
Quoted 10 lines · On Tue, 10 Mar 2020 09:03:31 +0000 Jonathan Cameron…
Quoted 7 lines · On Mon, 24 Feb 2020 13:30:42 +0100 SeongJae Park <[email protected]> wrote:
From: SeongJae Park <[email protected]>
This commit adds a tracepoint for DAMON's result buffer writing. It is called for each writing of the DAMON results and print the result data. Therefore, it would be used to easily integrated with other tracepoint supporting tracers such as perf.
Quoted 8 lines
Quoted 1 line
Signed-off-by SeongJae Park <[email protected]>I'm curious, why at the flush of rbuf rather than using a more structured trace point for each of the writes into rbuf?
Seems it would make more sense to have a tracepoint for each record write out. Probably at the level of each task, though might be more elegant to do it at the level of each region within a task and duplicate the header stuff.
I was worried if the format changes, but agree your suggestion is the right way. Will change so in next spin.
Thanks,
SeongJae Park
Quoted 75 lines
Quoted 74 lines
--- include/trace/events/damon.h | 32 ++++++++++++++++++++++++++++++++ mm/damon.c | 4 ++++ 2 files changed, 36 insertions(+) create mode 100644 include/trace/events/damon.hinclude/trace/events/damon.h new file +32
-0@@ -0,0 +1,32 @@ +/* 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_write_rbuf, + + TP_PROTO(void *buf, const ssize_t sz), + +TP_ARGS (buf, sz), + +TP_STRUCT__entry ( +__dynamic_array (char, buf, sz) + ), + +TP_fast_assign ( + memcpy(__get_dynamic_array(buf), buf, sz); + ), + +TP_printk ("dat=%s" ,__print_hex (__get_dynamic_array (buf), +__get_dynamic_array_len (buf))) +); + +#endif /* _TRACE_DAMON_H */ + +/* This part must be outside protection */ +#include <trace/define_trace.h> mm/damon.c +4
-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> #define damon_get_task_struct (t) \ (get_pid_task(find_vpid(t->pid), PIDTYPE_PID))@@ -553,6 +556,7 @@ static void damon_flush_rbuffer(struct damon_ctx *ctx)*/ static void damon_write_rbuf (struct damon_ctx *ctx,void *data,ssize_t size) { +trace_damon_write_rbuf (data, size);if (!ctx->rbuf_len || !ctx->rbuf)return ;if (ctx->rbuf_offset + size > ctx->rbuf_len)
PATCH v6 10/14 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/bin2txt.py | 64 +++++++ tools/damon/damo | 37 ++++ tools/damon/heats.py | 358 ++++++++++++++++++++++++++++++++++++++ tools/damon/nr_regions.py | 89 ++++++++++ tools/damon/record.py | 212 ++++++++++++++++++++++ tools/damon/report.py | 45 +++++ tools/damon/wss.py | 95 ++++++++++ 9 files changed, 937 insertions(+) create mode 100644 tools/damon/.gitignore create mode 100644 tools/damon/_dist.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/bin2txt.py new file +64 -0
64 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 +358 -0
358 lines not on this page · raw message
tools/damon/nr_regions.py new file +89 -0
89 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 +95 -0
95 lines not on this page · raw message
Signature · 1 line
2.17.1
PATCH v6 11/14 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 | 414 ++++++++++++++++++ Documentation/admin-guide/mm/index.rst | 1 + 2 files changed, 415 insertions(+) create mode 100644 Documentation/admin-guide/mm/data_access_monitor.rst
Documentation/admin-guide/mm/data_access_monitor.rst new file +414 -0
@@ -0,0 +1,414 @@ +.. SPDX-License-Identifier: GPL-2.0 + +========================== +DAMON: Data Access MONitor +========================== + +Introduction +============ + +Memory management decisions can normally be more efficient if finer data access +information is available. However, because finer information usually comes +with higher overhead, most systems including Linux made a tradeoff: Forgive +some wise decisions and use coarse information and/or light-weight heuristics. + +A number of experimental data access pattern awared memory management +optimizations say the sacrifices are +huge (2.55x slowdown). However, none of those has successfully adopted to +Linux kernel mainly due to the absence of a scalable and efficient data access +monitoring mechanism. + +DAMON is a data access monitoring solution for the problem. It is 1) accurate +enough 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 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``). + + +``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 starts the monitoring. + +Record +------ + +DAMON support 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.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 be 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, +``-EINVAL`` 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
Re: [PATCH v6 11/14] Documentation/admin-guide/mm: Add a document for DAMON
Quoted 5 lines · On Mon, 24 Feb 2020 13:30:44 +0100 SeongJae Park <[email protected]> wrote:
From: SeongJae Park <[email protected]>
This commit adds a simple document for DAMON under
Documentation/admin-guide/mm.
Nice document to get people started.
Certainly worked for me doing some initial playing around.
In general this is an interesting piece of work. I can see there are numerous
possible avenues to explore in making the monitoring more flexible, or potentially better at tracking usage whilst not breaking your fundamental 'bounded overhead'
requirement. Will be fun perhaps to explore some of those.
I'll do some more exploring and perhaps try some real world workloads.
Thanks,
Jonathan
Quoted 16 lines
Signed-off-by SeongJae Park <[email protected]>--- .../admin-guide/mm/data_access_monitor.rst | 414 ++++++++++++++++++ Documentation/admin-guide/mm/index.rst | 1 + 2 files changed, 415 insertions(+) create mode 100644 Documentation/admin-guide/mm/data_access_monitor.rstDocumentation/admin-guide/mm/data_access_monitor.rst new file +3
-0@@ -0,0 +1,414 @@ +.. SPDX-License-Identifier: GPL-2.0 + +==========================
Documentation/admin-guide/mm/data_access_monitor.rst line 13
Quoted 10 lines
Documentation/admin-guide/mm/data_access_monitor.rst new file +10
-0+DAMON: Data Access MONitor +========================== + +Introduction +============ + +Memory management decisions can normally be more efficient if finer data access +information is available. However, because finer information usually comes +with higher overhead, most systems including Linux made a tradeoff: Forgive +some wise decisions and use coarse information and/or light-weight heuristics.
I'm not sure what "Forgive some wise decisions" means...
Documentation/admin-guide/mm/data_access_monitor.rst
Quoted 4 lines
Documentation/admin-guide/mm/data_access_monitor.rst new file +4
-0+ +A number of experimental data access pattern awared memory management +optimizations say the sacrifices are +huge (2.55x slowdown).
Good to have a reference.
Quoted 1 line
However, none of those has successfully adopted to
adopted into the
Quoted 138 lines
Documentation/admin-guide/mm/data_access_monitor.rst new file +138
-0+Linux kernel mainly due to the absence of a scalable and efficient data access +monitoring mechanism. + +DAMON is a data access monitoring solution for the problem. It is 1) accurate +enough 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. +
Documentation/admin-guide/mm/data_access_monitor.rst line 165
Quoted 10 lines
Documentation/admin-guide/mm/data_access_monitor.rst new file +10
-0+ +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``).
One key part of the approach is the 3 region bit. Perhaps talk about that here somewhere?
Quoted 8 lines
Documentation/admin-guide/mm/data_access_monitor.rst new file +8
-0+ + +``debugfs`` Interface +===================== + +DAMON exports four files, ``attrs``, ``pids``, ``record``, and ``monitor_on`` +under its debugfs directory, ``<debugfs>/damon/``. +
Documentation/admin-guide/mm/data_access_monitor.rst line 183
Quoted 10 lines
Documentation/admin-guide/mm/data_access_monitor.rst new file +10
-0+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
I'm personally a great fan of human readable interfaces. Could we just split this into one file per interval? That way the file naming would make it self describing.
Quoted 19 lines
Documentation/admin-guide/mm/data_access_monitor.rst new file +19
-0+ # 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 starts the monitoring. + +Record
Documentation/admin-guide/mm/data_access_monitor.rst line 212
Quoted 10 lines
Documentation/admin-guide/mm/data_access_monitor.rst new file +10
-0+------ + +DAMON support 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
write it to record, not pids.
Quoted 11 lines
Documentation/admin-guide/mm/data_access_monitor.rst new file +11
-0+ # 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 be terminated. +Below example commands turn on, off, and check status of DAMON::
Documentation/admin-guide/mm/data_access_monitor.rst line 233
Quoted 10 lines
Documentation/admin-guide/mm/data_access_monitor.rst new file +10
-0+ + # 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, +``-EINVAL`` will be returned.
Perhaps -EBUSY would be more informative? Implies values might be fine, but the issue is 'not now'.
Quoted 193 lines
Documentation/admin-guide/mm/data_access_monitor.rst new file +181
-0+ + +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
Re: Re: [PATCH v6 11/14] Documentation/admin-guide/mm: Add a document for DAMON
Quoted 5 lines · On Tue, 10 Mar 2020 09:03:48 +0000 Jonathan Cameron…
Quoted 2 lines · On Mon, 24 Feb 2020 13:30:44 +0100 SeongJae Park <[email protected]> wrote:
From: SeongJae Park <[email protected]>
Quoted 7 lines
Quoted 3 lines
This commit adds a simple document for DAMON under
Documentation/admin-guide/mm.Nice document to get people started.
Certainly worked for me doing some initial playing around.
Great to hear that :)
Quoted 33 lines
In general this is an interesting piece of work. I can see there are numerous
possible avenues to explore in making the monitoring more flexible, or potentially better at tracking usage whilst not breaking your fundamental 'bounded overhead'
requirement. Will be fun perhaps to explore some of those.I'll do some more exploring and perhaps try some real world workloads.
Thanks,
Jonathan
Quoted 20 lines
Signed-off-by SeongJae Park <[email protected]>--- .../admin-guide/mm/data_access_monitor.rst | 414 ++++++++++++++++++ Documentation/admin-guide/mm/index.rst | 1 + 2 files changed, 415 insertions(+) create mode 100644 Documentation/admin-guide/mm/data_access_monitor.rstDocumentation/admin-guide/mm/data_access_monitor.rst new file +7
-0@@ -0,0 +1,414 @@ +.. SPDX-License-Identifier: GPL-2.0 + +========================== +DAMON: Data Access MONitor +========================== + +Introduction
Quoted 8 lines
Documentation/admin-guide/mm/data_access_monitor.rst line 13
Quoted 6 lines
Documentation/admin-guide/mm/data_access_monitor.rst new file +6
-0+============ + +Memory management decisions can normally be more efficient if finer data access +information is available. However, because finer information usually comes +with higher overhead, most systems including Linux made a tradeoff: Forgive +some wise decisions and use coarse information and/or light-weight heuristics.I'm not sure what "Forgive some wise decisions" means...
I wanted to mean that the mechanism makes no optimal decisions. Will wordsmith again.
Quoted 7 lines
Documentation/admin-guide/mm/data_access_monitor.rst
Quoted 5 lines
Documentation/admin-guide/mm/data_access_monitor.rst new file +4
-0+ +A number of experimental data access pattern awared memory management +optimizations say the sacrifices are +huge (2.55x slowdown).Good to have a reference.
:)
Quoted 4 lines
Quoted 2 lines
However, none of those has successfully adopted to
adopted into the
Thanks for correcting.
Quoted 1 line
[...]
Quoted 4 lines
Quoted 4 lines
Documentation/admin-guide/mm/data_access_monitor.rst new file +4
-0+Applying Dynamic Memory Mappings +-------------------------------- + +Only a number of small parts in the super-huge virtual address space of the
Quoted 8 lines
Documentation/admin-guide/mm/data_access_monitor.rst line 165
Quoted 5 lines
Documentation/admin-guide/mm/data_access_monitor.rst new file +5
-0+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``).One key part of the approach is the 3 region bit. Perhaps talk about that here somewhere?
I was afraid if it is too implementation detail, as this document is for admin users. Will add it in next spin, though.
Quoted 15 lines
Quoted 15 lines
Documentation/admin-guide/mm/data_access_monitor.rst new file +14
-0+ + +``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
Quoted 8 lines
Documentation/admin-guide/mm/data_access_monitor.rst line 183
Quoted 4 lines
Documentation/admin-guide/mm/data_access_monitor.rst new file +4
-0+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 > attrsI'm personally a great fan of human readable interfaces. Could we just split this into one file per interval? That way the file naming would make it self describing.
I was worried if it makes too many files. Do you think it's ok?
Quoted 24 lines
Quoted 24 lines
Documentation/admin-guide/mm/data_access_monitor.rst new file +23
-0+ # 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 starts the monitoring. + +Record +------ + +DAMON support direct monitoring result record feature. The recorded results +are first written to a buffer and flushed to a file in batch. Users can set
Quoted 8 lines
Documentation/admin-guide/mm/data_access_monitor.rst line 212
Quoted 6 lines
Documentation/admin-guide/mm/data_access_monitor.rst new file +6
-0+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" > pidswrite it to record, not pids.
Ah, good eye!
Quoted 17 lines
Quoted 17 lines
Documentation/admin-guide/mm/data_access_monitor.rst new file +16
-0+ # 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 be 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
Quoted 8 lines
Documentation/admin-guide/mm/data_access_monitor.rst line 233
Quoted 5 lines
Documentation/admin-guide/mm/data_access_monitor.rst new file +5
-0+ 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, +``-EINVAL`` will be returned.Perhaps
-EBUSYwould be more informative? Implies values might be fine, but the issue is 'not now'.
Agreed, will change so!
Thanks,
SeongJae Park
[...]
PATCH v6 12/14 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 | 604 ++++++++++++++++++++++++++++++++++++++++++++++++ mm/damon.c | 2 + 3 files changed, 617 insertions(+) create mode 100644 mm/damon-test.h
mm/Kconfig +11 -0
@@ -751,4 +751,15 @@ config DAMON be 1) accurate enough to be useful for performance-centric domains, and 2) sufficiently light-weight so that it can be applied online. +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 +604 -0
604 lines not on this page · raw message
mm/damon.c +2 -0
@@ -1423,3 +1423,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 v6 13/14 mm/damon: Add user 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 | 89 +++++++++++ .../testing/selftests/damon/debugfs_attrs.sh | 139 ++++++++++++++++++ .../testing/selftests/damon/debugfs_record.sh | 50 +++++++ 5 files changed, 313 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 +89 -0
89 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 v6 14/14 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
@@ -4611,6 +4611,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
Hello,
Quoted 26 lines · On Mon, 24 Feb 2020 13:30:33 +0100 SeongJae Park <[email protected]> wrote:
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 improvement 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 experimental data access pattern awared memory management optimizations (refer to 'Appendix A' for more details) say the sacrifices are huge. However, none of those has successfully adopted to 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.
Quoted 7 lines
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.
I have posted this patchset once per week, but skip this week because there were no comments in last week and therefore made no change in the patchset.
I think I answered to all previous comments and fixed all bugs previously found. May I ask some more comments or reviews? If I missed something or doing wrong, please let me know.
Thanks,
SeongJae Park
[...]
Quoted 38 lines · On Mon, 2 Mar 2020 12:35:12 +0100 SeongJae Park <[email protected]> wrote:
Hello,
Quoted 26 lines · On Mon, 24 Feb 2020 13:30:33 +0100 SeongJae Park <[email protected]> wrote:
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 improvement 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 experimental data access pattern awared memory management optimizations (refer to 'Appendix A' for more details) say the sacrifices are huge. However, none of those has successfully adopted to 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.
Quoted 7 lines
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.
Quoted 6 lines
I have posted this patchset once per week, but skip this week because there were no comments in last week and therefore made no change in the patchset.
I think I answered to all previous comments and fixed all bugs previously found. May I ask some more comments or reviews? If I missed something or doing wrong, please let me know.
There was no review/comment in last week, and therefore I made no change in the patchset. Instead, I ran more evaluation tests to prove the concepts in more formal way. Sharing the results with you.
I hope this evaluation results makes more REVIEWS/COMMENTS than my patchsets ;)
Thanks,
SeongJae Park
================================== >8 =========================================
TL;DR
-----
DAMON is lightweight. It makes target worloads only 0.76% slower and consumes only -0.08% more system memory.
DAMON is accurate and useful for memory management optimizations. An experimental DAMON-based operation scheme for THP removes 83.66% of THP memory overheads while preserving 40.67% of THP speedup.
Another experimental DAMON-based 'proactive reclamation' implementation reduced 22.42% of system memory usage and 88.86% of residential sets while incurring only 3.07% runtime overhead in best case.
NOTE that the experimentail THP optimization and proactive reclamation are not for production, just only for proof of concepts.
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 5s 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 106.586 107.160 (0.54) 106.535 (-0.05) 107.393 (0.76) 114.543 (7.47) parsec3/bodytrack 78.621 79.220 (0.76) 78.678 (0.07) 79.169 (0.70) 80.793 (2.76) parsec3/canneal 138.951 142.258 (2.38) 123.555 (-11.08) 133.588 (-3.86) 143.239 (3.09) parsec3/dedup 11.876 11.918 (0.35) 11.767 (-0.92) 11.957 (0.68) 13.235 (11.44) parsec3/facesim 207.761 208.159 (0.19) 204.735 (-1.46) 207.172 (-0.28) 208.663 (0.43) parsec3/ferret 190.694 192.004 (0.69) 190.345 (-0.18) 190.453 (-0.13) 192.081 (0.73) parsec3/fluidanimate 210.189 212.511 (1.10) 208.695 (-0.71) 210.843 (0.31) 213.379 (1.52) parsec3/freqmine 289.000 289.483 (0.17) 287.724 (-0.44) 289.761 (0.26) 297.878 (3.07) parsec3/raytrace 118.482 119.346 (0.73) 118.861 (0.32) 119.151 (0.56) 136.566 (15.26) parsec3/streamcluster 323.338 328.431 (1.58) 285.039 (-11.85) 296.830 (-8.20) 331.670 (2.58) parsec3/swaptions 155.853 156.826 (0.62) 154.089 (-1.13) 156.332 (0.31) 155.422 (-0.28) parsec3/vips 58.864 59.408 (0.92) 58.450 (-0.70) 58.976 (0.19) 61.068 (3.74) parsec3/x264 69.201 69.208 (0.01) 68.795 (-0.59) 71.501 (3.32) 71.766 (3.71) splash2x/barnes 81.140 80.869 (-0.33) 74.734 (-7.90) 79.859 (-1.58) 108.875 (34.18) splash2x/fft 33.442 33.579 (0.41) 22.949 (-31.38) 27.055 (-19.10) 40.261 (20.39) splash2x/lu_cb 85.064 85.441 (0.44) 84.688 (-0.44) 85.868 (0.95) 88.949 (4.57) splash2x/lu_ncb 92.606 93.615 (1.09) 90.484 (-2.29) 93.368 (0.82) 93.279 (0.73) splash2x/ocean_cp 44.672 44.826 (0.34) 43.024 (-3.69) 43.671 (-2.24) 45.889 (2.72) splash2x/ocean_ncp 81.360 81.434 (0.09) 51.157 (-37.12) 66.711 (-18.00) 91.611 (12.60) splash2x/radiosity 91.374 91.568 (0.21) 90.406 (-1.06) 91.609 (0.26) 103.790 (13.59) splash2x/radix 31.330 31.509 (0.57) 25.145 (-19.74) 26.296 (-16.07) 31.835 (1.61) splash2x/raytrace 84.715 85.274 (0.66) 82.034 (-3.16) 84.458 (-0.30) 84.967 (0.30) splash2x/volrend 86.625 87.844 (1.41) 86.206 (-0.48) 87.851 (1.42) 87.809 (1.37) splash2x/water_nsquared 231.661 233.817 (0.93) 221.024 (-4.59) 228.020 (-1.57) 236.306 (2.01) splash2x/water_spatial 89.101 89.616 (0.58) 88.845 (-0.29) 89.710 (0.68) 103.370 (16.01)
total 2992.490 3015.330 (0.76) 2857.950 (-4.50) 2937.610 (-1.83) 3137.260 (4.84)
memused.avg orig rec (overhead) thp (overhead) ethp (overhead) prcl (overhead) parsec3/blackscholes 1822704.400 1833697.600 (0.60) 1826160.400 (0.19) 1833316.800 (0.58) 1657871.000 (-9.04) parsec3/bodytrack 1417677.600 1434893.200 (1.21) 1420652.200 (0.21) 1431637.000 (0.98) 1433359.800 (1.11) parsec3/canneal 1044807.000 1056496.200 (1.12) 1037582.400 (-0.69) 1050845.200 (0.58) 1051668.200 (0.66) parsec3/dedup 2408896.200 2433019.000 (1.00) 2403343.200 (-0.23) 2421191.800 (0.51) 2461284.400 (2.17) parsec3/facesim 541808.200 554404.200 (2.32) 545591.600 (0.70) 553669.600 (2.19) 553910.600 (2.23) parsec3/ferret 319697.200 331642.400 (3.74) 320722.000 (0.32) 332126.000 (3.89) 330581.800 (3.40) parsec3/fluidanimate 573267.400 587376.200 (2.46) 574660.200 (0.24) 596108.600 (3.98) 538974.600 (-5.98) parsec3/freqmine 986872.400 998956.200 (1.22) 992037.800 (0.52) 989680.800 (0.28) 765626.800 (-22.42) parsec3/raytrace 1749641.800 1761473.200 (0.68) 1743617.800 (-0.34) 1753105.600 (0.20) 1580514.800 (-9.67) parsec3/streamcluster 125165.400 149479.600 (19.43) 122082.000 (-2.46) 140484.200 (12.24) 132027.000 (5.48) parsec3/swaptions 15515.400 29577.200 (90.63) 15692.000 (1.14) 26733.200 (72.30) 28423.000 (83.19) parsec3/vips 2954233.800 2970852.400 (0.56) 2954338.800 (0.00) 2959100.200 (0.16) 2951979.600 (-0.08) parsec3/x264 3174959.000 3191900.200 (0.53) 3192736.200 (0.56) 3201927.200 (0.85) 3194867.400 (0.63) splash2x/barnes 1215064.400 1209725.600 (-0.44) 1215945.600 (0.07) 1212294.600 (-0.23) 937605.800 (-22.83) splash2x/fft 9429331.600 9187727.600 (-2.56) 9290976.600 (-1.47) 9036430.800 (-4.17) 9409815.800 (-0.21) splash2x/lu_cb 512744.800 521964.600 (1.80) 521795.800 (1.77) 522445.600 (1.89) 346352.200 (-32.45) splash2x/lu_ncb 516623.000 523673.200 (1.36) 520129.200 (0.68) 522398.800 (1.12) 522246.200 (1.09) splash2x/ocean_cp 3325422.200 3287326.200 (-1.15) 3381646.400 (1.69) 3294803.400 (-0.92) 3287401.800 (-1.14) splash2x/ocean_ncp 3894128.600 3868638.400 (-0.65) 7065137.400 (81.43) 4844981.600 (24.42) 3811968.400 (-2.11) splash2x/radiosity 1471464.000 1470680.800 (-0.05) 1481054.600 (0.65) 1472332.200 (0.06) 521064.000 (-64.59) splash2x/radix 1698164.400 1707518.400 (0.55) 1385276.800 (-18.42) 1415885.000 (-16.62) 1717103.600 (1.12) splash2x/raytrace 45334.200 59478.400 (31.20) 52893.400 (16.67) 62366.000 (37.57) 53765.800 (18.60) splash2x/volrend 151118.400 167429.800 (10.79) 151600.000 (0.32) 163950.800 (8.49) 162873.800 (7.78) splash2x/water_nsquared 46839.000 61947.000 (32.26) 49173.600 (4.98) 58301.200 (24.47) 56678.400 (21.01) splash2x/water_spatial 666960.000 674851.600 (1.18) 668957.600 (0.30) 673287.400 (0.95) 463938.800 (-30.44)
total 40108199.000 40074800.000 (-0.08) 42933800.000 (7.04) 40569300.000 (1.15) 37972000.000 (-5.33)
DAMON Overheads
~~~~~~~~~~~~~~~
In total, DAMON recording feature incurs 0.76% runtime overhead (up to 2.38% in worst case with 'parsec3/canneal') and -0.08% 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. In detail, 19%, 90%, 31%, 10%, and 32% overheads shown for parsec3/streamcluster (125 MiB), parsec3/swaptions (15 MiB), splash2x/raytrace (45 MiB), splash2x/volrend (151 MiB), and splash2x/water_nsquared (46 MiB)). 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.5% speedup but incurs 7.04% memory overhead. It achieves 37.12% speedup in best case, but 81.43% 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 1.83% speedup and 1.15% memory overhead. In other words, 'ethp' removes 83.66% of THP memory waste while preserving 40.67% of THP speedup in total.
In case of the 'splash2x/ocean_ncp', which is best for speedup but worst for memory overhead of THP, 'ethp' removes 70% of THP memory space overhead while preserving 48.49% 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 4.84% runtime overhead in total while achieving 5.33% 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 prcl (overhead) parsec3/blackscholes 589633.600 329611.400 (-44.10) parsec3/bodytrack 32217.600 21652.200 (-32.79) parsec3/canneal 840411.600 838931.000 (-0.18) parsec3/dedup 1223907.600 835473.600 (-31.74) parsec3/facesim 311271.600 311070.200 (-0.06) parsec3/ferret 99635.600 89290.800 (-10.38) parsec3/fluidanimate 531760.000 484945.600 (-8.80) parsec3/freqmine 552609.400 61583.600 (-88.86) parsec3/raytrace 896446.600 317792.000 (-64.55) parsec3/streamcluster 110793.600 108061.600 (-2.47) parsec3/swaptions 5604.600 2694.400 (-51.93) parsec3/vips 31779.600 28422.200 (-10.56) parsec3/x264 81943.800 81874.600 (-0.08) splash2x/barnes 1219389.600 619038.600 (-49.23) splash2x/fft 9597789.600 7264542.200 (-24.31) splash2x/lu_cb 510524.000 327813.600 (-35.79) splash2x/lu_ncb 510131.200 510146.800 (0.00) splash2x/ocean_cp 3406968.600 3341620.400 (-1.92) splash2x/ocean_ncp 3919926.800 3670768.800 (-6.36) splash2x/radiosity 1474387.800 254678.600 (-82.73) splash2x/radix 1723283.200 1763916.000 (2.36) splash2x/raytrace 23194.400 17454.000 (-24.75) splash2x/volrend 43980.000 32524.600 (-26.05) splash2x/water_nsquared 29327.200 23989.200 (-18.20) splash2x/water_spatial 656323.200 381068.600 (-41.94)
total 28423300.000 21719000.000 (-23.59)
In total, 23.59% of residential sets were reduced.
With parsec3/freqmine, 'prcl' reduced 22.42% of system memory usage and 88.86% of residential sets while incurring only 3.07% runtime overhead.
Quoted 6 lines · SeongJae Park
From: SeongJae Park <[email protected]>
Introduction
============
Quoted 7 lines
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 improvement 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 experimental data access pattern awared memory management
why experimental? [5,8] are deployed across Google fleet.
Quoted 2 lines
optimizations (refer to 'Appendix A' for more details) say the sacrifices are huge.
It depends. For servers where stranded CPUs are common, the cost is not that huge.
Quoted 1 line
However, none of those has successfully adopted to Linux kernel mainly
adopted? I think you mean accepted or merged
Quoted 9 lines
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)
94.242.42x ?
Quoted 63 lines
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.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.
Visualized Outputs of DAMON
===========================For intuitively understanding of DAMON, I made web pages[1-8] showing the visualized dynamic data access pattern of various realistic workloads, which I picked up from 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.htmlData Access Monitoring-based Operation Schemes
==============================================As 'Appendix D' describes, DAMON can be used for data access monitoring-based operation schemes (DAMOS). RFC patchsets for DAMOS are already available
(https://lore.kernel.org/linux-mm/[email protected]/).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.
The detailed setup and number will be posted soon with the next RFC patchset for DAMOS. The posting is currently scheduled for tomorrow.
Frequently Asked Questions
==========================
Quoted 11 lines
Q: Why DAMON is not integrated with perf?
A: From the perspective of perf like profilers, DAMON can be thought of as a data source in kernel, like the tracepoints, the pressure stall information (psi), or the idle page tracking. Thus, it is easy to integrate DAMON with the profilers. 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 a debugfs interface based user space tool for DAMON. It can be used to record, visualize, and analyze data access patterns of target processes in a convenient way.
Oh it is monitoring at the process level.
Quoted 22 lines
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' 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.Evaluations
===========
Quoted 6 lines
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].
The paper [2] is behind a paywall, upload it somewhere for free access.
Quoted 5 lines
Quality
-------
Quoted 8 lines
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.
Did you change the applications to add mlock() or was it done dynamically through some new interface? The hot memory / working set changes, so, dynamically m[un]locking makes sense.
Quoted 3 lines
The optimized versions consistently show speedup (2.55x in best case, 1.65x in average) under memory pressure.
Do tell more about these 9 workloads and how they were evaluated. How memory pressure was induced? Did you overcommit the memory? How many workloads were running concurrently? How was the performance isolation between the workloads? Is this speedup due to triggering oom-killer earlier under memory pressure or something else?
Quoted 7 lines
Overhead
--------We also measured the overhead of DAMON. It was not only under the upperbound we set, but was much lower (0.6 percent of the bound in best case, 13.288 percent of the bound in average).
Why the upperbound you set matters?
Quoted 5 lines
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 access check-based monitoring.
What is periodic access check-based monitoring?
Quoted 6 lines
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.
What about the number of processes? The alternative mechanism in [5,8] are whole machine monitoring. Thousands of processes run on a machine. How does this work monitoring thousands of processes compared to [5,8].
Using sampling the cost/overhead is configurable but I would like to know at what cost? Will the accuracy be good enough for the given use-case?
Quoted 273 lines
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 WeeklyNews (LWN), Feb 2020. https://lwn.net/Articles/812707/Sequence Of Patches
===================The patches are organized in the following sequence. The first patch introduces DAMON module, it's data structures, and data structure related common functions. Following three patches (2nd to 4th) implement the core logics of DAMON, namely regions based sampling, adaptive regions adjustment, and dynamic memory mapping chage adoption, one by one.
Following five patches are for low level users of DAMON. The 5th patch implements callbacks for each of monitoring steps so that users can do whatever they want with the access patterns. The 6th one implements recording of access patterns in DAMON for better convenience and efficiency. Each of next three patches (7th to 9th) respectively adds a programmable interface for other kernel code, 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 (10th) implements an user space tool. The 11th patch adds a document for administrators of DAMON.
Next two patches are for tests. The 12th and 13th patches provide unit tests (based on kunit) and user space tests (based on kselftest) respectively.
Finally, the last patch (14th) updates the
MAINTAINERSfile.The patches are based on the v5.5. You can also clone the complete git tree:
$ git clone git://github.com/sjp38/linux -b damon/patches/v6The web is also available:
https://github.com/sjp38/linux/releases/tag/damon/patches/v6Patch History
=============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 checkChanges 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)Reported-by kbuild test robot <[email protected]>- Fix m68k module build issue
Reported-by kbuild test robot <[email protected]>- Add selftests
- Seperate patches for low level users from core logics for better reading
- Clean up debugfs interface
- Trivial nitpicksChanges from v3
(https://lore.kernel.org/linux-mm/[email protected]/)
- Fix i386 build issueReported-by kbuild test robot <[email protected]>- Increase the default size of the monitoring result buffer to 1 MiB
- Fix misc bugs in debugfs interfaceChanges from v2
(https://lore.kernel.org/linux-mm/[email protected]/)
- MoveMAINTAINERSchanges 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 interfaceChanges 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)
- UpdatePG_Youngto 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 codeSeongJae Park (14):
mm: Introduce Data Access MONitor (DAMON) mm/damon: Implement region based sampling mm/damon: Adaptively adjust regions
mm/damon: Apply dynamic memory mapping changes mm/damon: Implement callbacks
mm/damon: Implement access pattern recording mm/damon: Implement kernel space API mm/damon: Add debugfs interface
mm/damon: Add a tracepoint for result writing
tools: Add a minimal user-space tool for DAMONDocumentation/admin-guide/mm: Add a document for DAMON mm/damon: Add kunit tests
mm/damon: Add user selftests
MAINTAINERS: Update for DAMON.../admin-guide/mm/data_access_monitor.rst | 414 +++++ Documentation/admin-guide/mm/index.rst | 1 + MAINTAINERS | 12 + include/linux/damon.h | 71 + include/trace/events/damon.h | 32 + mm/Kconfig | 23 + mm/Makefile | 1 + mm/damon-test.h | 604 +++++++ mm/damon.c | 1427 +++++++++++++++++ mm/page_ext.c | 1 + tools/damon/.gitignore | 1 + tools/damon/_dist.py | 36 + tools/damon/bin2txt.py | 64 + tools/damon/damo | 37 + tools/damon/heats.py | 358 +++++ tools/damon/nr_regions.py | 89 + tools/damon/record.py | 212 +++ tools/damon/report.py | 45 + tools/damon/wss.py | 95 ++ tools/testing/selftests/damon/Makefile | 7 + .../selftests/damon/_chk_dependency.sh | 28 + tools/testing/selftests/damon/_chk_record.py | 89 + .../testing/selftests/damon/debugfs_attrs.sh | 139 ++ .../testing/selftests/damon/debugfs_record.sh | 50 + 24 files changed, 3836 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/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--
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_Idleflags) 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.
Quoted 5 lines
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``.
Why is "aggregation interval" important? User space can just poll after such interval.
Quoted 22 lines
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.
Quoted 4 lines
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.
So, the spatial locality is assumed.
Quoted 10 lines
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
Oh aggregation interval is used for merging event.
Quoted 5 lines
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.
What's the equilibrium/stable state here?
Quoted 92 lines
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.
A Future Plan: Data Access Monitoring-based Operation Schemes
-------------------------------------------------------------As described in the above section, DAMON could be helpful for actual access based memory management optimizations. Nevertheless, users who want to do such optimizations should run DAMON, read the traced data (either online or offline), analyze it, plan a new memory management scheme, and apply the new scheme by themselves. It must be easier than the past, but could still require some level of efforts. In its next development stage, DAMON will reduce some of such efforts by allowing users to specify some access based memory management rules for their specific processes.
Because this is just a plan, the specific interface is not fixed yet, but for example, users will be allowed to write their desired memory management rules to a special file in a DAMON specific format. The rules will be something like 'if a memory region of size in a range is keeping a range of hotness for more than a duration, apply specific memory management rule using
madvise()ormlock()to the region'. For example, we can imagine rules like below:# format is: <min/max size> <min/max frequency (0-99)> <duration> <action># if a region of a size keeps a very high access frequency for more than # 100ms, lock the region in the main memory (call mlock()). But, if the # region is larger than 500 MiB, skip it. The exception might be helpful # if the system has only, say, 600 MiB of DRAM, a region of size larger # than 600 MiB cannot be locked in the DRAM at all. na 500M 90 99 100ms mlock# if a region keeps a high access frequency for more than 100ms, put the # region on the head of the LRU list (call madvise() with MADV_WILLNEED). na na 80 90 100ms madv_willneed# if a region keeps a low access frequency for more than 100ms, put the # region on the tail of the LRU list (call madvise() with MADV_COLD). na na 10 20 100ms madv_cold# if a region keeps a very low access frequency for more than 100ms, swap # out the region immediately (call madvise() with MADV_PAGEOUT). na na 0 10 100ms madv_pageout# if a region of a size bigger than 2MB keeps a very high access frequency # for more than 100ms, let the region to use huge pages (call madvise() # with MADV_HUGEPAGE). 2M na 90 99 100ms madv_hugepage
Quoted 7 lines
# If a regions of a size bigger than > 2MB keeps no high access frequency # for more than 100ms, avoid the region from using huge pages (call #
madvise()withMADV_NOHUGEPAGE).
2M na 0 25 100msmadv_nohugepageAn RFC patchset for this is available:
https://lore.kernel.org/linux-mm/[email protected]/
I do want to question the actual motivation of the design followed by this work.
With the already present Page Idle Tracking feature in the kernel, I can envision that the region sampling and adaptive region adjustments can be done in the user space. Due to sampling, the additional overhead will be very small and configurable.
Additionally the proposed mechanism has inherent assumption of the presence of spatial locality (for virtual memory) in the monitored processes which is very workload dependent.
Given that the the same mechanism can be implemented in the user space within tolerable overhead and is workload dependent, why it should be done in the kernel? What exactly is the advantage of implementing this in kernel?
thanks,
Shakeel
Quoted 13 lines · On Tue, 10 Mar 2020 10:21:34 -0700 Shakeel Butt <[email protected]> wrote:
Quoted 12 lines · SeongJae Park
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 improvement and rely on only coarse information or some light-weight heuristics. The pseudo-LRU and the aggressive THP promotions are such examples.
Quoted 3 lines
Quoted 1 line
A number of experimental data access pattern awared memory management
why experimental? [5,8] are deployed across Google fleet.
Yes, simply saying all as experimental was my mistake. Will change this sentence in the next spin.
Quoted 6 lines
Quoted 3 lines
optimizations (refer to 'Appendix A' for more details) say the sacrifices are huge.
It depends. For servers where stranded CPUs are common, the cost is not that huge.
What I wanted to say is that the potential performance benefit that can be earned by utilizing the data access pattern based optimizations such as proactive reclamation is large (sacrification from perspective of Linux, which is not optimized in that way). Will wordsmith this sentence in the next spin.
Quoted 4 lines
Quoted 2 lines
However, none of those has successfully adopted to Linux kernel mainly
adopted? I think you mean accepted or merged
You're right, will correct this.
Quoted 5 lines
Quoted 5 lines
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.
Quoted 7 lines
Quoted 5 lines
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)
94.242.42x ?
94,242.42x (almost 100 thousands). Sorry for confusion.
Quoted 13 lines
Quoted 13 lines
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.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.
[...]
Quoted 16 lines
Quoted 4 lines
Frequently Asked Questions
==========================Quoted 11 lines
Q: Why DAMON is not integrated with perf?
A: From the perspective of perf like profilers, DAMON can be thought of as a data source in kernel, like the tracepoints, the pressure stall information (psi), or the idle page tracking. Thus, it is easy to integrate DAMON with the profilers. 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 a debugfs interface based user space tool for DAMON. It can be used to record, visualize, and analyze data access patterns of target processes in a convenient way.
Quoted 1 line
Oh it is monitoring at the process level.
Yes, exactly.
Quoted 2 lines
Quoted 2 lines
[...]
Quoted 5 lines
Quoted 5 lines
Evaluations
===========
Quoted 8 lines
Quoted 6 lines
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].
The paper [2] is behind a paywall, upload it somewhere for free access.
It's a shame, sorry. But, isn't it illegal to upload it somwahere?
Quoted 10 lines
Quoted 10 lines
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.
Quoted 8 lines
Quoted 4 lines
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.
Did you change the applications to add
mlock()or was it done dynamically through some new interface? The hot memory / working set changes, so, dynamically m[un]locking makes sense.
We manually changed the application source code to add mlock()/munlock().
Quoted 10 lines
Quoted 4 lines
The optimized versions consistently show speedup (2.55x in best case, 1.65x in average) under memory pressure.
Do tell more about these 9 workloads and how they were evaluated. How memory pressure was induced? Did you overcommit the memory? How many workloads were running concurrently? How was the performance isolation between the workloads? Is this speedup due to triggering oom-killer earlier under memory pressure or something else?
The 9 workloads are 433.milc, 462.libquantum and 470.lbm from SPEC CPU 2006, cg, sp from NPB, and ferret, water_nsquared, fft, and volrend from PARSEC3 benchmark suites.
I isolated them and induced the memory pressure by running those one by one, in a cgroup providing memory space 30\% less than rheir orginal working set.
The speedup came from the reduced swap in events, due to the mlock() of hot objects.
Quoted 10 lines
Quoted 8 lines
Overhead
--------We also measured the overhead of DAMON. It was not only under the upperbound we set, but was much lower (0.6 percent of the bound in best case, 13.288 percent of the bound in average).
Why the upperbound you set matters?
I just wanted to show that the upperbound setting really works as intended.
Quoted 8 lines
Quoted 6 lines
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 access check-based monitoring.What is periodic access check-based monitoring?
It means periodically checking the 'Accessed bit' of each page of the target processes.
Quoted 4 lines
Quoted 4 lines
DAMON's overhead was smaller than it by 94,242.42x in best case, 3,159.61x in average.
Quoted 8 lines
Quoted 3 lines
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.
What about the number of processes? The alternative mechanism in [5,8] are whole machine monitoring. Thousands of processes run on a machine. How does this work monitoring thousands of processes compared to [5,8].
DAMON is designed to be able to monitor multiple processes, but the tests has done for each of the single process.
I am planning to extend DAMON to support entire physical memory in future, though.
Quoted 4 lines
Using sampling the cost/overhead is configurable but I would like to know at what cost? Will the accuracy be good enough for the given use-case?
The adaptive regions adjustment is for the point. To show the correctness, I showed the visualized patterns (seems reasonable) and the pattern based (manual and automated) optimizations (shows reasonable improvements).
Quoted 3 lines
Quoted 3 lines
[...]
Quoted 13 lines
Quoted 13 lines
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.
Quoted 8 lines
Quoted 5 lines
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``.
Why is "aggregation interval" important? User space can just poll after such interval.
You already got the answer below, but to add my explanation, it's necessary to be able to say 'how many times' the region has accessed for last 'specific duration'. Users can jut poll it of course, but doing this inside the kernel will reduce many number of kernel-user context changes.
Quoted 23 lines
Quoted 23 lines
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.
Quoted 6 lines
Quoted 4 lines
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.
So, the spatial locality is assumed.
Yes, exactly. The difinition of 'region' in DAMON is 'adjacent memory area showing similar access frequency'.
Quoted 5 lines
Quoted 5 lines
Adaptive Regions Adjustment
---------------------------
Quoted 8 lines
Quoted 6 lines
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
Oh aggregation interval is used for merging event.
Yes, right!
Quoted 8 lines
Quoted 6 lines
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.
What's the equilibrium/stable state here?
Currently, we merge two regions if the difference of 'number of accesses' of those is smaller than 10% of the highest number of accesses.
Quoted 15 lines
Quoted 15 lines
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``).
[...]
Quoted 8 lines
I do want to question the actual motivation of the design followed by this work.
With the already present Page Idle Tracking feature in the kernel, I can envision that the region sampling and adaptive region adjustments can be done in the user space. Due to sampling, the additional overhead will be very small and configurable.
Quoted 8 lines
Additionally the proposed mechanism has inherent assumption of the presence of spatial locality (for virtual memory) in the monitored processes which is very workload dependent.
Given that the the same mechanism can be implemented in the user space within tolerable overhead and is workload dependent, why it should be done in the kernel? What exactly is the advantage of implementing this in kernel?
First of all, DAMON is not for only user space processes, but also for kernel space core mechanisms. Many of the core mechanisms will be able to use DAMON for access pattern based optimizations, with light overhead and reasonable accuracy.
Implementing DAMON in user space is of course possible, but it will be inefficient. Using it from kernel space would make no sense, and it would incur unnecessarily frequent kernel-user context switches, which is very expensive nowadays.
Thanks,
SeongJae Park
Quoted 3 lines
thanks,
Shakeel
Quoted 9 lines · On Thu, 12 Mar 2020 11:07:59 +0100 SeongJae Park <[email protected]> wrote:
Quoted 7 lines · On Tue, 10 Mar 2020 10:21:34 -0700 Shakeel Butt <[email protected]> wrote:
Quoted 6 lines · SeongJae Park
From: SeongJae Park <[email protected]>
Introduction
============
[...]
Quoted 22 lines
Quoted 8 lines
I do want to question the actual motivation of the design followed by this work.
With the already present Page Idle Tracking feature in the kernel, I can envision that the region sampling and adaptive region adjustments can be done in the user space. Due to sampling, the additional overhead will be very small and configurable.
Quoted 8 lines
Additionally the proposed mechanism has inherent assumption of the presence of spatial locality (for virtual memory) in the monitored processes which is very workload dependent.
Given that the the same mechanism can be implemented in the user space within tolerable overhead and is workload dependent, why it should be done in the kernel? What exactly is the advantage of implementing this in kernel?
First of all, DAMON is not for only user space processes, but also for kernel space core mechanisms. Many of the core mechanisms will be able to use DAMON for access pattern based optimizations, with light overhead and reasonable accuracy.
Quoted 4 lines
Implementing DAMON in user space is of course possible, but it will be inefficient. Using it from kernel space would make no sense, and it would incur unnecessarily frequent kernel-user context switches, which is very expensive nowadays.
Forgot mentioning about the spatial locality. Yes, it is workload dependant, but still pervasive in many case. Also, many core mechanisms in kernel such as read-ahead or LRU are already using some similar assumptions.
If it is so problematic, you could set the maximum number of regions to the number of pages in the system so that each region monitors each page.
Thanks,
SeongJae Park
Quoted 10 lines
Thanks,
SeongJae ParkQuoted 3 lines
thanks,
Shakeel
Quoted 30 lines · SeongJae Park
Quoted 9 lines · On Thu, 12 Mar 2020 11:07:59 +0100 SeongJae Park <[email protected]> wrote:
Quoted 7 lines · On Tue, 10 Mar 2020 10:21:34 -0700 Shakeel Butt <[email protected]> wrote:
Quoted 6 lines · SeongJae Park
From: SeongJae Park <[email protected]>
Introduction
============[...]
Quoted 17 lines
Quoted 16 lines
I do want to question the actual motivation of the design followed by this work.
With the already present Page Idle Tracking feature in the kernel, I can envision that the region sampling and adaptive region adjustments can be done in the user space. Due to sampling, the additional overhead will be very small and configurable.
Additionally the proposed mechanism has inherent assumption of the presence of spatial locality (for virtual memory) in the monitored processes which is very workload dependent.
Given that the the same mechanism can be implemented in the user space within tolerable overhead and is workload dependent, why it should be done in the kernel? What exactly is the advantage of implementing this in kernel?
Quoted 4 lines
Quoted 4 lines
First of all, DAMON is not for only user space processes, but also for kernel space core mechanisms. Many of the core mechanisms will be able to use DAMON for access pattern based optimizations, with light overhead and reasonable accuracy.
Which kernel space core mechanisms? I can see memory reclaim, do you envision some other component as well.
Let's discuss how this can interact with memory reclaim and we can see if there is any benefit to do this in kernel.
Quoted 10 lines
Quoted 5 lines
Implementing DAMON in user space is of course possible, but it will be inefficient. Using it from kernel space would make no sense, and it would incur unnecessarily frequent kernel-user context switches, which is very expensive nowadays.
Forgot mentioning about the spatial locality. Yes, it is workload dependant, but still pervasive in many case. Also, many core mechanisms in kernel such as read-ahead or LRU are already using some similar assumptions.
Not sure about the LRU but yes read-ahead in several places does assume spatial locality. However most of those are configurable and the userspace can enable/disable the read-ahead based on the workload.
Quoted 4 lines
If it is so problematic, you could set the maximum number of regions to the number of pages in the system so that each region monitors each page.
How will this work in the process context? Number of regions equal to the number of mapped pages?
Basically I am trying to envision the comparison of physical memory based monitoring (using idle page tracking) vs pid+VA based monitoring.
Anyways I am not against your proposal. I am trying to see how to make it more general to be applicable to more use-cases and one such use-case which I am interested in is monitoring all the user pages on the system for proactive reclaim purpose.
Shakeel
Quoted 31 lines · On Wed, 18 Mar 2020 12:52:48 -0700 Shakeel Butt <[email protected]> wrote:
Quoted 30 lines · SeongJae Park
Quoted 9 lines · On Thu, 12 Mar 2020 11:07:59 +0100 SeongJae Park <[email protected]> wrote:
Quoted 7 lines · On Tue, 10 Mar 2020 10:21:34 -0700 Shakeel Butt <[email protected]> wrote:
Quoted 6 lines · SeongJae Park
From: SeongJae Park <[email protected]>
Introduction
============[...]
Quoted 17 lines
Quoted 16 lines
I do want to question the actual motivation of the design followed by this work.
With the already present Page Idle Tracking feature in the kernel, I can envision that the region sampling and adaptive region adjustments can be done in the user space. Due to sampling, the additional overhead will be very small and configurable.
Additionally the proposed mechanism has inherent assumption of the presence of spatial locality (for virtual memory) in the monitored processes which is very workload dependent.
Given that the the same mechanism can be implemented in the user space within tolerable overhead and is workload dependent, why it should be done in the kernel? What exactly is the advantage of implementing this in kernel?
Quoted 7 lines
Quoted 4 lines
Quoted 4 lines
First of all, DAMON is not for only user space processes, but also for kernel space core mechanisms. Many of the core mechanisms will be able to use DAMON for access pattern based optimizations, with light overhead and reasonable accuracy.
Which kernel space core mechanisms? I can see memory reclaim, do you envision some other component as well.
In addition to reclmation, I am thinking THP promotion/demotion decision, page migration among NUMA nodes on tier-memory configuration, and on-demand virtual machine live migration mechanisms could benefit from DAMON, for now. I also believe more use-cases could be found.
Quoted 3 lines
Let's discuss how this can interact with memory reclaim and we can see if there is any benefit to do this in kernel.
For reclaim, I believe we could try the proactive reclamation again using DAMON (Yes, I'm a fan of the idea of proactive reclamation). I already implemented and evaluated a simple form of DAMON-based proactive reclamation for the proof of the concept (not for production). In best case (parsec3/freqmine), it reduces 22.42% of system memory usage and 88.86% of residential sets while incurring only 3.07% runtime overhead. Please refer to 'Appendix E' of the v7 patchset[1] of DAMON. It also describes the implementation and the evaluation of a data access monitoring-based THP promotion/demotion policy.
The experimental implementation cannot be directly applied to kernel reclamation mechanism, because it requires users to specify the target applications. Nonetheless, I think we can also easily adopt it inside the kernel by modifying kswapd to periodically select processes having huge RSS as targets, or by creating proactive reclamation type cgroups which selects every processes in the cgroup as targets.
Of course, we can extend DAMON to support physical memory address space instead of virtual memory of specific processes. Actually, this is in our TODO list. With the extension, applying DAMON to core memory management mechanisms will be even easier.
Nonetheless, this is only example but not concrete plan. I didn't make the concrete plan yet, but believe that of DAMON will open the gates.
[1] https://lore.kernel.org/linux-mm/[email protected]/
Quoted 7 lines
Quoted 7 lines
Quoted 6 lines
Implementing DAMON in user space is of course possible, but it will be inefficient. Using it from kernel space would make no sense, and it would incur unnecessarily frequent kernel-user context switches, which is very expensive nowadays.
Quoted 8 lines
Quoted 4 lines
Forgot mentioning about the spatial locality. Yes, it is workload dependant, but still pervasive in many case. Also, many core mechanisms in kernel such as read-ahead or LRU are already using some similar assumptions.
Not sure about the LRU but yes read-ahead in several places does assume spatial locality. However most of those are configurable and the userspace can enable/disable the read-ahead based on the workload.
Sorry for my ambiguous description. LRU uses temporal locality, which is somewhat similar to spatial locality, in terms of workload dependency.
Quoted 8 lines
Quoted 5 lines
If it is so problematic, you could set the maximum number of regions to the number of pages in the system so that each region monitors each page.
How will this work in the process context? Number of regions equal to the number of mapped pages?
Suppose that a process has 1024 pages of working set and each of the pages has totally different access frequency. If the maximum number of regions is 1024, the adaptive regions adjustment mechanism of DAMON will create each region for each page and monitor the access to each page. So, the output will be same to straightforward periodic page-granularity access checking methods, which does not depend on the spatial locality. Nevertheless, the monitoring overhead will be also similar to that.
However, if any adjacent pages have similar access frequencies, DAMON will group those pages into one region. This will reduce the total number of PTE Accessed bit checks and thus decrease the overhead. In other words, DAMON do its best effort to minimize the overhead while preserving quality.
Also suppose that the maximum number of region is smaller than 1024 in this case. Pages having different access frequency will be grouped in same region and thus the output quality will be decreased. However, the overhead will be half, as DAMON does one access check per each region. This means that you can easily trade the monitoring quality with overhead by adjusting the maximum number of regions.
Quoted 4 lines
Basically I am trying to envision the comparison of physical memory based monitoring (using idle page tracking) vs pid+VA based monitoring.
I believe the core mechanisms of DAMON could be easily extended to the physical memory. Indeed, it is in our TODO list, and I believe it would make use of DAMON in kernel core mechanisms much easier.
Quoted 5 lines
Anyways I am not against your proposal. I am trying to see how to make it more general to be applicable to more use-cases and one such use-case which I am interested in is monitoring all the user pages on the system for proactive reclaim purpose.
Your questions gave me many insight and shed lights to the way DAMON should go. Really appreciate. If you have any more questions or need my help, please let me know.
Thanks,
SeongJae Park
Quoted 3 lines
Shakeel
Quoted 39 lines · SeongJae Park
Quoted 36 lines · On Wed, 18 Mar 2020 12:52:48 -0700 Shakeel Butt <[email protected]> wrote:
Quoted 34 lines · SeongJae Park
Quoted 9 lines · On Thu, 12 Mar 2020 11:07:59 +0100 SeongJae Park <[email protected]> wrote:
Quoted 7 lines · On Tue, 10 Mar 2020 10:21:34 -0700 Shakeel Butt <[email protected]> wrote:
Quoted 6 lines · SeongJae Park
From: SeongJae Park <[email protected]>
Introduction
============[...]
Quoted 21 lines
Quoted 8 lines
I do want to question the actual motivation of the design followed by this work.
With the already present Page Idle Tracking feature in the kernel, I can envision that the region sampling and adaptive region adjustments can be done in the user space. Due to sampling, the additional overhead will be very small and configurable.
Quoted 8 lines
Additionally the proposed mechanism has inherent assumption of the presence of spatial locality (for virtual memory) in the monitored processes which is very workload dependent.
Given that the the same mechanism can be implemented in the user space within tolerable overhead and is workload dependent, why it should be done in the kernel? What exactly is the advantage of implementing this in kernel?
First of all, DAMON is not for only user space processes, but also for kernel space core mechanisms. Many of the core mechanisms will be able to use DAMON for access pattern based optimizations, with light overhead and reasonable accuracy.
Quoted 8 lines
Quoted 2 lines
Which kernel space core mechanisms? I can see memory reclaim, do you envision some other component as well.
In addition to reclmation, I am thinking THP promotion/demotion decision, page migration among NUMA nodes on tier-memory configuration, and on-demand virtual machine live migration mechanisms could benefit from DAMON, for now. I also believe more use-cases could be found.
I am still struggling to see how these use-cases require in-kernel DAMON. For THP promotion/demotaion, madvise(MADV_[NO]HUGEPAGE) can be used or we can introduce a new MADV_HUGIFY to synchronously convert small pages to hugepages. Page migration on tier-memory is similar to proactive reclaim and we already have migrate_pages/move_pages syscalls. Basically why userspace DAMON can not perform these operations?
Quoted 13 lines
Quoted 3 lines
Let's discuss how this can interact with memory reclaim and we can see if there is any benefit to do this in kernel.
For reclaim, I believe we could try the proactive reclamation again using DAMON (Yes, I'm a fan of the idea of proactive reclamation). I already implemented and evaluated a simple form of DAMON-based proactive reclamation for the proof of the concept (not for production). In best case (parsec3/freqmine), it reduces 22.42% of system memory usage and 88.86% of residential sets while incurring only 3.07% runtime overhead. Please refer to 'Appendix E' of the v7 patchset[1] of DAMON. It also describes the implementation and the evaluation of a data access monitoring-based THP promotion/demotion policy.
Quoted 6 lines
The experimental implementation cannot be directly applied to kernel reclamation mechanism, because it requires users to specify the target applications. Nonetheless, I think we can also easily adopt it inside the kernel by modifying kswapd to periodically select processes having huge RSS as targets, or by creating proactive reclamation type cgroups which selects every processes in the cgroup as targets.
Again I feel like these should be done in user space as these are more policies instead of mechanisms. However if it can be shown that doing that in userspace is very expensive as compared to in-kernel solution then we can think about it.
Quoted 5 lines
Of course, we can extend DAMON to support physical memory address space instead of virtual memory of specific processes. Actually, this is in our TODO list. With the extension, applying DAMON to core memory management mechanisms will be even easier.
See below on physical memory monitoring.
Quoted 47 lines
Nonetheless, this is only example but not concrete plan. I didn't make the concrete plan yet, but believe that of DAMON will open the gates.
[1] https://lore.kernel.org/linux-mm/[email protected]/
Quoted 7 lines
Quoted 7 lines
Quoted 6 lines
Implementing DAMON in user space is of course possible, but it will be inefficient. Using it from kernel space would make no sense, and it would incur unnecessarily frequent kernel-user context switches, which is very expensive nowadays.
Quoted 8 lines
Quoted 4 lines
Forgot mentioning about the spatial locality. Yes, it is workload dependant, but still pervasive in many case. Also, many core mechanisms in kernel such as read-ahead or LRU are already using some similar assumptions.
Not sure about the LRU but yes read-ahead in several places does assume spatial locality. However most of those are configurable and the userspace can enable/disable the read-ahead based on the workload.
Sorry for my ambiguous description. LRU uses temporal locality, which is somewhat similar to spatial locality, in terms of workload dependency.
Quoted 8 lines
Quoted 5 lines
If it is so problematic, you could set the maximum number of regions to the number of pages in the system so that each region monitors each page.
How will this work in the process context? Number of regions equal to the number of mapped pages?
Suppose that a process has 1024 pages of working set and each of the pages has totally different access frequency. If the maximum number of regions is 1024, the adaptive regions adjustment mechanism of DAMON will create each region for each page and monitor the access to each page. So, the output will be same to straightforward periodic page-granularity access checking methods, which does not depend on the spatial locality. Nevertheless, the monitoring overhead will be also similar to that.
However, if any adjacent pages have similar access frequencies, DAMON will group those pages into one region. This will reduce the total number of PTE Accessed bit checks and thus decrease the overhead. In other words, DAMON do its best effort to minimize the overhead while preserving quality.
Quoted 7 lines
Also suppose that the maximum number of region is smaller than 1024 in this case. Pages having different access frequency will be grouped in same region and thus the output quality will be decreased. However, the overhead will be half, as DAMON does one access check per each region. This means that you can easily trade the monitoring quality with overhead by adjusting the maximum number of regions.
So, users can select to not merge the regions to keep the monitoring quality high, right?
Quoted 9 lines
Quoted 4 lines
Basically I am trying to envision the comparison of physical memory based monitoring (using idle page tracking) vs pid+VA based monitoring.
I believe the core mechanisms of DAMON could be easily extended to the physical memory. Indeed, it is in our TODO list, and I believe it would make use of DAMON in kernel core mechanisms much easier.
How will the sampling and regions representation/resizing work in physical memory?
Quoted 11 lines
Quoted 5 lines
Anyways I am not against your proposal. I am trying to see how to make it more general to be applicable to more use-cases and one such use-case which I am interested in is monitoring all the user pages on the system for proactive reclaim purpose.
Your questions gave me many insight and shed lights to the way DAMON should go. Really appreciate. If you have any more questions or need my help, please let me know.
Shakeel
Quoted 49 lines · On Mon, 23 Mar 2020 10:29:24 -0700 Shakeel Butt <[email protected]> wrote:
Quoted 39 lines · SeongJae Park
Quoted 36 lines · On Wed, 18 Mar 2020 12:52:48 -0700 Shakeel Butt <[email protected]> wrote:
Quoted 34 lines · SeongJae Park
Quoted 9 lines · On Thu, 12 Mar 2020 11:07:59 +0100 SeongJae Park <[email protected]> wrote:
Quoted 7 lines · On Tue, 10 Mar 2020 10:21:34 -0700 Shakeel Butt <[email protected]> wrote:
Quoted 6 lines · SeongJae Park
From: SeongJae Park <[email protected]>
Introduction
============[...]
Quoted 21 lines
Quoted 8 lines
I do want to question the actual motivation of the design followed by this work.
With the already present Page Idle Tracking feature in the kernel, I can envision that the region sampling and adaptive region adjustments can be done in the user space. Due to sampling, the additional overhead will be very small and configurable.
Quoted 8 lines
Additionally the proposed mechanism has inherent assumption of the presence of spatial locality (for virtual memory) in the monitored processes which is very workload dependent.
Given that the the same mechanism can be implemented in the user space within tolerable overhead and is workload dependent, why it should be done in the kernel? What exactly is the advantage of implementing this in kernel?
First of all, DAMON is not for only user space processes, but also for kernel space core mechanisms. Many of the core mechanisms will be able to use DAMON for access pattern based optimizations, with light overhead and reasonable accuracy.
Quoted 8 lines
Quoted 2 lines
Which kernel space core mechanisms? I can see memory reclaim, do you envision some other component as well.
In addition to reclmation, I am thinking THP promotion/demotion decision, page migration among NUMA nodes on tier-memory configuration, and on-demand virtual machine live migration mechanisms could benefit from DAMON, for now. I also believe more use-cases could be found.
Quoted 7 lines
I am still struggling to see how these use-cases require in-kernel DAMON. For THP promotion/demotaion,
madvise(MADV_[NO]HUGEPAGE)can be used or we can introduce a newMADV_HUGIFYto synchronously convert small pages to hugepages. Page migration on tier-memory is similar to proactive reclaim and we already have migrate_pages/move_pages syscalls. Basically why userspace DAMON can not perform these operations?
You are understanding it right, the most cases could be implemented in user space, either. My point is that DAMON in kernel space could give _better_ experiences to users.
First, implementing DAMON and DAMON-based optimiztions in kernel makes more people get the benefits without additional efforts. I think this is important because the benefits are often under-estimated while the required additional efforts are over-estimated by many application developers who doesn't concern about the system resources. Thus, implementing DAMON in userspace could limit the benefits to only early-adopters and leave many applications to not get benefit from it. For this, I would like to quote Jonathan, from his LWN article[1] introducing DAMON:
But one might well argue that production systems should Just Work without the need for this sort of manual tweaking, even if the tweaking is supported by a capable monitoring system. While DAMON looks like a useful tool now, users may be forgiven for hoping that it makes itself obsolete over time.
Second, the overhead comes from the user-kernel context changes. For an example, suppose that DAMON is implemented in user space and there are 100 regions. If you want to know only whether the regions are accessed or not, only 1 access check per each region is required and thus only 100 context changes. However, if you want to know the access frequency of each region in a fine-grained score, say, ranges from 0 to 100. In this case, the number of required context changes becomes 100x. Further, suppose that you want to know only regions consitently keeping a range of the access frequency score (e.g., 80-100 or 0-20) for several minutes. The context changes becomes much more frequent. Contrarily, if we implement DAMON and DAMON-based operations in the kernel, no context change is required. Even if the DAMON-based operations are implemented in user space, only one context change.
[1] https://lwn.net/Articles/812707/
Quoted 21 lines
Quoted 14 lines
Quoted 4 lines
Let's discuss how this can interact with memory reclaim and we can see if there is any benefit to do this in kernel.
For reclaim, I believe we could try the proactive reclamation again using DAMON (Yes, I'm a fan of the idea of proactive reclamation). I already implemented and evaluated a simple form of DAMON-based proactive reclamation for the proof of the concept (not for production). In best case (parsec3/freqmine), it reduces 22.42% of system memory usage and 88.86% of residential sets while incurring only 3.07% runtime overhead. Please refer to 'Appendix E' of the v7 patchset[1] of DAMON. It also describes the implementation and the evaluation of a data access monitoring-based THP promotion/demotion policy.
Quoted 6 lines
The experimental implementation cannot be directly applied to kernel reclamation mechanism, because it requires users to specify the target applications. Nonetheless, I think we can also easily adopt it inside the kernel by modifying kswapd to periodically select processes having huge RSS as targets, or by creating proactive reclamation type cgroups which selects every processes in the cgroup as targets.
Quoted 4 lines
Again I feel like these should be done in user space as these are more policies instead of mechanisms. However if it can be shown that doing that in userspace is very expensive as compared to in-kernel solution then we can think about it.
I think my above answers answer these. Implementing it in kernel space will make more users to get benefit, and a part of the overhead, which comes from the context changes, could be estimated.
Quoted 64 lines
Quoted 6 lines
Of course, we can extend DAMON to support physical memory address space instead of virtual memory of specific processes. Actually, this is in our TODO list. With the extension, applying DAMON to core memory management mechanisms will be even easier.
See below on physical memory monitoring.
Quoted 47 lines
Nonetheless, this is only example but not concrete plan. I didn't make the concrete plan yet, but believe that of DAMON will open the gates.
[1] https://lore.kernel.org/linux-mm/[email protected]/
Quoted 7 lines
Quoted 7 lines
Quoted 6 lines
Implementing DAMON in user space is of course possible, but it will be inefficient. Using it from kernel space would make no sense, and it would incur unnecessarily frequent kernel-user context switches, which is very expensive nowadays.
Quoted 8 lines
Quoted 4 lines
Forgot mentioning about the spatial locality. Yes, it is workload dependant, but still pervasive in many case. Also, many core mechanisms in kernel such as read-ahead or LRU are already using some similar assumptions.
Not sure about the LRU but yes read-ahead in several places does assume spatial locality. However most of those are configurable and the userspace can enable/disable the read-ahead based on the workload.
Sorry for my ambiguous description. LRU uses temporal locality, which is somewhat similar to spatial locality, in terms of workload dependency.
Quoted 8 lines
Quoted 5 lines
If it is so problematic, you could set the maximum number of regions to the number of pages in the system so that each region monitors each page.
How will this work in the process context? Number of regions equal to the number of mapped pages?
Suppose that a process has 1024 pages of working set and each of the pages has totally different access frequency. If the maximum number of regions is 1024, the adaptive regions adjustment mechanism of DAMON will create each region for each page and monitor the access to each page. So, the output will be same to straightforward periodic page-granularity access checking methods, which does not depend on the spatial locality. Nevertheless, the monitoring overhead will be also similar to that.
However, if any adjacent pages have similar access frequencies, DAMON will group those pages into one region. This will reduce the total number of PTE Accessed bit checks and thus decrease the overhead. In other words, DAMON do its best effort to minimize the overhead while preserving quality.
Quoted 7 lines
Also suppose that the maximum number of region is smaller than 1024 in this case. Pages having different access frequency will be grouped in same region and thus the output quality will be decreased. However, the overhead will be half, as DAMON does one access check per each region. This means that you can easily trade the monitoring quality with overhead by adjusting the maximum number of regions.
Quoted 2 lines
So, users can select to not merge the regions to keep the monitoring quality high, right?
No, DAMON provides no such option for now, though we could very easily add such option in future if required. Nonetheless, setting the maximum number of regions high enough avoids quality degradation caused by unnecessary merges.
Quoted 6 lines
Quoted 6 lines
Quoted 5 lines
Basically I am trying to envision the comparison of physical memory based monitoring (using idle page tracking) vs pid+VA based monitoring.
Quoted 7 lines
Quoted 4 lines
I believe the core mechanisms of DAMON could be easily extended to the physical memory. Indeed, it is in our TODO list, and I believe it would make use of DAMON in kernel core mechanisms much easier.
How will the sampling and regions representation/resizing work in physical memory?
Please note that below are a vague, might errorneous idea. I made no concrete plan for it yet, because I'm currently focusing for merge of virtual memory supporting version DAMON.
For sampling, reuse PAGE_IDLE. In some architectures, we could extend to use architecture-specific access monitoring features, but using PAGE_IDLE might be enough for the first step.
For regions representation, simply use the physical addresses instead of virtual addresses. Someone could ask whether physical address space has enough spatial locality. I believe so as long as some of the memory management subsystems related to compaction and NUMA balancing works well. Further, DAMON-based optimizations for those subsystems and DAMON itself might be possible.
Again, appreciate your questions. I also learn and remind many things by answering to you. :) If my answer is insufficient or you have any further comments, please feel free to let me know.
Thanks,
SeongJae Park
Quoted 15 lines
Quoted 12 lines
Quoted 6 lines
Anyways I am not against your proposal. I am trying to see how to make it more general to be applicable to more use-cases and one such use-case which I am interested in is monitoring all the user pages on the system for proactive reclaim purpose.
Your questions gave me many insight and shed lights to the way DAMON should go. Really appreciate. If you have any more questions or need my help, please let me know.
Shakeel