Linux 内核 DAMON 深度实战：自动化内存访问监控与智能页面调优

1. DAMON 概述：解决内存管理的「盲飞」问题

现代操作系统内核长期以来面临一个根本性困境：内存管理器不知道自己效率如何。传统的页面回收机制（LRU 链表、二次机会法、工作集时钟算法）都建立在启发式假设之上——「过去频繁访问的页面未来仍可能被访问」。然而在实际生产环境中，应用的内存访问模式千变万化，启发式假设经常失效。

DAMON（Data Access MONitor） 是 Linux 内核 5.15 引入的精准数据访问监控框架。不同于粗粒度的手段（如 /proc/smaps 中的定期采样、idle page tracking 的低精度标记），DAMON 以页面级别粒度实时监控内存区域的访问频率，为内核的内存管理决策（包括页面回收、NUMA 平衡、内存压缩）提供精确的访问模式数据。

DAMON 的核心设计哲学可以用一句话概括：用精确数据替代启发式假设。它让内核第一次能够「看」到应用的实际内存行为，从而做出最优的管理决策。

2. 核心架构与工作原理

DAMON 的设计极其精巧，采用了一个两阶段的自适应采样架构，在监控精度和性能开销之间取得了最佳平衡。

2.1 核心抽象：Region 与 Target

DAMON 将监控对象的虚拟地址空间划分为若干连续区间，称为 Region。每个 Region 代表一段连续的虚拟地址范围（[va_start, va_end)）。DAMON 以 Region 为最小单位报告访问信息。

初始状态下，DAMON 将整个地址空间视为一个 Region（或根据预定义方式分区）。随后 DAMON 通过 自适应合并与拆分 动态调整 Region 粒度：

• 拆分（Split）：如果一个 Region 内部访问模式差异显著（部分子区域被频繁访问，另一部分很少被访问），DAMON 将其拆分为两个子 Region 以获取更精确的监控信息。
• 合并（Merge）：如果两个相邻 Region 的访问模式相似，DAMON 将其合并为一个大 Region，以节省监控资源。

2.2 两层采样架构

DAMON 的两层采样设计是其低开销的关键：

第一步：Primitive-based Sampling（基于原语的粗采样）

DAMON 利用处理器硬件的 Address Storage (ADDR) 功能（在 ARM64 上类似 SPE，x86 上利用 Intel PEBS），在每次内存访问发生时硬件自动记录访问的地址到缓冲区。当缓冲区满时，DAMON 收集这些地址并进行初步分类。这一层几乎零开销，完全硬件辅助完成。

第二步：Adaptive Region Adjustment（自适应区域调整）

DAMON 收集到采样地址后，统计每个 Region 的被访问次数。基于这些统计信息：

• 标记每个 Region 的「访问频率得分」
• 决定是否拆分（访问模式不均匀时）
• 决定是否合并（访问模式相似时）
• 输出最终的 Region 访问报告

这两层之间通过一个 Timer-based Aggregation 机制连接。用户可配置采样间隔（sampling interval）、聚合间隔（aggregation interval）和更新间隔（update interval）三个关键参数，共同决定了监控的精度和开销。

3. 三大核心组件

3.1 DAMON Core（核心引擎）

DAMON Core 是整个框架的基础引擎，提供以下能力：

• Region 生命周期管理（创建、拆分、合并、销毁）
• 访问样本的收集与聚合
• Region 访问统计信息的维护
• 向用户态暴露监控结果（通过 debugfs/sysfs）

3.2 DAMOS（DAMON Operation Scheme）

DAMOS 是建立在 DAMON 监控数据之上的 动作执行层。用户定义一组「方案」，每个方案包含：

• Target Regions：识别要操作的目标 Region（基于访问频率阈值）
• Action：对目标 Region 执行的动作
• Quotas：限制动作执行的资源消耗（如最多回收多少页面、最长执行时间）

目前支持的 Action 包括：

