LWN: 利用 DAMON 进行内存主动回收！

关注了就能看到更多这么棒的文章哦～

Using DAMON for proactive reclaim

By Jonathan Corbet
July 23, 2021
DeepL assisted translation
https://lwn.net/Articles/863753/

DAMON patch set 在 2020 年初的时候 LWN 曾经第一次报道过。而这项工作现在已经进入第 34 版了。它的目的是能够有效收集 Linux 系统的内存使用的模式相关的信息。然后使用这些数据来影响内核的内存管理子系统的行为，比如其中一种可能的方法用法是更积极地回收那些未被使用的内存。为此，DAMON 的作者 SeongJae Park 提出了一个基于 DAMON 的机制来实现用户可以控制的主动回收。

DAMON 的核心思想是使用一种采样（sampling）技术来确定哪些内存是正在使用的，哪些是正在闲置的。进程的虚拟地址空间被分成不同的区域（region），划分出来的区域的 size 并不相同，而是根据活跃情况来划分的。接下来随着时间的推移会对最繁忙的区域进行更细地划分，从而进行更精细的监控。在每个区域内会随机选择一个 page 进行监控，它的活跃程度就被认为是代表了整个区域的情况。在需要的时候，DAMON 会以直方图（histogram）的形式生成一份报告来报告每个内存区域的繁忙程度。

Putting DAMON to work

一开始设立这项工作的时候，目标就是希望使用 DAMON 数据，可以通过调整内存管理子系统的行为来提高系统性能。最初的例子是 DAMON operation schemes（DAMOS）这组 patch，它增加了机制来根据使用模式进行各种 madvise() 调用。因此，比如说就可以提出 request 来将很少使用的内存换出（page out）出来，或者对那些范围很大的活跃区域来使用 huge page 管理。

主动回收（proactive-reclaim）补丁是基于 DAMOS 的，希望能让内存管理的行为更加积极主动。这项工作主要是开发了一个新的 kernel module，用来监测 DAMON 的数据，找到那些在这段时间内没有被访问过的内存区域，从而主动回收这些区域内的 page 页面来用于其他用途，哪怕系统目前没有感到内存压力也这样做。其结果令人印象深刻，可以看到减少了 latency 的峰值，以及减少了 direct reclaim 的耗时，从而让系统的整体性能得到了重大改进。不过，要达到这个目的话还需要做一些改动。

开发工作的第一步是为 DAMOS 添加一个 "pageout" 方案，允许直接调用内存回收动作（reclaim operation）。这与之前实现的 madvise()机制不同，因为它是操作物理页面的，而 madvise()是针对单个进程的虚拟地址空间。正如 madvise() 的名字所说的，它仅仅是建议而已，而新的 pageout scheme 方案会直接触发 reclaim。因此，对于真正将 page 从内存中换出这个效果方面它要更加有效。

Makeing proactive reclaim efficient

值得注意的是，主动回收（proactive reclaim）并不是一个新想法。例如 2019 年 Linux 存储、文件系统和内存管理峰会（2019 Linux Storage, Filesystem, and Memory-Management Summit）上就讨论过这个问题。当时与会的开发人员一致认为，对那些看起来未真正使用的内存进行主动回收会更有价值。毕竟，这就是内存管理子系统一直在努力要实现的功能。问题是这个动作的开销成本。因为要想密切监视系统从而找出哪些 page 是真正闲置的，这需要反复扫描观察所有的内存，这个开销很大。在许多情况下（其实应该是大多数情况），这种开销会超过精准主动回收 page 带来的好处，所以这项工作并没有进入 mainline kernel。

DAMON 的主要目标就是让这种监控开销变小。Park 在提出 proactive-reclaim 的邮件中这样描述：

它的监控开销可以得到自适应的控制，从而使得监控开销可以最小化。它还使得这个开销的上限可由客户来进行配置，无论需要监控的目标内存的整体大小是多少。在每 5 毫秒监控一次具有 70GB 内存的生产系统时，它消耗的 CPU 时间不到 1%。

这个监测的粒度是可以配置的，从而使得开销能在用户可以接受的范围内。当然，开销上限配置得越低，就会导致结果越不准确。我们希望 DAMON 的效率可以克服人们对主动回收的开销的反对，但这并不能完全解决这个问题。内存回收操作本身也有成本，我们也不能让这个成本失去控制。

为了避免这个问题，proactive-reclaim patch set 增加了一些控制节点，允许对新机制进行配置。其中一个控制节点直接控制了在每个时间单位中（具体多长时间也是可以设置的）可以操作的内存大小（单位是字节数）。等达到这个配额之后，proactive-reclaim 将主动暂停工作，等到下一个时间段再开始。为了避免一直卡在某个内存区域，proactive-reclaim 在触发了这个 limit 之后，在下一个时间段会跳转到新的一个区域。

除此之外还有一个设置时间配额的控制节点，即每个时间段允许 proactive-reclaim 利用多少 CPU 时间。同样，如果超过了这个时间的话，reclaim 工作将会暂停，直到下一个时间段再开始。不过还有另一个控制节点，可以允许在系统的 free 内存超过一个设定值的时候将整个机制暂停。毕竟，如果空闲内存已经超过了需求，那么继续占用系统资源来强制释放内存就没有价值了。有趣的是，如果 free 内存太少的话，proactive-reclaim 也可以暂停。在这种情况下内存管理子系统已经在主动进行内存回收了，这个 proactive 机制机制最好不要插手。

最后，还有一个优先级判定机制。根据 quote 参数的设置，proactive-reclaim 很可能无法在实际给它的时间内完成所有的内存检查和回收动作，这种情况下就可以考虑把工作集中在那些可以获得最大利益的区域了。用户可以调整另一组控制节点，根据各个区域的大小、存在时长和访问频率，来把内存回收工作聚焦在一些特定区域上。

Not for everybody

所有这些工作合在一起建立了一个全新的机制，其中有很多参数需要针对性的调整。而且，有可能会损害系统的性能而不是提高性能。这组 patch 中的 documentation patch 详细描述了如何使用这个新的 module。它似乎不太会是普通用户希望使用的功能。

不过，对于那些需要从他们的系统得到最佳性能、并且有时间微调系统的管理员来说，proactive reclaim 可能会带来一些显著的好处。与 patch set 一起发布的那些 benchmark 的结果就说明，不受限制的 reclaim module 可以释放近一半的可用内存，但这要付出一些代价：将近 12% 的 CPU 专门用于页面回收工作，同时 workload 运行速度会有略高于 5% 的降低（可能是由于被回收的内存在后续再次需要时增加了 paging 换入操作）。通过设置一些限制就可以大大减少系统开销，同时还仍然能得到获得大多数 free memory 的好处，利用这些来执行其他的 workload。不过，最佳的参数似乎很可能在很大程度上取决于 workload 的特性。

proactive-reclaim 工作在邮件列表中已经是第三轮讨论了，但 DAMON 本身已经发布了 34 次，没有明确的迹象表明它何时会被合并到 mainline 中（甚至是否会被合入都不确定）。Park 显然希望能看到有一些进展，因此 patch 中一开始就要求大家对 DAMON 的工作进行 review。如果 DAMON 以及基于它的这些机制要想进入 mainline，那么就需要得到更多的 review，以及能看到人们对这项工作的更多兴趣。

全文完
LWN 文章遵循 CC BY-SA 4.0 许可协议。

长按下面二维码关注，关注 LWN 深度文章以及开源社区的各种新近言论～