LWN：2026 年 DAMON 更新进展

作者： Jonathan Corbet ，2026 年 5 月 8 日 

LSFMM+BPF 

内核的 DAMON （数据访问监视器，Data Access MONitor）子系统提供了对系统内存的用户空间 (user space) 监控与管理。DAMON 正在迅速发展，因此关于其进展的更新已成为年度 Linux 存储、文件系统、内存管理与 BPF 峰会 (Linux Storage, Filesystem, Memory Management, and BPF Summit, LSFMM+BPF) 的常规项目。这一传统在 2026 年的聚会上得以延续，DAMON 的创始人 SeongJae Park 带来了一份更新，涵盖了该子系统正在添加的一系列新功能——分层 (tiering)、数据属性监控 (data attributes monitoring)、透明大页 (transparent huge pages) 等。 

Park 开始介绍道，DAMON 是一个提供高效监控和内存管理操作的内核子系统。其核心是派生一个内核线程 (kernel thread)，每隔 5 毫秒对内存访问进行采样。结果被合并为数据，每隔 100 毫秒返回给用户空间，当然，这些间隔可以手动或自动调节。返回的访问信息描述了内存操作的位置、稳定性和频率。该系统的设计目标是既准确又轻量，并且既可调节又具备自动调节能力。在一个典型的系统上，它带来的性能开销不到 0.1%。该子系统最初在 5.15 内核版本中合并；目前在许多发行版内核中都已启用。 

Park 表示，DAMON 的“第二张面孔”是 DAMOS (基于 DAMON 的操作方案，DAMON-based Operation Schemes) 机制，它提供了改变内存管理方式的操作。例如，操作可以根据使用模式强制换出冷内存，或者在层级之间迁移内存。更多信息可以在 DAMON 网站上找到。 

Tiering (分层)

在 2025 年峰会上，Park 说他描述了  damos_migrate  操作，该操作已在 6.11 版本中合并。这些操作促进了页面在系统 RAM 和 CXL (Compute Express Link) 连接内存之间的移动——换句话说，就是内存分层。TPP-DAMON（其中“TPP”代表“透明页面放置”，transparent page placement）的工作正在进行中，它能够自动调节阈值以产生较高的 RAM 利用率。分层工作仍在继续，但事实证明单线程对于该任务来说太慢了。因此，TPP-DAMON 已转向多线程模型。它在 llama.cpp 基准测试中能够产生 94% 的性能提升。TPP-DAMON 在 6.16 中合并，6.19 中添加了控制组 (control-group，即 cgroup) 感知。不过，开发工作已经转移到了其他地方，因此 TPP-DAMON 已经进入了支持模式 (support mode)。 

damos_migrate  操作已扩展为支持动态交织 (dynamic interleaving)，其中一些热点内存被放置在（速度较慢的）CXL 内存中，以最大限度地提高内存带宽的整体利用率。它可以支持多个目标节点，每个节点都有自己的权重，但仅在虚拟地址空间中工作。此功能在某个未命名的基准测试中可以产生 25% 的加速；它在 6.17 中合并。 

交织的自动调节仍在进行中；它在物理地址空间中工作。它可以请求页面迁移，目标是维持给定的内存压力水平，或者将特定比例的热页面放置在 CXL 内存中。此功能已在 7.1-rc1 版本中合并。 

与此同时，之前投入到 TPP-DAMON 的精力现在集中在 NUMA-TPP-DAMON 上，这是基于这样一种观察：分层归根结底只是 NUMA (非统一内存访问，Non-Uniform Memory Access) 放置的一个特例。在新的模型中，系统有一组内存访问器（CPU、GPU 或其他访问内存的设备），以及一组可用于内存的提升路径 (promotion paths)。他说，概念已经有了，但这项工作仍处于头脑风暴阶段。 

Davidlohr Bueso 询问使用 NUMA-TPP-DAMON 是否需要禁用 NUMA 平衡 (NUMA balancing)；Park 表示不需要。Bueso 对不同层在内存放置决策上互相冲突表示担忧，但 Park 认为可以通过仔细设定目标来避免这种情况。 

Data attributes monitoring (数据属性监控)