• pageout：主动将 Region 中的脏页面写回存储并释放干净页面
• lru_sort：根据 DAMON 提供的访问热度信息调整 LRU 链表中的页面顺序
• lru_deprio：将不活跃 Region 中的页面在 LRU 链表降级（标记为冷页面）
• migrate_hot / migrate_cold：在 NUMA 节点间迁移热/冷页面
• stat：仅统计信息，不执行实际动作

3.3 PADDR 模式

除了基于虚拟地址的监控（DAMON_VADDR），DAMON 还支持 物理地址监控（PADDR） 模式。PADDR 模式直接监控物理页面的访问，无需与进程的虚拟地址空间关联。这对于以下场景至关重要：

• 监控共享内存（多个进程映射同一物理页面）
• 监控系统全局级别的内存访问模式
• 在没有进程上下文的场景下监控（如内核分配的页面）
• 防止进程通过 madvise(MADV_DONTNEED) 欺骗监控

4. 与内存回收子系统的深度集成

DAMON 最重要的应用之一是与内核页面回收机制的深度集成。

4.1 DAMON_LRU_SORT：精准 LRU 排序

CONFIG_DAMON_LRU_SORT 内核配置选项启用了 DAMON 驱动的 LRU 排序功能。这是 DAMON 在生产环境中最广泛部署的应用。

传统的 LRU 机制仅通过页表的 Accessed Bit 粗略判断页面是否被访问。但 Accessed Bit 有以下严重缺陷：

• 只能二元判断（访问过/没访问过），无法区分热页面和温页面
• 在扫描周期内多次访问一次多次访问的效果相同
• 依赖硬件自动清除 Accessed Bit，时序精度差
• 无法处理 访问模式突变（一个之前很热的页面突然不再使用，但 Accessed Bit 仍然置位）

DAMON_LRU_SORT 利用 DAMON 提供的精确访问频率统计信息，将传统的二元 LRU 升级为 多级热度 LRU：

1. DAMON 持续监控各 Region 的访问频率
2. DAMON_LRU_SORT 将页面按照 DAMON 报告的分类：
   • 热页面（Hot）：高频访问 → 保持在 active LRU 列表，永远不会被回收
   • 温页面（Warm）：中频访问 → 在 active 和 inactive 之间正常移动
   • 冷页面（Cold）：极少访问 → 直接放入 inactive LRU 列表尾部，优先被回收
   • 冰冻页面（Frozen）：长期未被访问 → 立即标记为可回收
3. 页面回收器（kswapd）在需要回收页面时，优先从 inactive 列表尾部开始，此时冷页面已被 DAMON 精确排到最前面

实验数据表明，DAMON_LRU_SORT 在 Redis、Memcached 等缓存密集型的应用中，可以将页面回收命中率提升 20-35%，显著减少不必要的页面抖动和性能下降。

4.2 DAMON_RECLAIM：访问感知的自动页面回收

CONFIG_DAMON_RECLAIM 实现了自动化的访问感知页面回收。它直接基于 DAMON 的访问信息决定哪些内存可以主动回收，而不需要等待 kswapd 被动发现内存压力。

DAMON_REclaim 的工作流程：

1. 为每个监控的 Region 持续跟踪访问频率
2. 当系统内存使用率超过用户定义的阈值（如 80%）时触发
3. 识别低于访问频率阈值的 Region
4. 在这些 Region 上执行页面回收操作
5. 通过 quota 机制限制每秒回收的页面数量，避免一次性回收过多导致应用突然变慢

DAMON_RECLAIM 特别适合以下场景：

• 容器内存超量分配：在多租户容器环境中，主动回收低活跃容器的内存给高活跃容器使用
• 数据库缓冲池管理：识别不活跃的缓冲页并优先回收
• 云原生环境的内存弹性管理：根据应用实际使用情况动态调整内存分配

5. 数据结构深度解析

5.1 核心数据结构

DAMON 的核心数据结构如下：

