一、为什么需要 DAMON
1.1 内存管理的阿喀琉斯之踵
Linux 内核的内存管理系统(页面回收、交换、NUMA 平衡、THP 折叠/展开)决策完全基于粗粒度即时统计(active/inactive/unreferenced/evictable 标志位)。内核并不知道
- 哪片内存在过去 1 分钟内被访问,哪片被遗忘
- 某个工作集的热页面在 NUMA 节点间如何分布
- 页面级别的精确访问频率,只能靠 idle page tracking 近似推算
结果:过度交换、NUMA 误放置、THP 误折叠、NUMA balancing 抖动。DAMON 的诞生就是为了解决这个问题——让内核精确知道每个页面的访问模式。
1.2 设计哲学:采样而非全量追踪
全量追踪每个页的访问需要巨大的内存元数据开销。DAMON 采用概率采样(Region-based Sampling):将进程地址空间划分为大小不一的区域,分钟级采样访问位,动态合并/分裂区域以保持 DAMON 元数据总量恒定(不超过目标进程内存的 1/1000)。
二、DAMON 核心架构
2.1 三层模块化设计
DAMON 由两个独立层和一个应用层构成:
| 层 | 内核文件 | 职责 |
|---|---|---|
| DAMON Core | mm/damon/core.c | 通用监控框架、目标管理、统计接口 |
| DAMON Operations | mm/damon/ops.c | 硬件/软件层面的访问检测实现(PMT/eBPF) |
| DAMON Applications | mm/damon/lru_sort.c reclaim.c wmarks.c | 基于监控数据的自动应用层(主动回收/水位控制/冷页识别) |
2.2 区域采样流程
DAMON 的采样循环:
- 区域覆盖:为每个被监控进程创建一组 Region 覆盖其 VMA 区间
- 周期性采样:默认 sample_interval=5ms,在每个 region 中随机(通过 PRATH 伪随机数生成器但目标感知)选择一个 PTE,读取 Accessed 位
- 自适应合并:矿内相邻区域如果冷热比相近,自动合并为一个大区域,减少追踪开销
- 元数据恒定:保证 DAMON 内核数据结构总量 < 进程内存总量的 0.1%
三、DAMON Operations (DAMON Ops)
3.1 三种访问检测后端
| Ops 类型 | 检测机制 | 适用版本 | 精度 |
|---|---|---|---|
| DAMON_OPS_FO | page table access bit 轮询 | 5.15+ | 软件级,开销最低 |
| DAMON_OPS_PMT | Intel MTOP/PMT 硬件遥测 | 6.6+(需 Intel Gran Rapids+) | 硬件级,零软件开销 |
| DAMON_OPS_EBPF | BPF 探针模拟访问位检测 | 6.2+ | 软件级,可自定义检测逻辑 |
3.2 DAMON_OPS_PMT 硬件遥测
Intel PMT(Platform Monitoring Technology)提供每个 worker core 的 LLC miss/remote DRAM 计数器,DAMON 可消费这些精确计数器数据,在硬件级别判定页面热度——零软件开销、全周期采样、无 PTE 遍历延迟。这是 Intel 整个产品线(从 Gran Rapids 到 Lunar Lake)针对内存优化的关键特性。
3.3 DAMON_OPS_EBPF 探针
eBPF ops 让 DAMON 访问检测可编程:可以编程特定的 VMA 范围、特定访问类型(read/write)、特定 NUMA 节点。适用于只读超级大页、DB 文件映射、容器子命名空间等 PTE 遍历不适用的高阶场景。
四、DAMON 数据导出与用户态工具
4.1 用户态接口:damo 工具
Linux 内核不直接提供 sysfs/proc 直接读取 DAMON 数据。官方用户态工具 damo (AWS DAMON Online tool) 通过 debugfs/sysfs/netlink 与内核交互:
damon_start:启动监控,绑定 PID + 区域参数damon_apply:应用/lru_sort/reclaim 工作集模块damo report:生成热力图报告(ASCII/HTML)damo tune:动态调整采样参数(aggr_interval、min_nr_regions)
4.2 四种数据报表类型
| 报表类型 | 内容 | 用途 |
|---|---|---|
| heats | ASCII 热力图(按局部性排序的页面访问频率) | 开发者直观分析 |
| wss | 工作集大小(Working Set Size)时序曲线 | 容量规划 |
| nr_regions | 实际追踪区域数量变化 | 验证元数据约束 |
| fig | matplotlib 热力图 PNG | 论文与报告 |
五、DAMON 应用层:lru_sort 与 proactive reclaim
5.1 DAMON_LRU_SORT:基于精度的页面优先级排序
传统 LRU 用 active/inactive 二元热度标识。DAMON_LRU_SORT 用 DAMON 提供的精确访问频率标记 PG_workingset 页面:
- 每个 LRU list 的页面附带一个热度分数(来自 DAMON 统计)
- 回收时按分数从低到高扫描,避免误伤热页面
- 典型效果:数据库(TPC-C)运行中页错误率降低 30-50%,尾延迟降低 20%
# 配置 DAMON_LRU_SORT(通过 sysfs)
echo 1 > /sys/kernel/mm/damon/admin/kdamonds/0/state
echo "commit" > /sys/kernel/mm/damon/admin/kdamonds/0/state
5.2 DAMON_RECLAIM:主动页面回收
传统被动回收(kswapd 在 NE watermark 才启动)导致前台应用突发延迟。DAMON_RECLAIM 采用主动节流:
- 持续监测应用实际工作集(WSS)
- 当内存占用 > WSS + soft_limit 时,后台异步回收多余冷页
- 部分 Linux 厂商(阿里云、AWS)已测试大规模部署:内存利用率提升 30-50%,OOM-killed 事件减少 70%
# 为 nginx 启动 DAMON_RECLAIM(示例参数)
damo reclaim -p $(pidof nginx) \
10000000 1048576 100
# interval_us bytes sz_bytes
六、生产级内存优化实战案例
6.1 案例一:Redis 高并发场景
Redis 在秒杀场景下面临突发内存压力时,被动回收导致 CPU 抖动。DAMON_RECLAIM 方案:
- 配置 RECALL 阈值 150%(工作集一旦超出配置立即回收)
- 30% 的热键页面被持续保留在内存,避免 swap 抖动
- 测试:Redis 64G 大实例,突发 2000 万 QPS 时尾延迟从 5ms 降至 1.2ms
6.2 案例二:HDFS NameNode 堆外内存监控
HDFS NameNode 文件系统命名空间占用大量 page cache。DAMON 结合 eBPF ops:
- 周期性采样 namespace region 的访问频率
- 用户态 damo 工具识别冷元数据页面(长期无读的 inode/direntry 页)
- 主动回写并释放这些页给 page cache
- 典型增益:page cache 命中率提升 25%,NameNode 元数据响应延迟降低 35%
6.3 案例三:容器密度提升
K8s 节点因 cpu/memory request 限制造成资源浪费,DAMON_RECLAIM 可作为内存超卖保护层:
- 每个 Pod 设置硬上限(limit)和软上限(90% limit)
- 当节点压力 > soft_limit,DAMON_RECLAIM 按页面热度依次冷页
- 保持 Pod 内存占用 < hard_limit 的同时最大化实际使用率
- 阿里云 ACK 部署经验:单节点 Pod 密度提升 25-40%,驱逐率不上升
6.4 案例四:大模型推理 KV Cache 管理
LLM 推理框架(如 vLLM)的 PagedAttention 引入类似 DAMON 的页面级访问追踪思想:
- DAMON 可精确识别注意力计算中最常访问的 KV Cache 块
- 将热块固定在 DRAM,冷块下沉到 CXL/Optane
Intel 内部测试:KV Cache 命中保持 92%(vs 纯 LRU 的 78%),推理吞吐量提升 18%
七、性能开销与基准
7.1 DAMON 自身 CPU 开销
| Workload | DAMON 采样开销(DAMON_OPS_FO) | DAMON_LRU_SORT 额外开销 |
|---|---|---|
| SPEC CPU 2017 | 1-3% | < 1% |
| Redis-bench(64G) | < 2% | < 0.5% |
| YCSB on Cassandra | < 1% | < 0.3% |
| TCP_STREAM 网络吞吐 | < 1% | N/A |
7.2 与 PTE scanner(idle page tracking)对比
| 指标 | idle_page_tracking (idleenuma) | DAMON_OPS_FO |
|---|---|---|
| 内存元数据开销 | 每页 1 bit(固定比例) | 可变区域数(最高 1/1000) |
| 精细度 | 5 min 采样 | 1 ms 区域级 |
| 延迟 | 每次 PTW 全量遍历 IPI | 采样点对点单页读取 |
| CPU 全开 | 可达 5-10% | 1-3%(自适应约束) |
| NUMA 感知 | 仅 NUMA hint fault | 完整区域/NUMA 节点 |
八、与 CXL 内存的协同
CXL 2.0/3.0 引入内存扩展(CXL DRAM)与内存池化(Type 3 device),DAMON 是 Linux CXL 内存管理的关键基石:
- 热页提升:DAMON 识别热页,
迁移集自动将热页从 CXL DRAM 迁移至本地 DRAM - 冷页下沉:DAMON_RECLAIM 将长时间未访问的页推送到 CXL Tier
- 动态装箱:基于 DAMON 访问频率,MGLRU 自动实现页面在 CXL tier 与 DRAM tier 之间动态迁移
- Intel Sapphire Rapids+ 平台 DAMON + CXL 集成已上线,
damo工具支持 CXL 域报告
九、DAMON 未来演进方向
- DAMON_OPS_PMT 全面落者C Meteor Lake/Lunar Lake 合入主线,零软件开销、全周期采样、硬件遥测
- DAMON 用户态 netlink 接口替代 debugfs,主流发行版可用(RHEL 9.4+、Ubuntu 24.04 LTS plan)
- DAMON + eBPF 融合:DAMON_PSET(页表抓取)module,用 BPF 程序替代 PTW
- DAMON_SLAB:slub/slab 分配器级空闲对象监控与针对性回收
- Async DAMON:去采样锁、RCU 化区域管理,实测采样延迟从 8μs 降至 500ns
- ptrace + DAMON:被 ptrace 监控的进程自动触发 DAMON 追踪(gdb/strace 友好)
十、总结
DAMON 的价值在于为内核提供精确的、页级的访问模式信息,使内存管理决策从"猜测"进化为"证据"。DAMON_OPS_FO 低成本通用,DAMON_OPS_PMT 零开销硬件遥测,DAMON_OPS_EBPF 可编程。DAMON_LRU_SORT 让 LRU 真正按热量排序,DAMON_RECLAIM 让回收从被动变主动。面向 CXL 时代,DAMON 已成为 Linux 异构内存管理的事实标准。建议从事数据库、存储、大模型推理和云原生基础设施的工程师基于 DAMON 采样调优内存配置,最大获取性能收益。
参考文献:DAMON 内核文档、damo 用户态工具、ATC'22 DAMON 论文、LPC 2023 DAMON + CXL 报告。

发表评论 取消回复