他说，去年开发人员开始研究页级属性监控，旨在回答诸如给定区域中有多少字节由大页支持或计入给定控制组之类的问题。这种监控已经实现，但开销很高。该功能已经得到改进，在 6.15 中引入了许多重要的修复，但开销问题仍然存在。 

目前正在启动一个新的数据属性监控项目，目标是支持全集群监控 (fleet-wide monitoring) 等用例。它实现了一个基于采样的页级监控器，用户可以注册探测点 (probes) 来缩小感兴趣的页面集。每个探测点根据类型（匿名 (anonymous) 或文件支持 (file-backed)）、控制组归属、空闲 (idleness) 等属性对页面进行过滤。这些探测点可以充当 DAMOS 过滤器。 

事实证明，该系统轻量且可扩展，使用了现有的访问采样逻辑。不过，它的准确性是“值得商榷”的，取决于多个与工作负载相关的因素。他说，如果相关的开销可以接受，可以使用页级监控来获取更准确的信息。 

他说，数据属性监控补丁集 (patch set) 的第一个版本已经在邮件列表中，可能很快就会宣布就绪。目前，主要功能是监控匿名状态，但未来的计划更为宏大。意图是将数据访问转变为另一个可以监控的属性，并添加一个可以作用于该属性的  pg_idle  DAMON 过滤器。DAMON 将支持基于属性的区域拆分和合并。将会有更丰富的访问检查原语 (access-check primitives)，并带有针对来自页错误 (page faults) 或系统的性能监控单元 (Performance Monitoring Unit, PMU) 数据的过滤器。此功能最终可能成为 NUMA-TPP-DAMON 工作的基础。 

监控来自其他来源的数据是一个活跃的考虑领域。Park 希望能够以多种方式对数据访问进行分类，包括来源 NUMA 节点、控制组或线程。这些数据将有助于编写感知缓存的  sched_ext  CPU 调度器；对于 NUMA-TPP-DAMON 也会很有帮助。例如，它可以用来发现写操作最少的虚拟机，这通常是最容易进行热迁移 (live-migration) 的目标。 

目前，DAMON 使用页面空闲位 (page-idle bit) 进行访问检查；产生的数据缺乏关于谁访问了内存或进行了何种类型访问的信息。为了获得更好的数据，他希望引入来自其他来源的事件，包括页错误处理程序和 PMU。例如，NUMA 子系统现在收集关于哪些节点正在访问页面的数据；目前存在一个“原型黑客手段 (prototype hack)”将这些数据输入 DAMON。但这种对数据的使用干扰了原始的 NUMA 平衡意图，这不是预期的结果。 

因此，Park 说，下一个重要步骤是清理 NUMA 提示 (NUMA-hinting) 代码；这应该在尝试任何扩展之前发生。但对于 DAMON 和 NUMA 提示之间的干扰仍会有所担忧。由于两者都将使用页面空闲位，每一方都会“测量”由另一方引起的错误。解决该问题的一种方法是使 NUMA 提示和 DAMON 互斥，这样内核中只能构建其中一个；这是一个简单但缺乏灵活性的方法，并且会使发行版陷入必须决定启用哪项功能的困难境地。 

另一种选择是运行时隔离 (run-time isolation)，即在任何给定时间只能激活这两个功能中的一个。这是一个干净且灵活的解决方案，但实现起来相对困难。部分隔离是另一种方法，在从一个子系统过渡到另一个子系统的过程中，页面标记将保持原位。这将使过渡更快，代价是会使数据变得有些模糊。或者，Park 说，可以干脆允许这两个子系统相互干扰；这是否会导致真正的问题尚不清楚。DAMON 应该能够处理这种干扰。同时使用这两个子系统的情况会很少见，所以也许整个问题可以被直接忽略。Kiryl Shutsemau 指出，由于 NUMA 平衡使用采样，丢失一些信息不一定是大问题。 

Park 的建议是，一旦完成必要的清理工作，第一个实现要么使用编译时隔离 (build-time isolation)，要么直接忽略该问题。 

