On Tue, 10 Mar 2020 09:03:48 +0000 Jonathan Cameron <Jonathan.Cameron@xxxxxxxxxx> wrote: > On Mon, 24 Feb 2020 13:30:44 +0100 > SeongJae Park <sjpark@xxxxxxxxxx> wrote: > > > From: SeongJae Park <sjpark@xxxxxxxxx> > > > > 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 > > > > Signed-off-by: SeongJae Park <sjpark@xxxxxxxxx> > > --- > > .../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. > > > + > > +A number of experimental data access pattern awared memory management > > +optimizations say the sacrifices are > > +huge (2.55x slowdown). > > Good to have a reference. :) > > > However, none of those has successfully adopted to > > adopted into the Thanks for correcting. > [...] > > +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. > > > + > > + > > +``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? > > > + # 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! > > > + # 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 [...]
