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

On Tue, 10 Mar 2020 09:03:48 +0000 Jonathan Cameron [off-list ref] wrote:

On Mon, 24 Feb 2020 13:30:44 +0100
SeongJae Park [off-list ref] wrote:

quoted

From: SeongJae Park <redacted>

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

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

Signed-off-by: SeongJae Park <redacted>
---
 .../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

diff --git a/Documentation/admin-guide/mm/data_access_monitor.rst b/Documentation/admin-guide/mm/data_access_monitor.rst
new file mode 100644
index 000000000000..4d836c3866e2
--- /dev/null
+++ b/Documentation/admin-guide/mm/data_access_monitor.rst

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

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

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

However, none of those has successfully adopted to

adopted into the 

Thanks for correcting.

[...]

quoted

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

I was afraid if it is too implementation detail, as this document is for admin
users.  Will add it in next spin, though.

quoted

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

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

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

write it to record, not pids.

Ah, good eye!

quoted

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

Perhaps -EBUSY would be more informative?  Implies values might be fine, but
the issue is 'not now'.

Agreed, will change so!


Thanks,
SeongJae Park

[...]