另一个有用的数据来源可能是通过  perf events  子系统获得的 PMU。目前有一些将 PMU 集成到 DAMON 中的 RFC (Request For Comments) 实现正在传阅，  perf  维护者似乎对此想法没有异议。但是，来自 PMU 的数据是硬件特定的，而且在虚拟机内部更难获得有用的数据。因此，这些数据在一般情况下的效用尚不完全清楚。 

DAMON-X

Park 简要讨论了一个他称之为“DAMON-X”的概念，也被称为“开箱即用的 DAMON” (DAMON that just works)。DAMON 为想要手动调节的用户提供了手动调节旋钮 (manual tuning knobs)，并为其他所有人提供自动调节，但每个 DAMON 模块都是独立运行的。Park 正在开发一种解决方案，其中所有模块共享相同的基本监控参数，仅在它们提供的 DAMOS 方案上有所不同。单个上下文可以运行多个方案，用户可以根据意图安装和卸载。在可能的情况下，所有这些都将自动调节并直接工作。预计今年晚些时候将出现一个概念验证 (Proof of Concept, PoC) 实现。 

Access-aware transparent huge pages (感知访问的透明大页)

透明大页 (Transparent Huge Pages, THP) 的优点在于它们可以使程序运行得更快。但它们也会导致内部碎片 (internal fragmentation，即内显碎片) 和内存浪费。用户可以通过  madvise()  对 THP 的使用进行一些控制，但很难提供正确的建议；也许 DAMON 可以提供帮助。 damos_hugepage  模块将跟踪访问模式，并根据内存的使用情况，将基础页合并为大页，或再次将大页拆分。它能够消除一个基准测试中由 THP 引起的 80% 的内存膨胀 (memory bloat)，同时保留 46% 的性能提升。不过，这项工作还处于早期原型阶段，基准测试结果并不稳定。 

Park 希望巩固这项工作，并想知道  damos_hugepage  模块是应该同时负责大页的组装和拆分，还是只负责其中之一。华为的开发人员提出了一种仅限合并的方法，其工作原理是寻找系统上三个 CPU 密集型进程；然后将这些进程的热点内存区域合并为大页。在定义的周期之后，选择一组新的三个进程，然后重新开始该过程。这项工作在基于 MySQL 的工作负载中取得了良好的结果。 

但总的来说，DAMON 是应该将基础页合并为大页，还是将大页重新拆分，亦或是两者兼而有之，目前还是一个悬而未决的问题。运行在  thp=always  模式下的系统可能不需要 DAMON 来创建大页。可以根据需要拆分大页的 THP 收缩器 (THP shrinkers) 已经存在，因此 DAMON 可能也不需要这样做。目前尚不清楚哪组操作是最佳的。 

还有个问题是 THP 原语应该在虚拟地址空间还是物理地址空间中运行。合并一个进程的页面必然涉及在该进程的虚拟地址空间内工作。当然，还有一个选择操作哪个进程的问题；也许这个选择可以留给用户。在虚拟地址空间中工作增加了与 DAMON-X 产生干扰的可能性。相反，拆分操作仅需要访问物理地址，并且不会有此类干扰问题。 

Park 提出的最后一个问题与热度（用于合并）或冷度（用于拆分）程度的阈值设置有关。这些或许可以自动调节，但要正确执行此操作取决于目标是什么。可能的目标可以是给定的大页与基础页的比例，或者是特定的 TLB 未命中 (TLB-miss) 率，尽管后者是硬件特定的。其他可能的目标可以用内存膨胀或压力来表示。 

随着时间耗尽，David Hildenbrand 建议 DAMON 拆分大页可能永远不是一个好主意。当系统组装好一个大页时，尽可能保持其完整是有意义的；如果该页面未被充分利用，那么更好的解决方案可能是将其内容迁移到其他地方的基础页。他还想知道大页的热度如何测量；由于只有一个访问位，无法直接指示任何给定大页中有多少内容被访问。 

LWN 评论概述：

感谢 LWN 提供的这份出色总结！供大家参考，会议使用的幻灯片已发布在 https://github.com/damonitor/talks/tree/master/2026/lsfmmbpf 。 

另一位评论者希望能澄清这一子系统将如何与  /usr/bin/numad  交互（或取代它）。 

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