Skip to contentSkip to conversation

Introduce Data Access MONitor (DAMON)

PATCH Superseded SeongJae Park 4 participants 51 messages Feb 24, 2020 – Mar 24, 2020

Subsystems (8)

v6 of 24 Superseded Latest is v24 →

lore
Share & tools
lore
#0 lore raw

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]/
#1 lore raw

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
index ab80933be65f..387d469f40ec 100644
@@ -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
index 1937cc251883..2911b3832c90 100644
@@ -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
#2 lore raw

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.

---
 mm/Kconfig  |  12 +++
 mm/Makefile |   1 +
 mm/damon.c  | 224 ++++++++++++++++++++++++++++++++++++++++++++++++++++
 3 files changed, 237 insertions(+)
 create mode 100644 mm/damon.c
mm/Kconfig +0 -0
index ab80933be65f..387d469f40ec 100644

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.
+
 endmenu
mm/Makefile +1 -0
index 1937cc251883..2911b3832c90 100644
@@ -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 +61 -0
new file mode 100644
index 000000000000..aafdca35b7b8
@@ -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");
#3 lore raw

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 n

No 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 a damon_region struct
+ *
+ * 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.h comments for __list_add call this
function "insert". No idea why it isn't simply called that..

Quoted 2 lines

Perhaps damon_insert_region would 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");
#4 lore raw

PATCH v6 2/14 mm/damon: Implement region based sampling

In reply to SeongJae Park

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.

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
index aafdca35b7b8..6bdeb84d89af 100644
@@ -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
index 4ade843ff588..71169b45bba9 100644
@@ -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
#5 lore raw

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.

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
index aafdca35b7b8..6bdeb84d89af 100644
@@ -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
index 4ade843ff588..71169b45bba9 100644
@@ -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)
 {
#6 lore raw

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_stop infrastructure 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
index aafdca35b7b8..6bdeb84d89af 100644
@@ -9,9 +9,14 @@
 

[...]

Quoted 6 lines
Quoted 4 lines

+/*
+ * Get the mm_struct of the given task
+ *
+ * Callser should put the mm_struct after use, unless it is NULL.

Caller

Good eye! Will fix it.

Quoted 43 lines
Quoted 43 lines

+ *
+ * Returns the mm_struct of 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 unmapped

actually

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 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.

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_stop approach?

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 then

		if (!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_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.
+ */

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
index 4ade843ff588..71169b45bba9 100644
@@ -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)
 {
#7 lore raw

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 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.

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);
+}
+
#8 lore raw

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 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.

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) ~= 1

Should 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);
+}
+
#9 lore raw

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 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.

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) ~= 1

Should 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 Park

Quoted 7 lines
Quoted 5 lines
Quoted 5 lines
Quoted 5 lines
mm/damon.c +5 -0
+#endif
+
+	spin_unlock(ptl);
+}
+  
#10 lore raw

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 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.

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) ~= 1

Should 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 Park

Quoted 7 lines
Quoted 5 lines
Quoted 5 lines
Quoted 5 lines
mm/damon.c +5 -0
+#endif
+
+	spin_unlock(ptl);
+}
+  
#11 lore raw

Re: [PATCH v6 02/14] mm/damon: Implement region based sampling

In reply to SeongJae Park
Quoted 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.

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
index aafdca35b7b8..6bdeb84d89af 100644
@@ -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
index 4ade843ff588..71169b45bba9 100644
@@ -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)
 {
#12 lore raw

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_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 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

#13 lore raw

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_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 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

#14 lore raw

PATCH v6 3/14 mm/damon: Adaptively adjust regions

In reply to SeongJae Park

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.

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
index 6bdeb84d89af..1c8bb71bbce9 100644
@@ -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
#15 lore raw

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.

Really minor comments inline.

Quoted 58 lines
---
 mm/damon.c | 151 ++++++++++++++++++++++++++++++++++++++++++++++++++---
 1 file changed, 144 insertions(+), 7 deletions(-)
mm/damon.c +29 -3
index 6bdeb84d89af..1c8bb71bbce9 100644
@@ -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;
 }
 
#16 lore raw

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.

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
index 6bdeb84d89af..1c8bb71bbce9 100644

[...]

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 -1
 	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;

max_nr_accesses = max(r->nr_accesses, max_nr_accesses)

Good point!

Thanks,
SeongJae Park

[...]

#17 lore raw

PATCH v6 4/14 mm/damon: Apply dynamic memory mapping changes

In reply to SeongJae Park

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``).

---
 mm/damon.c | 99 +++++++++++++++++++++++++++++++++++++++++++++++++++---
 1 file changed, 95 insertions(+), 4 deletions(-)
mm/damon.c +95 -4
index 1c8bb71bbce9..6a17408e83c2 100644
@@ -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
#18 lore raw

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``).

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
index 1c8bb71bbce9..6a17408e83c2 100644
@@ -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;
#19 lore raw

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``).

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 :)

[...]

#20 lore raw

PATCH v6 5/14 mm/damon: Implement callbacks

In reply to SeongJae Park

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 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
index 6a17408e83c2..554720778e8a 100644
@@ -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
#21 lore raw

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.

---
 mm/damon.c | 8 ++++++++
 1 file changed, 8 insertions(+)
mm/damon.c +8 -0
index 6a17408e83c2..554720778e8a 100644
@@ -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);
 		}
#22 lore raw

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

[...]

#23 lore raw

PATCH v6 6/14 mm/damon: Implement access pattern recording

In reply to SeongJae Park

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.

