LWN：用DAMON来优化memory-management！

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

Memory-management optimization with DAMON

By Jonathan Corbet
February 20, 2020

原文来自：https://lwn.net/Articles/812707/

memory management（内存管理）其实在很大程度上是依靠预测来做决策的：哪些memory page会在近期被某个进程访问？可惜，做好预测是非常难的，尤其是这些都是针对未来的一些事件的。既然没有人能从未来传递这些信息给我们，那么memory-management subsystem就只能通过观察过去一小段事件内的行为来假设这种行为模式会保持下去。不过，kernel的memory management决策对user space来说是透明不可见的，因此经常看到这些决策得到的性能表现不是最优的。最近SeongJae Park就提出两个patch set，试图让memory-usage的模式对user space课件，让user space可以相应地调整memory-management决策。

这个新机制的核心就是data access monitor，DAMON。它可以把memory-access pattern暴露给user space。从概念上来说，这个动作非常简单，DAMON会先把一个进程的地址空间分割成许多同等大小的region（区域），然后监控对每个region的访问，输出一个直方图来展示对各个region的访问次数。读取到这个信息的用户（可以是user space也可以是kernel里）就可以要求来优化这个进程对memory的使用。

当然，现实情况总是更加复杂的。目前的硬件能支持非常巨大的地址空间，其中绝大多数是从来用不到的地址。如果简单把这么大的地址空间平分为1000个region，那么肯定会只有少数几个region是真正有访问的。DAMON会先把地址空间分成3个chunks(大块区域)，近似于对应着text, heap和stack区域。只有这些区域才会进行访问监测。

每个region里面，DAMON都会记录访问的次数。如果监测某个region里面的全部page的访问，那可就有点浪费资源了。DAMON的一个主要设计目标就是希望能在production workload（生产环境里的真实工作负载）场景下也能高效率的采集到信息。这个目标是通过一个假设来实现的：假设一个region中，所有page都有相同的访问模式，这样的话，只需要监控一个page就够了。这样一来，在每个region里面，会随机选择一个page，在bitmap中把它对应的“accessed（访问过）”bit先清零，然后时不时地检查一下。如果这个page被访问过了，那么就算作这个region都被访问过了。

如果被监控的进程愿意把它自己的memory-access pattern都排好，按照DAMON来选择的region挨个访问，那就太好了。不过实际上当然很少有这么好的事。所以，这些平均分割好的region很可能没法跟真正的memory访问对应上。DAMON会试着在此进程执行的过程中来动态调整这些region的划分，从而来弥补原方案的缺点。那些非常频繁访问到的region，会被分成更小的区域，而那些很少用到的区域则合并成大块的block。一切正常运行的话，随着时间推移，结果就会聚焦在目标进程地址空间里的真正热点区域上。

为了能更好地控制这个过程，DAMON在debugfs文件系统里面创建了一些虚拟文件。DAMON并没有配置访问权限，不过这些文件缺省是只有root权限的用户才可以访问。所有相关的参数——包括目标进程，region的数目，采样和汇聚的周期——都可以通过写这些文件来配置。最终数据也可以通过debugfs读出来。也可以直接让kernel把采样出来的数据直接写入文件，这样后续就可以慢慢处理了。还可以让用户attach到一个tracepoint上，就能随着数据的产生，实时收到这些数据。这样一来perf工具就可以直接利用这个功能了。

不过这个获取的数据本质上是个直方图，每个memory region都有一个数据，记录了访问到这个区域的数量。这个数据可以人工分析，也有一个sample script可以把它送给gnuplot来图形化展示出来。Park认为这类信息会非常有用：“为了评估这些监控数据有多大用处，我们利用DAMON的输出对9种memory intensive（访存密集型） workload在内存紧张的条件下进行了优化。具体来说，我们利用DAMON数据找到了每种workload中经常被访问到的memory region，然后用mlock()系统调用来保护这些区域。优化过的软件基本上在内存紧张时都有性能提升（最高的有2.55倍，平均1.65倍）。”

这种性能提升，已经足够说明花时间分析进程的memory pattern是非常值得的。甚至，如果kernel能自己搞定这个工作的话那就更完美了。毕竟这本来就是memory-management subsystem本来应该解决的问题。作为在这个方向上的尝试，Park又发布了另一个patch set，实现了“data access monitoring-based memory operation schems”。这个机制能让用户告诉DAMON针对某种特殊的access pattern应该采取什么应对措施。这也是通过一个新增的debugfs文件（“schemes”）来配置的，它可以接受这样的输入：

    min-size max-size min-acc max-acc min-age max-age action

针对那些region length在min-size和max-size之间、访问次数在min-acc和max-acc之间的region，就会应用这条规则。这些访问次数统计需要满足积累时间在min-age和max-age之间。region的"age"在每次某个大变动（比如应用了一个action，或者调整了region size）的时候都会被重置。

action，目前来说只是针对此region发起的madvise()系统调用的一个命令，可以是MADV_WILLNEED、MADV_COLD、MADV_PAGEOUT、MADV_HUGEPAGE、MADV_NOHUGEPAGE。举例来说，我们可以利用这种类型的action来明确要求一个很少用到的region被换出（swap out），也可以用它来要求用huge page来存放hot region（热点区域）。对这个patch set进行review时，也有人提出mlock可以作为一个action，不过目前还没有实现进去。

这种机制肯定会对开发者针对自己特有的workload来调试memory-management subsystem有很大帮助。这样也引起了一个有趣的问题：既然kernel可以用来自己tune好参数来达到更好的memory-management效果，那么为什么这不能作为memory-management subsystem本身的一部分呢？像现在这样，把它作为一个单独模块开发出来，对于memory-management开发者来说肯定是很有用的，他们都喜欢尝试各种不同的新想法。不过肯定有人会认为，尽管现在这个调优工作有一个监测系统可以帮助进行了，但是在production system里面，一切应该都一上来就能正常工作，不需要人工参与这些调优工作。所以，DAMON现在看来是个很有用的工具，不过肯定也有不少用户会希望能把DAMON在今后的某一天废弃掉，大家也应该可以理解这些用户的想法吧。

译者注：patch作者sjpark在LWN文后也有回复，一方面提供了更多图片帮助大家理解DAMON的效果，另一方面，针对LWN编辑的问题“为何不能把它放到memory-management subsystem里面去”，他的回答是：“DAMON提供了两种接口，debugfs和tracepoint的接口都是供有root权限的程序，Profiler等使用的。另外还提供了一个kernel代码可编程的接口，用这个接口的话，memory-management subsystem就可以利用DAMON了。”

译者再注：看完全文的朋友的，评一评吧？

全文完

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

欢迎分享、转载及基于现有协议再创作～

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