Skip to content

Commit b1eee3c

Browse files
sjp38torvalds
sjp38
authored and
torvalds
committed
Docs/admin-guide/mm/damon/start: simplify the content
Information in 'TL; DR' section of 'Getting Started' is duplicated in other parts of the doc. It is also asking readers to visit the access pattern visualizations gallery web site to show the results of example visualization commands, while the users of the commands can use terminal output. To make the doc simple, this removes the duplicated 'TL; DR' section and replaces the visualization example commands with versions using terminal outputs. Link: https://lkml.kernel.org/r/[email protected] Signed-off-by: SeongJae Park <[email protected]> Cc: Jonathan Corbet <[email protected]> Cc: Peter Xu <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
1 parent 49ce7de commit b1eee3c

File tree

1 file changed

+60
-53
lines changed

1 file changed

+60
-53
lines changed

‎Documentation/admin-guide/mm/damon/start.rst

Lines changed: 60 additions & 53 deletions
Original file line numberDiff line numberDiff line change
@@ -11,38 +11,6 @@ of its features for brevity. Please refer to the usage `doc
1111
details.
1212

1313

14-
TL; DR
15-
======
16-
17-
Follow the commands below to monitor and visualize the memory access pattern of
18-
your workload. ::
19-
20-
# # build the kernel with CONFIG_DAMON_*=y, install it, and reboot
21-
# mount -t debugfs none /sys/kernel/debug/
22-
# git clone https://github.com/awslabs/damo
23-
# ./damo/damo record $(pidof <your workload>)
24-
# ./damo/damo report heats --heatmap stdout
25-
26-
The final command draws the access heatmap of ``<your workload>``. The heatmap
27-
shows which memory region (x-axis) is accessed when (y-axis) and how frequently
28-
(number; the higher the more accesses have been observed). ::
29-
30-
111111111111111111111111111111111111111111111111111111110000
31-
111121111111111111111111111111211111111111111111111111110000
32-
000000000000000000000000000000000000000000000000001555552000
33-
000000000000000000000000000000000000000000000222223555552000
34-
000000000000000000000000000000000000000011111677775000000000
35-
000000000000000000000000000000000000000488888000000000000000
36-
000000000000000000000000000000000177888400000000000000000000
37-
000000000000000000000000000046666522222100000000000000000000
38-
000000000000000000000014444344444300000000000000000000000000
39-
000000000000000002222245555510000000000000000000000000000000
40-
# access_frequency: 0 1 2 3 4 5 6 7 8 9
41-
# x-axis: space (140286319947776-140286426374096: 101.496 MiB)
42-
# y-axis: time (605442256436361-605479951866441: 37.695430s)
43-
# resolution: 60x10 (1.692 MiB and 3.770s for each character)
44-
45-
4614
Prerequisites
4715
=============
4816

@@ -93,22 +61,66 @@ pattern in the ``damon.data`` file.
9361
Visualizing Recorded Patterns
9462
=============================
9563

96-
The following three commands visualize the recorded access patterns and save
97-
the results as separate image files. ::
98-
99-
$ sudo damo report heats --heatmap access_pattern_heatmap.png
100-
$ sudo damo report wss --range 0 101 1 --plot wss_dist.png
101-
$ sudo damo report wss --range 0 101 1 --sortby time --plot wss_chron_change.png
102-
103-
- ``access_pattern_heatmap.png`` will visualize the data access pattern in a
104-
heatmap, showing which memory region (y-axis) got accessed when (x-axis)
105-
and how frequently (color).
106-
- ``wss_dist.png`` will show the distribution of the working set size.
107-
- ``wss_chron_change.png`` will show how the working set size has
108-
chronologically changed.
109-
110-
You can view the visualizations of this example workload at [1]_.
111-
Visualizations of other realistic workloads are available at [2]_ [3]_ [4]_.
64+
You can visualize the pattern in a heatmap, showing which memory region
65+
(x-axis) got accessed when (y-axis) and how frequently (number).::
66+
67+
$ sudo damo report heats --heatmap stdout
68+
22222222222222222222222222222222222222211111111111111111111111111111111111111100
69+
44444444444444444444444444444444444444434444444444444444444444444444444444443200
70+
44444444444444444444444444444444444444433444444444444444444444444444444444444200
71+
33333333333333333333333333333333333333344555555555555555555555555555555555555200
72+
33333333333333333333333333333333333344444444444444444444444444444444444444444200
73+
22222222222222222222222222222222222223355555555555555555555555555555555555555200
74+
00000000000000000000000000000000000000288888888888888888888888888888888888888400
75+
00000000000000000000000000000000000000288888888888888888888888888888888888888400
76+
33333333333333333333333333333333333333355555555555555555555555555555555555555200
77+
88888888888888888888888888888888888888600000000000000000000000000000000000000000
78+
88888888888888888888888888888888888888600000000000000000000000000000000000000000
79+
33333333333333333333333333333333333333444444444444444444444444444444444444443200
80+
00000000000000000000000000000000000000288888888888888888888888888888888888888400
81+
[...]
82+
# access_frequency: 0 1 2 3 4 5 6 7 8 9
83+
# x-axis: space (139728247021568-139728453431248: 196.848 MiB)
84+
# y-axis: time (15256597248362-15326899978162: 1 m 10.303 s)
85+
# resolution: 80x40 (2.461 MiB and 1.758 s for each character)
86+
87+
You can also visualize the distribution of the working set size, sorted by the
88+
size.::
89+
90+
$ sudo damo report wss --range 0 101 10
91+
# <percentile> <wss>
92+
# target_id 18446632103789443072
93+
# avr: 107.708 MiB
94+
0 0 B | |
95+
10 95.328 MiB |**************************** |
96+
20 95.332 MiB |**************************** |
97+
30 95.340 MiB |**************************** |
98+
40 95.387 MiB |**************************** |
99+
50 95.387 MiB |**************************** |
100+
60 95.398 MiB |**************************** |
101+
70 95.398 MiB |**************************** |
102+
80 95.504 MiB |**************************** |
103+
90 190.703 MiB |********************************************************* |
104+
100 196.875 MiB |***********************************************************|
105+
106+
Using ``--sortby`` option with the above command, you can show how the working
107+
set size has chronologically changed.::
108+
109+
$ sudo damo report wss --range 0 101 10 --sortby time
110+
# <percentile> <wss>
111+
# target_id 18446632103789443072
112+
# avr: 107.708 MiB
113+
0 3.051 MiB | |
114+
10 190.703 MiB |***********************************************************|
115+
20 95.336 MiB |***************************** |
116+
30 95.328 MiB |***************************** |
117+
40 95.387 MiB |***************************** |
118+
50 95.332 MiB |***************************** |
119+
60 95.320 MiB |***************************** |
120+
70 95.398 MiB |***************************** |
121+
80 95.398 MiB |***************************** |
122+
90 95.340 MiB |***************************** |
123+
100 95.398 MiB |***************************** |
112124

113125

114126
Data Access Pattern Aware Memory Management
@@ -120,8 +132,3 @@ accessed for >=60 seconds in your workload to be swapped out. ::
120132
$ echo "#min-size max-size min-acc max-acc min-age max-age action" > test_scheme
121133
$ echo "4K max 0 0 60s max pageout" >> test_scheme
122134
$ damo schemes -c test_scheme <pid of your workload>
123-
124-
.. [1] https://damonitor.github.io/doc/html/v17/admin-guide/mm/damon/start.html#visualizing-recorded-patterns
125-
.. [2] https://damonitor.github.io/test/result/visual/latest/rec.heatmap.1.png.html
126-
.. [3] https://damonitor.github.io/test/result/visual/latest/rec.wss_sz.png.html
127-
.. [4] https://damonitor.github.io/test/result/visual/latest/rec.wss_time.png.html

0 commit comments

Comments
 (0)