diff options
author | Linus Torvalds <torvalds@linux-foundation.org> | 2022-03-21 14:13:25 -0700 |
---|---|---|
committer | Linus Torvalds <torvalds@linux-foundation.org> | 2022-03-21 14:13:25 -0700 |
commit | 346658a5e189f35b61206fed2f9f60d4bb34b881 (patch) | |
tree | eff44d85cbd92095d1d17271489ca9d89a239824 /Documentation/translations/zh_CN/admin-guide/mm/damon | |
parent | d2eb5500f1d916c9b0815cdc63c48a6d615532cc (diff) | |
parent | 75c05fabb873367d9e64f063dda8a310c4c58826 (diff) | |
download | linux-346658a5e189f35b61206fed2f9f60d4bb34b881.tar.bz2 |
Merge tag 'docs-5.18' of git://git.lwn.net/linux
Pull documentation updates from Jonathan Corbet:
"It has been a moderately busy cycle for documentation; some of the
highlights are:
- Numerous PDF-generation improvements
- Kees's new document with guidelines for researchers studying the
development community.
- The ongoing stream of Chinese translations
- Thorsten's new document on regression handling
- A major reworking of the internal documentation for the kernel-doc
script.
Plus the usual stream of typo fixes and such"
* tag 'docs-5.18' of git://git.lwn.net/linux: (80 commits)
docs/kernel-parameters: update description of mem=
docs/zh_CN: Add sched-nice-design Chinese translation
docs: scheduler: Convert schedutil.txt to ReST
Docs: ktap: add code-block type
docs: serial: fix a reference file name in driver.rst
docs: UML: Mention telnetd for port channel
docs/zh_CN: add damon reclaim translation
docs/zh_CN: add damon usage translation
docs/zh_CN: add admin-guide damon start translation
docs/zh_CN: add admin-guide damon index translation
docs/zh_CN: Refactoring the admin-guide directory index
zh_CN: Add translation for admin-guide/mm/index.rst
zh_CN: Add translations for admin-guide/mm/ksm.rst
Add Chinese translation for vm/ksm.rst
docs/zh_CN: Add sched-stats Chinese translation
docs/zh_CN: add devicetree of_unittest translation
docs/zh_CN: add devicetree usage-model translation
docs/zh_CN: add devicetree index translation
Documentation: describe how to apply incremental stable patches
docs/zh_CN: add peci subsystem translation
...
Diffstat (limited to 'Documentation/translations/zh_CN/admin-guide/mm/damon')
4 files changed, 678 insertions, 0 deletions
diff --git a/Documentation/translations/zh_CN/admin-guide/mm/damon/index.rst b/Documentation/translations/zh_CN/admin-guide/mm/damon/index.rst new file mode 100644 index 000000000000..0c8276109fc0 --- /dev/null +++ b/Documentation/translations/zh_CN/admin-guide/mm/damon/index.rst @@ -0,0 +1,28 @@ +.. SPDX-License-Identifier: GPL-2.0 +.. include:: ../../../disclaimer-zh_CN.rst + +:Original: Documentation/admin-guide/mm/damon/index.rst + +:翻译: + + 司延腾 Yanteng Si <siyanteng@loongson.cn> + +:校译: + +============ +监测数据访问 +============ + +:doc:`DAMON </vm/damon/index>` 允许轻量级的数据访问监测。使用DAMON, +用户可以分析他们系统的内存访问模式,并优化它们。 + +.. toctree:: + :maxdepth: 2 + + start + usage + reclaim + + + + diff --git a/Documentation/translations/zh_CN/admin-guide/mm/damon/reclaim.rst b/Documentation/translations/zh_CN/admin-guide/mm/damon/reclaim.rst new file mode 100644 index 000000000000..9e541578f38d --- /dev/null +++ b/Documentation/translations/zh_CN/admin-guide/mm/damon/reclaim.rst @@ -0,0 +1,232 @@ +.. SPDX-License-Identifier: GPL-2.0 +.. include:: ../../../disclaimer-zh_CN.rst + +:Original: Documentation/admin-guide/mm/damon/reclaim.rst + +:翻译: + + 司延腾 Yanteng Si <siyanteng@loongson.cn> + +:校译: + +=============== +基于DAMON的回收 +=============== + +基于DAMON的回收(DAMON_RECLAIM)是一个静态的内核模块,旨在用于轻度内存压力下的主动和轻 +量级的回收。它的目的不是取代基于LRU列表的页面回收,而是有选择地用于不同程度的内存压力和要 +求。 + +哪些地方需要主动回收? +====================== + +在一般的内存超量使用(over-committed systems,虚拟化相关术语)的系统上,主动回收冷页 +有助于节省内存和减少延迟高峰,这些延迟是由直接回收进程或kswapd的CPU消耗引起的,同时只产 +生最小的性能下降 [1]_ [2]_ 。 + +基于空闲页报告 [3]_ 的内存过度承诺的虚拟化系统就是很好的例子。在这样的系统中,客户机 +向主机报告他们的空闲内存,而主机则将报告的内存重新分配给其他客户。因此,系统的内存得到了充 +分的利用。然而,客户可能不那么节省内存,主要是因为一些内核子系统和用户空间应用程序被设计为 +使用尽可能多的内存。然后,客户机可能只向主机报告少量的内存是空闲的,导致系统的内存利用率下降。 +在客户中运行主动回收可以缓解这个问题。 + +它是如何工作的? +================ + +DAMON_RECLAIM找到在特定时间内没有被访问的内存区域并分页。为了避免它在分页操作中消耗过多 +的CPU,可以配置一个速度限制。在这个速度限制下,它首先分页出那些没有被访问过的内存区域。系 +统管理员还可以配置在什么情况下这个方案应该自动激活和停用三个内存压力水位。 + +接口: 模块参数 +============== + +要使用这个功能,你首先要确保你的系统运行在一个以 ``CONFIG_DAMON_RECLAIM=y`` 构建的内 +核上。 + +为了让系统管理员启用或禁用它,并为给定的系统进行调整,DAMON_RECLAIM利用了模块参数。也就 +是说,你可以把 ``damon_reclaim.<parameter>=<value>`` 放在内核启动命令行上,或者把 +适当的值写入 ``/sys/modules/damon_reclaim/parameters/<parameter>`` 文件。 + +注意,除 ``启用`` 外的参数值只在DAMON_RECLAIM启动时应用。因此,如果你想在运行时应用新 +的参数值,而DAMON_RECLAIM已经被启用,你应该通过 ``启用`` 的参数文件禁用和重新启用它。 +在重新启用之前,应将新的参数值写入适当的参数值中。 + +下面是每个参数的描述。 + +enable +------ + +启用或禁用DAMON_RECLAIM。 + +你可以通过把这个参数的值设置为 ``Y`` 来启用DAMON_RCLAIM,把它设置为 ``N`` 可以禁用 +DAMON_RECLAIM。注意,由于基于水位的激活条件,DAMON_RECLAIM不能进行真正的监测和回收。 +这一点请参考下面关于水位参数的描述。 + +min_age +------- + +识别冷内存区域的时间阈值,单位是微秒。 + +如果一个内存区域在这个时间或更长的时间内没有被访问,DAMON_RECLAIM会将该区域识别为冷的, +并回收它。 + +默认为120秒。 + +quota_ms +-------- + +回收的时间限制,以毫秒为单位。 + +DAMON_RECLAIM 试图在一个时间窗口(quota_reset_interval_ms)内只使用到这个时间,以 +尝试回收冷页。这可以用来限制DAMON_RECLAIM的CPU消耗。如果该值为零,则该限制被禁用。 + +默认为10ms。 + +quota_sz +-------- + +回收的内存大小限制,单位为字节。 + +DAMON_RECLAIM 收取在一个时间窗口(quota_reset_interval_ms)内试图回收的内存量,并 +使其不超过这个限制。这可以用来限制CPU和IO的消耗。如果该值为零,则限制被禁用。 + +默认情况下是128 MiB。 + +quota_reset_interval_ms +----------------------- + +时间/大小配额收取重置间隔,单位为毫秒。 + +时间(quota_ms)和大小(quota_sz)的配额的目标重置间隔。也就是说,DAMON_RECLAIM在 +尝试回收‘不’超过quota_ms毫秒或quota_sz字节的内存。 + +默认为1秒。 + +wmarks_interval +--------------- + +当DAMON_RECLAIM被启用但由于其水位规则而不活跃时,在检查水位之前的最小等待时间。 + +wmarks_high +----------- + +高水位的可用内存率(每千字节)。 + +如果系统的可用内存(以每千字节为单位)高于这个数值,DAMON_RECLAIM就会变得不活跃,所以 +它什么也不做,只是定期检查水位。 + +wmarks_mid +---------- + +中间水位的可用内存率(每千字节)。 + +如果系统的空闲内存(以每千字节为单位)在这个和低水位线之间,DAMON_RECLAIM就会被激活, +因此开始监测和回收。 + +wmarks_low +---------- + +低水位的可用内存率(每千字节)。 + +如果系统的空闲内存(以每千字节为单位)低于这个数值,DAMON_RECLAIM就会变得不活跃,所以 +它除了定期检查水位外什么都不做。在这种情况下,系统会退回到基于LRU列表的页面粒度回收逻辑。 + +sample_interval +--------------- + +监测的采样间隔,单位是微秒。 + +DAMON用于监测冷内存的采样间隔。更多细节请参考DAMON文档 (:doc:`usage`) 。 + +aggr_interval +------------- + +监测的聚集间隔,单位是微秒。 + +DAMON对冷内存监测的聚集间隔。更多细节请参考DAMON文档 (:doc:`usage`)。 + +min_nr_regions +-------------- + +监测区域的最小数量。 + +DAMON用于冷内存监测的最小监测区域数。这可以用来设置监测质量的下限。但是,设 +置的太高可能会导致监测开销的增加。更多细节请参考DAMON文档 (:doc:`usage`) 。 + +max_nr_regions +-------------- + +监测区域的最大数量。 + +DAMON用于冷内存监测的最大监测区域数。这可以用来设置监测开销的上限值。但是, +设置得太低可能会导致监测质量不好。更多细节请参考DAMON文档 (:doc:`usage`) 。 + +monitor_region_start +-------------------- + +目标内存区域的物理地址起点。 + +DAMON_RECLAIM将对其进行工作的内存区域的起始物理地址。也就是说,DAMON_RECLAIM +将在这个区域中找到冷的内存区域并进行回收。默认情况下,该区域使用最大系统内存区。 + +monitor_region_end +------------------ + +目标内存区域的结束物理地址。 + +DAMON_RECLAIM将对其进行工作的内存区域的末端物理地址。也就是说,DAMON_RECLAIM将 +在这个区域内找到冷的内存区域并进行回收。默认情况下,该区域使用最大系统内存区。 + +kdamond_pid +----------- + +DAMON线程的PID。 + +如果DAMON_RECLAIM被启用,这将成为工作线程的PID。否则,为-1。 + +nr_reclaim_tried_regions +------------------------ + +试图通过DAMON_RECLAIM回收的内存区域的数量。 + +bytes_reclaim_tried_regions +--------------------------- + +试图通过DAMON_RECLAIM回收的内存区域的总字节数。 + +nr_reclaimed_regions +-------------------- + +通过DAMON_RECLAIM成功回收的内存区域的数量。 + +bytes_reclaimed_regions +----------------------- + +通过DAMON_RECLAIM成功回收的内存区域的总字节数。 + +nr_quota_exceeds +---------------- + +超过时间/空间配额限制的次数。 + +例子 +==== + +下面的运行示例命令使DAMON_RECLAIM找到30秒或更长时间没有访问的内存区域并“回收”? +为了避免DAMON_RECLAIM在分页操作中消耗过多的CPU时间,回收被限制在每秒1GiB以内。 +它还要求DAMON_RECLAIM在系统的可用内存率超过50%时不做任何事情,但如果它低于40%时 +就开始真正的工作。如果DAMON_RECLAIM没有取得进展,因此空闲内存率低于20%,它会要求 +DAMON_RECLAIM再次什么都不做,这样我们就可以退回到基于LRU列表的页面粒度回收了:: + + # cd /sys/modules/damon_reclaim/parameters + # echo 30000000 > min_age + # echo $((1 * 1024 * 1024 * 1024)) > quota_sz + # echo 1000 > quota_reset_interval_ms + # echo 500 > wmarks_high + # echo 400 > wmarks_mid + # echo 200 > wmarks_low + # echo Y > enabled + +.. [1] https://research.google/pubs/pub48551/ +.. [2] https://lwn.net/Articles/787611/ +.. [3] https://www.kernel.org/doc/html/latest/vm/free_page_reporting.html diff --git a/Documentation/translations/zh_CN/admin-guide/mm/damon/start.rst b/Documentation/translations/zh_CN/admin-guide/mm/damon/start.rst new file mode 100644 index 000000000000..67d1b49481dc --- /dev/null +++ b/Documentation/translations/zh_CN/admin-guide/mm/damon/start.rst @@ -0,0 +1,132 @@ +.. SPDX-License-Identifier: GPL-2.0 +.. include:: ../../../disclaimer-zh_CN.rst + +:Original: Documentation/admin-guide/mm/damon/start.rst + +:翻译: + + 司延腾 Yanteng Si <siyanteng@loongson.cn> + +:校译: + +======== +入门指南 +======== + +本文通过演示DAMON的默认用户空间工具,简要地介绍了如何使用DAMON。请注意,为了简洁 +起见,本文档只描述了它的部分功能。更多细节请参考该工具的使用文档。 +`doc <https://github.com/awslabs/damo/blob/next/USAGE.md>`_ . + + +前提条件 +======== + +内核 +---- + +首先,你要确保你当前系统中跑的内核构建时选定了这个功能选项 ``CONFIG_DAMON_*=y``. + + +用户空间工具 +------------ + +在演示中,我们将使用DAMON的默认用户空间工具,称为DAMON Operator(DAMO)。它可以在 +https://github.com/awslabs/damo找到。下面的例子假设DAMO在你的$PATH上。当然,但 +这并不是强制性的。 + +因为DAMO使用的是DAMON的debugfs接口(详情请参考 :doc:`usage` 中的使用方法) 你应该 +确保debugfs被挂载。手动挂载它,如下所示:: + + # mount -t debugfs none /sys/kernel/debug/ + +或者在你的 ``/etc/fstab`` 文件中添加以下一行,这样你的系统就可以在启动时自动挂载 +debugfs了:: + + debugfs /sys/kernel/debug debugfs defaults 0 0 + + +记录数据访问模式 +================ + +下面的命令记录了一个程序的内存访问模式,并将监测结果保存到文件中。 :: + + $ git clone https://github.com/sjp38/masim + $ cd masim; make; ./masim ./configs/zigzag.cfg & + $ sudo damo record -o damon.data $(pidof masim) + +命令的前两行下载了一个人工内存访问生成器程序并在后台运行。生成器将重复地逐一访问两个 +100 MiB大小的内存区域。你可以用你的真实工作负载来代替它。最后一行要求 ``damo`` 将 +访问模式记录在 ``damon.data`` 文件中。 + + +将记录的模式可视化 +================== + +你可以在heatmap中直观地看到这种模式,显示哪个内存区域(X轴)何时被访问(Y轴)以及访 +问的频率(数字)。:: + + $ sudo damo report heats --heatmap stdout + 22222222222222222222222222222222222222211111111111111111111111111111111111111100 + 44444444444444444444444444444444444444434444444444444444444444444444444444443200 + 44444444444444444444444444444444444444433444444444444444444444444444444444444200 + 33333333333333333333333333333333333333344555555555555555555555555555555555555200 + 33333333333333333333333333333333333344444444444444444444444444444444444444444200 + 22222222222222222222222222222222222223355555555555555555555555555555555555555200 + 00000000000000000000000000000000000000288888888888888888888888888888888888888400 + 00000000000000000000000000000000000000288888888888888888888888888888888888888400 + 33333333333333333333333333333333333333355555555555555555555555555555555555555200 + 88888888888888888888888888888888888888600000000000000000000000000000000000000000 + 88888888888888888888888888888888888888600000000000000000000000000000000000000000 + 33333333333333333333333333333333333333444444444444444444444444444444444444443200 + 00000000000000000000000000000000000000288888888888888888888888888888888888888400 + [...] + # access_frequency: 0 1 2 3 4 5 6 7 8 9 + # x-axis: space (139728247021568-139728453431248: 196.848 MiB) + # y-axis: time (15256597248362-15326899978162: 1 m 10.303 s) + # resolution: 80x40 (2.461 MiB and 1.758 s for each character) + +你也可以直观地看到工作集的大小分布,按大小排序。:: + + $ sudo damo report wss --range 0 101 10 + # <percentile> <wss> + # target_id 18446632103789443072 + # avr: 107.708 MiB + 0 0 B | | + 10 95.328 MiB |**************************** | + 20 95.332 MiB |**************************** | + 30 95.340 MiB |**************************** | + 40 95.387 MiB |**************************** | + 50 95.387 MiB |**************************** | + 60 95.398 MiB |**************************** | + 70 95.398 MiB |**************************** | + 80 95.504 MiB |**************************** | + 90 190.703 MiB |********************************************************* | + 100 196.875 MiB |***********************************************************| + +在上述命令中使用 ``--sortby`` 选项,可以显示工作集的大小是如何按时间顺序变化的。:: + + $ sudo damo report wss --range 0 101 10 --sortby time + # <percentile> <wss> + # target_id 18446632103789443072 + # avr: 107.708 MiB + 0 3.051 MiB | | + 10 190.703 MiB |***********************************************************| + 20 95.336 MiB |***************************** | + 30 95.328 MiB |***************************** | + 40 95.387 MiB |***************************** | + 50 95.332 MiB |***************************** | + 60 95.320 MiB |***************************** | + 70 95.398 MiB |***************************** | + 80 95.398 MiB |***************************** | + 90 95.340 MiB |***************************** | + 100 95.398 MiB |***************************** | + + +数据访问模式感知的内存管理 +========================== + +以下三个命令使每一个大小>=4K的内存区域在你的工作负载中没有被访问>=60秒,就会被换掉。 :: + + $ echo "#min-size max-size min-acc max-acc min-age max-age action" > test_scheme + $ echo "4K max 0 0 60s max pageout" >> test_scheme + $ damo schemes -c test_scheme <pid of your workload> diff --git a/Documentation/translations/zh_CN/admin-guide/mm/damon/usage.rst b/Documentation/translations/zh_CN/admin-guide/mm/damon/usage.rst new file mode 100644 index 000000000000..5d7533347216 --- /dev/null +++ b/Documentation/translations/zh_CN/admin-guide/mm/damon/usage.rst @@ -0,0 +1,286 @@ +.. SPDX-License-Identifier: GPL-2.0 +.. include:: ../../../disclaimer-zh_CN.rst + +:Original: Documentation/admin-guide/mm/damon/usage.rst + +:翻译: + + 司延腾 Yanteng Si <siyanteng@loongson.cn> + +:校译: + +======== +详细用法 +======== + +DAMON 为不同的用户提供了下面三种接口。 + +- *DAMON用户空间工具。* + `这 <https://github.com/awslabs/damo>`_ 为有这特权的人, 如系统管理员,希望有一个刚好 + 可以工作的人性化界面。 + 使用它,用户可以以人性化的方式使用DAMON的主要功能。不过,它可能不会为特殊情况进行高度调整。 + 它同时支持虚拟和物理地址空间的监测。更多细节,请参考它的 `使用文档 + <https://github.com/awslabs/damo/blob/next/USAGE.md>`_。 +- *debugfs接口。* + :ref:`这 <debugfs_interface>` 是为那些希望更高级的使用DAMON的特权用户空间程序员准备的。 + 使用它,用户可以通过读取和写入特殊的debugfs文件来使用DAMON的主要功能。因此,你可以编写和使 + 用你个性化的DAMON debugfs包装程序,代替你读/写debugfs文件。 `DAMON用户空间工具 + <https://github.com/awslabs/damo>`_ 就是这种程序的一个例子 它同时支持虚拟和物理地址 + 空间的监测。注意,这个界面只提供简单的监测结果 :ref:`统计 <damos_stats>`。对于详细的监测 + 结果,DAMON提供了一个:ref:`跟踪点 <tracepoint>`。 + +- *内核空间编程接口。* + :doc:`This </vm/damon/api>` 这是为内核空间程序员准备的。使用它,用户可以通过为你编写内 + 核空间的DAMON应用程序,最灵活有效地利用DAMON的每一个功能。你甚至可以为各种地址空间扩展DAMON。 + 详细情况请参考接口 :doc:`文件 </vm/damon/api>`。 + + +debugfs接口 +=========== + +DAMON导出了八个文件, ``attrs``, ``target_ids``, ``init_regions``, +``schemes``, ``monitor_on``, ``kdamond_pid``, ``mk_contexts`` 和 +``rm_contexts`` under its debugfs directory, ``<debugfs>/damon/``. + + +属性 +---- + +用户可以通过读取和写入 ``attrs`` 文件获得和设置 ``采样间隔`` 、 ``聚集间隔`` 、 ``区域更新间隔`` +以及监测目标区域的最小/最大数量。要详细了解监测属性,请参考 `:doc:/vm/damon/design` 。例如, +下面的命令将这些值设置为5ms、100ms、1000ms、10和1000,然后再次检查:: + + # cd <debugfs>/damon + # echo 5000 100000 1000000 10 1000 > attrs + # cat attrs + 5000 100000 1000000 10 1000 + + +目标ID +------ + +一些类型的地址空间支持多个监测目标。例如,虚拟内存地址空间的监测可以有多个进程作为监测目标。用户 +可以通过写入目标的相关id值来设置目标,并通过读取 ``target_ids`` 文件来获得当前目标的id。在监 +测虚拟地址空间的情况下,这些值应该是监测目标进程的pid。例如,下面的命令将pid为42和4242的进程设 +为监测目标,并再次检查:: + + # cd <debugfs>/damon + # echo 42 4242 > target_ids + # cat target_ids + 42 4242 + +用户还可以通过在文件中写入一个特殊的关键字 "paddr\n" 来监测系统的物理内存地址空间。因为物理地 +址空间监测不支持多个目标,读取文件会显示一个假值,即 ``42`` ,如下图所示:: + + # cd <debugfs>/damon + # echo paddr > target_ids + # cat target_ids + 42 + +请注意,设置目标ID并不启动监测。 + + +初始监测目标区域 +---------------- + +在虚拟地址空间监测的情况下,DAMON自动设置和更新监测的目标区域,这样就可以覆盖目标进程的整个 +内存映射。然而,用户可能希望将监测区域限制在特定的地址范围内,如堆、栈或特定的文件映射区域。 +或者,一些用户可以知道他们工作负载的初始访问模式,因此希望为“自适应区域调整”设置最佳初始区域。 + +相比之下,DAMON在物理内存监测的情况下不会自动设置和更新监测目标区域。因此,用户应该自己设置 +监测目标区域。 + +在这种情况下,用户可以通过在 ``init_regions`` 文件中写入适当的值,明确地设置他们想要的初 +始监测目标区域。输入的每一行应代表一个区域,形式如下:: + + <target idx> <start address> <end address> + +目标idx应该是 ``target_ids`` 文件中目标的索引,从 ``0`` 开始,区域应该按照地址顺序传递。 +例如,下面的命令将设置几个地址范围, ``1-100`` 和 ``100-200`` 作为pid 42的初始监测目标 +区域,这是 ``target_ids`` 中的第一个(索引 ``0`` ),另外几个地址范围, ``20-40`` 和 +``50-100`` 作为pid 4242的地址,这是 ``target_ids`` 中的第二个(索引 ``1`` ):: + + # cd <debugfs>/damon + # cat target_ids + 42 4242 + # echo "0 1 100 + 0 100 200 + 1 20 40 + 1 50 100" > init_regions + +请注意,这只是设置了初始的监测目标区域。在虚拟内存监测的情况下,DAMON会在一个 ``区域更新间隔`` +后自动更新区域的边界。因此,在这种情况下,如果用户不希望更新的话,应该把 ``区域的更新间隔`` 设 +置得足够大。 + + +方案 +---- + +对于通常的基于DAMON的数据访问感知的内存管理优化,用户只是希望系统对特定访问模式的内存区域应用内 +存管理操作。DAMON从用户那里接收这种形式化的操作方案,并将这些方案应用到目标进程中。 + +用户可以通过读取和写入 ``scheme`` debugfs文件来获得和设置这些方案。读取该文件还可以显示每个 +方案的统计数据。在文件中,每一个方案都应该在每一行中以下列形式表示出来:: + + <target access pattern> <action> <quota> <watermarks> + +你可以通过简单地在文件中写入一个空字符串来禁用方案。 + +目标访问模式 +~~~~~~~~~~~~ + +``<目标访问模式>`` 是由三个范围构成的,形式如下:: + + min-size max-size min-acc max-acc min-age max-age + +具体来说,区域大小的字节数( `min-size` 和 `max-size` ),访问频率的每聚合区间的监测访问次 +数( `min-acc` 和 `max-acc` ),区域年龄的聚合区间数( `min-age` 和 `max-age` )都被指定。 +请注意,这些范围是封闭区间。 + +动作 +~~~~ + +``<action>`` 是一个预定义的内存管理动作的整数,DAMON将应用于具有目标访问模式的区域。支持 +的数字和它们的含义如下:: + + - 0: Call ``madvise()`` for the region with ``MADV_WILLNEED`` + - 1: Call ``madvise()`` for the region with ``MADV_COLD`` + - 2: Call ``madvise()`` for the region with ``MADV_PAGEOUT`` + - 3: Call ``madvise()`` for the region with ``MADV_HUGEPAGE`` + - 4: Call ``madvise()`` for the region with ``MADV_NOHUGEPAGE`` + - 5: Do nothing but count the statistics + +配额 +~~~~ + +每个 ``动作`` 的最佳 ``目标访问模式`` 取决于工作负载,所以不容易找到。更糟糕的是,将某个 +动作的方案设置得过于激进会导致严重的开销。为了避免这种开销,用户可以通过下面表格中的 ``<quota>`` +来限制方案的时间和大小配额:: + + <ms> <sz> <reset interval> <priority weights> + +这使得DAMON在 ``<reset interval>`` 毫秒内,尽量只用 ``<ms>`` 毫秒的时间对 ``目标访 +问模式`` 的内存区域应用动作,并在 ``<reset interval>`` 内只对最多<sz>字节的内存区域应 +用动作。将 ``<ms>`` 和 ``<sz>`` 都设置为零,可以禁用配额限制。 + +当预计超过配额限制时,DAMON会根据 ``目标访问模式`` 的大小、访问频率和年龄,对发现的内存 +区域进行优先排序。为了实现个性化的优先级,用户可以在 ``<优先级权重>`` 中设置这三个属性的 +权重,具体形式如下:: + + <size weight> <access frequency weight> <age weight> + +水位 +~~~~ + +有些方案需要根据系统特定指标的当前值来运行,如自由内存比率。对于这种情况,用户可以为该条 +件指定水位。:: + + <metric> <check interval> <high mark> <middle mark> <low mark> + +``<metric>`` 是一个预定义的整数,用于要检查的度量。支持的数字和它们的含义如下。 + + - 0: 忽视水位 + - 1: 系统空闲内存率 (千分比) + +每隔 ``<检查间隔>`` 微秒检查一次公制的值。 + +如果该值高于 ``<高标>`` 或低于 ``<低标>`` ,该方案被停用。如果该值低于 ``<中标>`` , +该方案将被激活。 + +统计数据 +~~~~~~~~ + +它还统计每个方案被尝试应用的区域的总数量和字节数,每个方案被成功应用的区域的两个数量,以 +及超过配额限制的总数量。这些统计数据可用于在线分析或调整方案。 + +统计数据可以通过读取方案文件来显示。读取该文件将显示你在每一行中输入的每个 ``方案`` , +统计的五个数字将被加在每一行的末尾。 + +例子 +~~~~ + +下面的命令应用了一个方案:”如果一个大小为[4KiB, 8KiB]的内存区域在[10, 20]的聚合时间 +间隔内显示出每一个聚合时间间隔[0, 5]的访问量,请分页出该区域。对于分页,每秒最多只能使 +用10ms,而且每秒分页不能超过1GiB。在这一限制下,首先分页出具有较长年龄的内存区域。另外, +每5秒钟检查一次系统的可用内存率,当可用内存率低于50%时开始监测和分页,但如果可用内存率 +大于60%,或低于30%,则停止监测“:: + + # cd <debugfs>/damon + # scheme="4096 8192 0 5 10 20 2" # target access pattern and action + # scheme+=" 10 $((1024*1024*1024)) 1000" # quotas + # scheme+=" 0 0 100" # prioritization weights + # scheme+=" 1 5000000 600 500 300" # watermarks + # echo "$scheme" > schemes + + +开关 +---- + +除非你明确地启动监测,否则如上所述的文件设置不会产生效果。你可以通过写入和读取 ``monitor_on`` +文件来启动、停止和检查监测的当前状态。写入 ``on`` 该文件可以启动对有属性的目标的监测。写入 +``off`` 该文件则停止这些目标。如果每个目标进程被终止,DAMON也会停止。下面的示例命令开启、关 +闭和检查DAMON的状态:: + + # cd <debugfs>/damon + # echo on > monitor_on + # echo off > monitor_on + # cat monitor_on + off + +请注意,当监测开启时,你不能写到上述的debugfs文件。如果你在DAMON运行时写到这些文件,将会返 +回一个错误代码,如 ``-EBUSY`` 。 + + +监测线程PID +----------- + +DAMON通过一个叫做kdamond的内核线程来进行请求监测。你可以通过读取 ``kdamond_pid`` 文件获 +得该线程的 ``pid`` 。当监测被 ``关闭`` 时,读取该文件不会返回任何信息:: + + # cd <debugfs>/damon + # cat monitor_on + off + # cat kdamond_pid + none + # echo on > monitor_on + # cat kdamond_pid + 18594 + + +使用多个监测线程 +---------------- + +每个监测上下文都会创建一个 ``kdamond`` 线程。你可以使用 ``mk_contexts`` 和 ``rm_contexts`` +文件为多个 ``kdamond`` 需要的用例创建和删除监测上下文。 + +将新上下文的名称写入 ``mk_contexts`` 文件,在 ``DAMON debugfs`` 目录上创建一个该名称的目录。 +该目录将有该上下文的 ``DAMON debugfs`` 文件:: + + # cd <debugfs>/damon + # ls foo + # ls: cannot access 'foo': No such file or directory + # echo foo > mk_contexts + # ls foo + # attrs init_regions kdamond_pid schemes target_ids + +如果不再需要上下文,你可以通过把上下文的名字放到 ``rm_contexts`` 文件中来删除它和相应的目录:: + + # echo foo > rm_contexts + # ls foo + # ls: cannot access 'foo': No such file or directory + +注意, ``mk_contexts`` 、 ``rm_contexts`` 和 ``monitor_on`` 文件只在根目录下。 + + +监测结果的监测点 +================ + +DAMON通过一个tracepoint ``damon:damon_aggregated`` 提供监测结果. 当监测开启时,你可 +以记录追踪点事件,并使用追踪点支持工具如perf显示结果。比如说:: + + # echo on > monitor_on + # perf record -e damon:damon_aggregated & + # sleep 5 + # kill 9 $(pidof perf) + # echo off > monitor_on + # perf script |