struct damon_region {
    unsigned long start;        // Region 起始虚拟地址
    unsigned long end;          // Region 结束虚拟地址
    unsigned long last_nr_accesses; // 上一聚合周期的访问次数
    unsigned int nr_accesses;   // 当前聚合周期的访问次数（采样密度）
    unsigned int age;           // Region 存活年龄（聚合周期数）
    struct list_head list;      // 链接到 damon_ctx 的 regions 链表
};

struct damon_target {
    pid_t pid;                  // 监控的目标进程 PID（PADDR 模式下为 0）
    struct list_head regions;   // 该 target 的所有 Region 链表
    unsigned long min_nr_regions; // 最小 Region 数量
    unsigned long max_nr_regions; // 最大 Region 数量
};

struct damon_ctx {
    unsigned long sample_interval;     // 采样间隔：连续两次原语采样之间的时间
    unsigned long aggregation_interval; // 聚合间隔：生成一次访问报告的时间
    unsigned long update_interval;     // 更新间隔：调整 Region 粒度的时间
    struct list_head targets;          // 当前监控的所有 target
    struct list_head schemes;          // DAMOS 方案列表
    struct damon_operations *ops;      // 回调函数表
};

5.2 自适应 Region 调整算法

Region 的拆分与合并遵循以下策略：

static void damon_split_region(struct damon_ctx *ctx,
                                struct damon_region *r)
{
    unsigned long sz = r->end - r->start;
    unsigned long sz_region = ALIGN_DOWN(sz / 2, DAMON_MIN_REGION);
    
    // 在 Region 中点拆分为两个子 Region
    struct damon_region *new = damon_create_region(r->start + sz_region, r->end);
    r->end = r->start + sz_region;
    
    // 继承原 Region 的访问统计（按子区域比例分摊）
    new->last_nr_accesses = r->last_nr_accesses * 5 / 10;
    r->last_nr_accesses = r->last_nr_accesses * 5 / 10;
    
    damon_add_region_to_target(new, target);
    damon_add_region_after(r, new); // 将新 Region 插入链表
}

关键参数说明：

• DAMON_MIN_REGION：Region 最小粒度（通常对应 4KB 的倍数），过小的 Region 会导致拆分风暴
• min_nr_regions / max_nr_regions：限制 Region 数量的上下界，防止 Region 数量无限增长
• age 因子：Region 存活时间越长，越不容易被合并

6. 用户态接口与配置

6.1 sysfs 接口（推荐）

Linux 6.12+ 和较新的 LTS 内核通过 sysfs 暴露 DAMON 控制接口：

/sys/kernel/mm/damon/
    admin/
    ├─ kdamonds/          # kdamond 守护线程管理
    │   ├─ nr_kdamonds    # 显示/设置 kdamond 数量
    │   └─ ./0/           # 第 0 个 kdamond 的上下文
    │       ├─ state      # start/stop/pause 控制
    │       ├─ target_ids # 要监控的 target ID
    │       ├─ schemes/   # DAMOS 方案目录
    │       │   └─ ./0/   # 第 0 个方案
    │       │       ├─ access_pattern
    │       │       ├─ action
    │       │       └─ quotas/
    │       └─ monitors/   # 监控目标管理

6.2 配置示例：针对 Redis 实例的 DAMOS 方案

# 创建 1 个 kdamond 线程
echo 1 > /sys/kernel/mm/damon/admin/kdamonds/nr_kdamonds

# 设置 kdamond 监控目标（假设 Redis-server PID 为 12340）
echo "vaddr" > /sys/kernel/mm/damon/admin/kdamonds/0/monitors/0/mode
echo 12340 > /sys/kernel/mm/damon/admin/kdamonds/0/monitors/0/pid

# 配置三个时间参数（单位微秒）
echo 5000    > /sys/kernel/mm/damon/admin/kdamonds/0/sample_interval      # 5ms
echo 100000  > /sys/kernel/mm/damon/admin/kdamonds/0/aggregation_interval # 100ms
echo 1000000 > /sys/kernel/mm/damon/admin/kdamonds/0/update_interval      # 1s