---
 mm/damon.c | 126 +++++++++++++++++++++++++++++++++++++++++++++++++++--
 1 file changed, 123 insertions(+), 3 deletions(-)
mm/damon.c +123 -3
index 554720778e8a..a7edb2dfa700 100644
@@ -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
#24 lore raw

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.

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
index 554720778e8a..a7edb2dfa700 100644
@@ -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
  *
#25 lore raw

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

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

---

[...]

#26 lore raw

PATCH v6 7/14 mm/damon: Implement kernel space API

In reply to SeongJae Park

From: 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
new file mode 100644
index 000000000000..78785cb88d42
@@ -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
#27 lore raw

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() and damon_stop() with their own 'struct damon_ctx'.

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.h
include/linux/damon.h new file +71 -0
new file mode 100644
index 000000000000..78785cb88d42
@@ -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
index a7edb2dfa700..b3e9b9da5720 100644
@@ -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)
 {
#28 lore raw

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() and damon_stop() with their own 'struct damon_ctx'.

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

---

[...]

#29 lore raw

PATCH v6 8/14 mm/damon: Add debugfs interface

In reply to SeongJae Park

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 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.

---
 mm/damon.c | 377 ++++++++++++++++++++++++++++++++++++++++++++++++++++-
 1 file changed, 376 insertions(+), 1 deletion(-)
mm/damon.c +376 -1
index b3e9b9da5720..facb1d7f121b 100644
@@ -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
#30 lore raw

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 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
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.

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
index b3e9b9da5720..facb1d7f121b 100644
@@ -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");
 }
 
#31 lore raw

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

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
index b3e9b9da5720..facb1d7f121b 100644
@@ -10,6 +10,7 @@

[...]

Quoted 5 lines
Quoted 3 lines

+/*
+ * debugfs functions

Seems 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_err and spin_unlock in 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_init feels 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 __exit damon_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");
 }
#32 lore raw

PATCH v6 9/14 mm/damon: Add a tracepoint for result writing

In reply to SeongJae Park

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.

---
 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
new file mode 100644
index 000000000000..fb33993620ce
@@ -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
index facb1d7f121b..8faf3879f99e 100644
@@ -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
#33 lore raw

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.

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.h
include/trace/events/damon.h new file +32 -0
new file mode 100644
index 000000000000..fb33993620ce
@@ -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
index facb1d7f121b..8faf3879f99e 100644
@@ -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)
#34 lore raw

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

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.h
include/trace/events/damon.h new file +32 -0
new file mode 100644
index 000000000000..fb33993620ce
@@ -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
index facb1d7f121b..8faf3879f99e 100644
@@ -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)
#35 lore raw

PATCH v6 10/14 tools: Add a minimal user-space tool for DAMON

In reply to SeongJae Park

From: 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
new file mode 100644
index 000000000000..96403d36ff93
@@ -0,0 +1 @@
+__pycache__/*
tools/damon/_dist.py new file +36 -0
new file mode 100644
index 000000000000..9851ec964e5c
@@ -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
new file mode 100755
index 000000000000..58e1099ae5fc
@@ -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
#36 lore raw

PATCH v6 11/14 Documentation/admin-guide/mm: Add a document for DAMON

In reply to SeongJae Park

From: 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
new file mode 100644
index 000000000000..4d836c3866e2
@@ -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
index 11db46448354..d3d0ba373eb6 100644
@@ -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
#37 lore raw

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
---
 .../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 +3 -0
new file mode 100644
index 000000000000..4d836c3866e2
@@ -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
index 11db46448354..d3d0ba373eb6 100644
@@ -27,6 +27,7 @@ the Linux memory management.
 
    concepts
    cma_debugfs
+   data_access_monitor
    hugetlbpage
    idle_page_tracking
    ksm
#38 lore raw

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
---
 .../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 +7 -0
new file mode 100644
index 000000000000..4d836c3866e2
@@ -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 > 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.

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" > pids

write 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 -EBUSY would be more informative? Implies values might be fine, but the issue is 'not now'.

Agreed, will change so!

Thanks,
SeongJae Park

[...]

#39 lore raw

PATCH v6 12/14 mm/damon: Add kunit tests

In reply to SeongJae Park

From: 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
index 387d469f40ec..1a745ce0cbcb 100644
@@ -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
index 8faf3879f99e..ff150ae7532a 100644
@@ -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
#40 lore raw

PATCH v6 13/14 mm/damon: Add user selftests

In reply to SeongJae Park

From: 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
new file mode 100644
index 000000000000..cfd5393a4639
@@ -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
new file mode 100644
index 000000000000..814dcadd5e96
@@ -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
#41 lore raw

PATCH v6 14/14 MAINTAINERS: Update for DAMON

In reply to SeongJae Park

From: SeongJae Park <[email protected]>

This commit updates MAINTAINERS file for DAMON related files.

---
 MAINTAINERS | 12 ++++++++++++
 1 file changed, 12 insertions(+)
MAINTAINERS +12 -0
index 56765f542244..422c86f64cdd 100644
@@ -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
#42 lore raw
In reply to SeongJae Park

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

[...]

#43 lore raw
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.

#44 lore raw
In reply to SeongJae Park
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.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
==========================

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 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

--
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.

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() 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
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() 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]/

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

#45 lore raw
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

#46 lore raw
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 Park

Quoted 3 lines

thanks,
Shakeel

#47 lore raw
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

#48 lore raw
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

#49 lore raw
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

#50 lore raw
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 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?

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