# 配置最多 500 个 Region
echo 500 > /sys/kernel/mm/damon/admin/kdamonds/0/max_nr_regions

# 创建 DAMON_LRU_SORT 方案
mkdir /sys/kernel/mm/damon/admin/kdamonds/0/schemes/0

# 设置访问模式过滤
echo 1    > /sys/kernel/mm/damon/admin/kdamonds/0/schemes/0/access_pattern/sz_min
echo 104857600 > /sys/kernel/mm/damon/admin/kdamonds/0/schemes/0/access_pattern/sz_max
echo 10   > /sys/kernel/mm/damon/admin/kdamonds/0/schemes/0/access_pattern.min_nr_accesses
echo 0    > /sys/kernel/mm/damon/admin/kdamonds/0/schemes/0/access_pattern.max_nr_accesses
echo 100  > /sys/kernel/mm/damon/admin/kdamonds/0/schemes/0/access_pattern.min_age
echo 3600 > /sys/kernel/mm/damon/admin/kdamonds/0/schemes/0/access_pattern.max_age

# 设置动作为 lru_sort
echo "lru_sort" > /sys/kernel/mm/damon/admin/kdamonds/0/schemes/0/action

# 设置配额
mkdir /sys/kernel/mm/damon/admin/kdamonds/0/schemes/0/quotas
echo 2000000  > /sys/kernel/mm/damon/admin/kdamonds/0/schemes/0/quotas/ms
echo 1048576  > /sys/kernel/mm/damon/admin/kdamonds/0/schemes/0/quotas/bytes
echo 1000000  > /sys/kernel/mm/damon/admin/kdamonds/0/schemes/0/quotas/reset_interval

# 启动 DAMON
echo "on" > /sys/kernel/mm/damon/admin/kdamonds/0/state

6.3 debugfs 接口（旧版兼容）

早期 DAMON 版本（Linux 5.15 ~ 6.11）通过 debugfs 暴露接口：

# debugfs 挂载点
/sys/kernel/debug/damon/

# 使用 DAMON 用户态工具
damon assigned 12340 vaddr --sample 5000 --aggr 100000 --up 1000000 --min-regions 10 --max-regions 500
damon start

7. 实战案例：Web 服务器的内存优化

7.1 场景描述

一个 Nginx + PHP-FPM 的 Web 服务器承载着多个业务站点。发现内存使用长期接近上限，kswapd 频繁运行导致响应延迟偶尔飙升。传统手段无法识别哪些 PHP-FPM 子进程的内存可以安全回收。

7.2 DAMON 部署方案

#!/bin/bash
# damon_nginx_optimize.sh

# 1. 找到所有 PHP-FPM 子进程
FHP_PIDS=$(pgrep -f "php-fpm: pool www")

# 2. 启动 DAMON 监控
echo 1 > /sys/kernel/mm/damon/admin/kdamonds/nr_kdamonds

for pid in $FHP_PIDS; do
    MONITOR_IDX=$(echo $pid | md5sum | head -c 8 | tr 'a-f' '0-9' | head -c 4)
    echo $pid > /sys/kernel/mm/damon/admin/kdamonds/0/monitors/$MONITOR_IDX/pid
done

# 3. 配置 DAMOS 方案：对低频访问内存执行 pageout
mkdir -p /sys/kernel/mm/damon/admin/kdamonds/0/schemes/0

echo 1 > /sys/kernel/mm/damon/admin/kdamonds/0/schemes/0/access_pattern/min_nr_accesses
echo 104857600 > /sys/kernel/mm/damon/admin/kdamonds/0/schemes/0/access_pattern/sz_max

echo "pageout" > /sys/kernel/mm/damon/admin/kdamonds/0/schemes/0/action

# 配额限制
echo 5000000  > /sys/kernel/mm/damon/admin/kdamonds/0/schemes/0/quotas/ms
echo 16777216 > /sys/kernel/mm/damon/admin/kdamonds/0/schemes/0/quotas/bytes

echo "on" > /sys/kernel/mm/damon/admin/kdamonds/0/state

echo "DAMON 已启动，监控 $(echo $FHP_PIDS | wc -w) 个 PHP-FPM 进程"

7.3 效果评估

部署 DAMON 后，该场景下的核心指标变化：

8. 进阶：DAMON 与 NUMA 系统协作

在多 NUMA 节点的服务器上，跨节点内存访问的延迟是本地节点访问的 2-3 倍。DAMON 的 NUMA 模式可以提供关键数据。

8.1 NUMA-aware 页面迁移方案

# 监控所有进程的物理地址访问
echo "paddr" > /sys/kernel/mm/damon/admin/kdamonds/0/monitors/0/mode
echo 0 > /sys/kernel/mm/damon/admin/kdamonds/0/monitors/0/pid

# 热页面方案：访问频率 > 100 的页面迁移到 node0
echo 100  > /sys/kernel/mm/damon/admin/kdamonds/0/schemes/0/access_pattern/min_nr_accesses
echo "migrate_hot" > /sys/kernel/mm/damon/admin/kdamonds/0/schemes/0/action
echo 0    > /sys/kernel/mm/damon/admin/kdamonds/0/schemes/0/migrate_hot/target_node
echo 1073741824 > /sys/kernel/mm/damon/admin/kdamonds/0/schemes/0/quotas/bytes

# 冷页面方案：访问频率 < 10 的页面迁移到 node2
echo 0    > /sys/kernel/mm/damon/admin/kdamonds/0/schemes/1/access_pattern/min_nr_accesses
echo 10   > /sys/kernel/mm/damon/admin/kdamonds/0/schemes/1/access_pattern/max_nr_accesses
echo "migrate_cold" > /sys/kernel/mm/damon/admin/kdamonds/0/schemes/1/action
echo 2    > /sys/kernel/mm/damon/admin/kdamonds/0/schemes/1/migrate_cold/target_node
echo 536870912 > /sys/kernel/mm/damon/admin/kdamonds/0/schemes/1/quotas/bytes

9. 性能基准测试

以下是 DAMON 在标准工作负载下的性能影响测试结果（基于 Linux 6.8 内核，双路 AMD EPYC 7713 服务器）：

可以看到，DAMON 的开销极小（可忽略不计），且在某些场景下因为 LRU 排序更精确反而有轻微的性能提升。

10. DAMON vs. 同类技术对比

11. 局限性与发展方向

11.1 已知局限

• 采样偏差：基于硬件采样的 primitive 可能引入偏差
• Region 划分局限：Region 必须连续，无法灵活处理稀疏访问模式
• 初始冷启动：DAMON 需要几个聚合周期才能稳定
• 字符设备/驱动访问：对 O_DIRECT 直接 I/O 访问，DAMON 无法监控
• 内核版本依赖：完整功能需要 Linux 6.7+

11.2 发展方向

• GPU 内存监控：扩展 DAMON 支持监控 GPU VRAM 的访问模式
• CXL 内存分层管理：在 CXL 互连的异构内存系统中辅助决策
• 机器学习辅助：使用简单 ML 模型预测 Region 访问趋势
• 与 io_uring 集成：利用 DAMON 预测即将被访问的页面并提前 page-in

总结

DAMON 是 Linux 内存管理领域近年来最具创新性的突破之一。它用精确的访问数据替代了传统的启发式假设，将内核的内存管理从「盲飞」变为「仪表飞行」。无论是与 LRU 子系统的深度集成（DAMON_LRU_SORT），还是自动化的内存回收（DAMON_RECLAIM），都证明了精准监控数据对系统性能的提升价值。

对于系统工程师而言，DAMON 是解决内存相关性能问题的利器；对于应用开发者，DAMON 提供了一种验证内存访问模式假设的精确工具。随着 CXL 内存和异构计算的发展，DAMON 的应用场景将更加广阔。