先把场景摆出来。一台双路服务器，装了 256GB DRAM 加 512GB 持久内存，跑内存数据库。压测一上量，p99 延迟比纯 DRAM 机器差了快三倍。原因不复杂：异构内存访问效率的核心就是热数据别放慢速层，可传统机制根本没法精细地做这件事。市场上有不少用户态方案，但我心里一直有个更顺手的答案——DAMON，Linux 内核原生的数据访问监控机制，它能告诉我们“哪段物理内存、在什么时间段、被访问得多频繁”，再配合 DAMOS 的迁移动作，让热页回到 DRAM、冷页回到持久内存。
这篇博文算是一份完整的实践记录，从 DAMON 的监控原理讲到 sysfs 和 damo 工具的配置，再到异构内存冷热迁移的实验与调参。适合正在做内存分层、NUMA 优化、持久内存或 CXL 内存落地的内核开发者、系统性能工程师。文章里的命令全部基于我手头 6.6 内核环境，版本不同会有差异，我会在容易踩坑的地方专门提醒。
1. 异构内存最头疼的问题：数据放错地方，性能差一大截
1.1 三种内存摆在你面前，监控为什么成了刚需
先看硬件形态。今天的服务器内存早就不止一种了：DRAM 快、贵、容量有限；持久内存（比如 Intel Optane PMEM）延迟高一些，但容量大、能持久化；现在 CXL 内存条也开始进入数据中心。这类系统有个共同点——访问效率很大程度取决于数据放到了哪一层。冷数据放在 DRAM 是浪费，热数据放在慢速层则是灾难。
我简单给个数量级的感受：本地 DRAM 上读一个 4KB 页，延迟大概在 80 到 100 纳秒；同样读 PMEM，延迟可能翻到 200 到 300 纳秒；如果 CPU 在 socket0，数据却落在远端 socket 的 PMEM 上，加上跨 NUMA 的消耗，延迟还会继续恶化。对内存数据库这种负载来说，热数据如果长期留在慢速层，p99 延迟直接崩掉，吞吐也上不去。
那有人会问，能不能一开始就把数据全部放到正确的地方？静态放置方案的问题在于热点是漂移的。业务冷启动阶段可能全热，跑了一小时就凉了；某天发布一个新功能，某条数据线路突然变成瓶颈热点；多租户共享一台机器的时候，谁占哪块内存根本没法提前预测。人工用 numactl 或者 memkind 去指定分配，只适合数据集完全固定、访问模式完全不变化的场景，生产环境撑不住。我们需要的是持续的访问模式监控，加上一个能自动响应热点变化的迁移机制，这就是 DAMON 出场的原因。
1.2 为什么 NUMA balancing 和传统工具不够用
Linux 其实已经有一些“看起来能做这件事”的机制。最容易被提到的就是 NUMA balancing。它的大致逻辑是：当一个进程访问远端内存的比例过高，内核会在后台启动页面迁移，把页面挪回更靠近运行 CPU 的节点。问题在于，NUMA balancing 的定位是解决“CPU 和内存的亲和性”，而不是解决“快慢内存之间的冷热分层”。它的采样走的是微指令采样和稀疏扫描那套路线，控制粒度粗糙，也没有给用户提供“这页到底多热、能持续多久”的可视化数据。
内核 5.16 之后有 memory tiering 和 demotion 机制，思路是把慢速内存当作一个额外的回收层，内存压力高的时候先把冷页降级到慢速节点。但这套逻辑是挂在内存回收路径里的，被动触发，触发条件主要看内存是否紧张，而不是看页面的真实访问频率。换句话说，它适合“内存不够用了，往下挪一点”，不适合“系统还很闲，但我希望主动把热数据提到 DRAM、把冷数据沉下去”这种主动优化。
用户态工具同样尴尬。numactl能控制分配策略，但不能自动发现热点；perf和 eBPF 可以采样访问地址，但要把采样结果整理成连续的物理内存冷热地图，成本高、数据维护复杂。五年前我们只能靠猜，现在能用 DAMON 拿到内核态的结构化信息，并且触发动作也在内核里完成，绕开了用户态的搬运路径。这一步跨过去，整个异构内存分层的玩法就不一样了。
2. DAMON 到底在执行什么：从 accessed bit 到冷热区域
2.1 监控原语：PTE Accessed bit 与最小开销
DAMON 最底层依赖的东西其实很简单：CPU 在访问内存页时，硬件会自动在对应的页表项上置 Accessed 位。DAMON 做的事情就是周期性地检查这个位、把这个位清掉，然后在下一个周期再看一次，以此判断“这段时间里这个页有没有被访问过”。它不需要侵入业务代码，不需要用户态持续采集，完全靠内核页表信息就能工作。
这里有三组核心参数决定了它的行为：
| 参数 | 初始值 | 含义 |
|---|---|---|
| sampling_interval | 5ms | 多久检查一次 Accessed 位 |
| aggregation_interval | 100ms | 把多次采样结果聚合成一个 nr_accesses |
| update_interval | 1s | 多久重新调整一次跟踪的区域划分 |
可以这么理解：sampling_interval决定“看监控屏的频率”，aggregation_interval决定“多久写一份访问报告”，update_interval决定“多久重新画一下热力图网格”。在这套设定下，每个 aggregation 窗口内最多能统计到aggregation / sampling次访问，也就是 20。所以后面配置 scheme 的时候，nr_accesses的取值范围天然是 0 到 20，所谓热阈值设成 15，意思就是“至少 75% 的采样点都发现这个页被访问了”。
DAMON 支持两种跟踪目标：vaddr跟踪指定进程的虚拟地址空间，适合单进程分析；paddr直接跟踪物理地址空间，适合异构内存分层这种全局场景。物理地址监控是我这篇实践的主角，原因很简单——页面迁移操作是以物理页为单位进行的，paddr 模式得到的信息可以直接喂给后面的迁移动作。
2.2 动态区域划分与冷热判定参数
如果 DAMON 对每一个 4KB 页单独记账，64GB 内存就意味着一千六百多万个页面，内核根本扛不住这套审计开销。所以 DAMON 采用了一个非常聪明的近似方案：把地址空间划分成若干连续的 region，每个 region 是一个地址区间，监控的基本单位是这个区间，而不是单独的物理页。
初始状态下，整个目标地址空间就是一个大 region。DAMON 在运行过程中会根据访问模式动态调整 region 边界：一段区域内部的访问频率差异变大，就把它拆开；相邻区域的访问频率变得相似，就合并。min_nr_regions和max_nr_regions控制的是最后收敛出来的 region 数量。默认值通常是 10 到 1000，如果地址空间大、热点碎片化，可以把上限调高到几千甚至上万，但要付出额外 CPU 开销。
这个设计很像图片压缩里的区域编码：平坦区域用大方块表示，剧烈变化的区域才用小块。好处是开销可控，坏处是 region 是一个近似单位——迁移动作执行时是按页走的，但判定“这个页算不算热”是根据它所在的 region 整体访问水平判定的。这意味着 region 如果设得过大，落在 region 边缘的页面很容易被误判。后面调参的时候，这个“近似粒度”是很多困惑的根源。
2.3 不只监控，DAMOS 还能直接执行动作
DAMON 的监控数据本身只是信息，真正让异构内存优化落地的是 DAMOS（DAMON-based Operation Scheme）。一个 scheme 就是一条规则：当某个 region 的访问模式满足指定条件时，内核直接执行对应的动作。
常用的动作包括：
pageout：把页面换出到交换空间。hugepage/nohugepage：尝试合并或者拆分大页。migrate_hot：把访问频率高的页面迁移到更快的内存层。migrate_cold：把访问频率低的页面迁移到更慢的内存层。
后两个动作就是为异构内存定做的。迁移逻辑跑在内核态，直接调用页面迁移路径，比用户态搬数据高效得多。一个完整的 scheme 还能带配额、水位线、过滤器这些限制条件。配额用来防止动作风暴，比如限定一个时间窗口内最多迁移多少页；水位线表示内存压力达到什么程度才执行；过滤器则用来排除不想处理的内存区域，比如内核保留区、某个 cgroup 的页面。监控负责“看”，scheme 负责“做”，这套组合凑齐之后，冷热分层方案才真正可落地。
3. 方案落地的完整链路：监控物理地址、标记冷热、跨层迁移
3.1 硬件拓扑与内核配置检查清单
实验机是双路服务器，每颗 CPU 配 128GB DRAM，持久内存每路 256GB。操作系统把内存识别成四个 NUMA 节点：node0 和 node1 是 DRAM，node2 和 node3 是 PMEM。开机后先确认拓扑：
lscpu | grep -E "NUMA|Model name" ls /sys/devices/system/node/如果 PMEM 是用 App Direct 模式配置的，ls输出里能看到 node2、node3；如果持久内存只是当成块设备挂载，并没有暴露成 NUMA 节点，那 DAMON 的迁移目标就不完整，需要先用 ndctl 把它重新配置成 App Direct 模式，并让内核按 NUMA node 识别。
内核编译选项这一步很多人会忽略。DAMON 不是默认全开的，至少需要这几项：
zcat /proc/config.gz | grep -E "CONFIG_DAMON|CONFIG_MIGRATION|CONFIG_NUMA"建议至少要看到CONFIG_DAMON=y、CONFIG_DAMON_VADDR=y、CONFIG_DAMON_PADDR=y、CONFIG_DAMON_SYSFS=y，另外页迁移相关必须有CONFIG_MIGRATION=y和CONFIG_NUMA=y。发行版内核经常只开了 vaddr 或者干脆没开 DAMON，这种情况就得自编译内核。PADDR 模式尤其重要，因为我们要做的是物理地址空间层面的冷热分层，只开 vaddr 用不了migrate_hot和migrate_cold。
如果实验机上没有真实 PMEM，也不代表方案不能验证。把远端 DRAM 节点当作慢速 tier，跑机制验证完全可行，跨 socket 访问延迟通常比本地高一倍左右，趋势是对的。但要清楚这只是验证功能，性能结论别当生产数据来用。
3.2 DAMON sysfs 与 damo 工具的配置实操
配置 DAMON 有两条路：直接写 sysfs，或者用官方提供的 damo 工具。sysfs 适合脚本化、适合精确控制；damo 适合快速开始、适合调试。先讲 sysfs 的原生流程。
创建 context、指定 paddr 模式、设置三组时间间隔：
echo 1 > /sys/kernel/mm/damon/admin/nr_contexts echo paddr > /sys/kernel/mm/damon/admin/contexts/0/operations # 单位是微秒 echo 5000 > /sys/kernel/mm/damon/admin/contexts/0/sampling_interval echo 100000 > /sys/kernel/mm/damon/admin/contexts/0/aggregation_interval echo 1000000 > /sys/kernel/mm/damon/admin/contexts/0/update_interval # 创建 target，paddr 模式不需要 pid echo 1 > /sys/kernel/mm/damon/admin/contexts/0/targets/nr_targets然后配置两个 scheme，一个负责热迁移，一个负责冷迁移：
echo 2 > /sys/kernel/mm/damon/admin/contexts/0/schemes/nr_schemes # scheme 0：热区迁往 DRAM echo migrate_hot > /sys/kernel/mm/damon/admin/contexts/0/schemes/0/action echo 15 > /sys/kernel/mm/damon/admin/contexts/0/schemes/0/access_pattern/nr_accesses/min echo 20 > /sys/kernel/mm/damon/admin/contexts/0/schemes/0/access_pattern/nr_accesses/max echo 0 > /sys/kernel/mm/damon/admin/contexts/0/schemes/0/access_pattern/age/min echo 18446744073709551615 > /sys/kernel/mm/damon/admin/contexts/0/schemes/0/access_pattern/age/max # scheme 1：冷区迁往 PMEM echo migrate_cold > /sys/kernel/mm/damon/admin/contexts/0/schemes/1/action echo 0 > /sys/kernel/mm/damon/admin/contexts/0/schemes/1/access_pattern/nr_accesses/min echo 2 > /sys/kernel/mm/damon/admin/contexts/0/schemes/1/access_pattern/nr_accesses/max # 启动 echo on > /sys/kernel/mm/damon/admin/kdamonds/0/state需要注意的是access_pattern里的min和max必须同时设置，这是闭区间。age条件表示这个访问模式持续了多少个 aggregation 周期，第一次跑的时候可以把范围放开，先用0到U64_MAX。写脚本之前，一定先ls一下实际存在的路径，不同内核版本的 sysfs 目录结构有小差异，直接照抄容易碰到路径不存在的问题。
更省心的做法是用 damo 工具。安装方式只需要pip install damo，然后：
damo start \ --type paddr \ --sampling_interval 5ms \ --aggregation_interval 100ms \ --update_interval 1s \ --min_nr_regions 10 \ --max_nr_regions 10000 \ --scheme '{"action":"migrate_hot","access_pattern":{"nr_accesses":{"min":"15","max":"20"},"age":{"min":"0","max":"max"},"sz":{"min":"4096","max":"max"}}}' \ --scheme '{"action":"migrate_cold","access_pattern":{"nr_accesses":{"min":"0","max":"2"},"age":{"min":"0","max":"max"},"sz":{"min":"4096","max":"max"}}}' damo status damo stopdamo 配置会自动映射到 sysfs，还能输出更可读的状态报告，调试期我非常推荐先用它。
3.3 迁移方案：谁迁到 DRAM，谁迁到 PMEM
方案的本质就一句话：高频访问的页迁回 DRAM，长期不动的页沉到 PMEM。落成两个 scheme 之后，还要理解迁移动作的内核行为。migrate_hot在执行时会根据页面当前所在节点和系统中其他节点的 NUMA 距离或 memory tier 关系，选择一个更快的目标节点；migrate_cold则相反，会把页往更慢的节点挪。所以理论上你不需要手工指定“迁到 node0”这种目标。但生产环境最好确认一下 memory tiering 信息已经建立，可以看看/sys/devices/system/node/node*/memory_tiers是否存在、DRAM 和 PMEM 是否落在不同的 tier。
我实际的启动流程是先把业务进程用numactl绑在本地 DRAM 节点的 CPU 上，paddr 监控覆盖全物理内存，让 DAMON 自己去判断该往哪儿迁。这里有一个容易忽略的前提：迁移动作的决策依赖 NUMA 距离表，如果你的 PMEM 节点不符合规范的拓扑呈现，比如全部挂在同一个 socket 下，迁移路径的选择就会很别扭。稳妥起见，实验前先确认numactl --hardware输出的节点距离矩阵是合理的。
方案的第二步是考虑过滤器。paddr 模式监控的是整个物理地址空间，里面包含很多不值得迁移的内核保留区。如果内核版本支持，建议把过滤器打开，排除掉不可迁移的页面和内核分配区域，只保留普通用户态页面参与冷热判断。这一步能让监控开销和迁移干扰都大幅下降。damo 的配置里可以直接声明 filter，sysfs 下则要到对应 scheme 的 filters 目录里创建条目。
4. 实测数据与调参过程：一次完整实验
4.1 实验负载与基线数据
我用 Memcached 做负载测试。实验机 DRAM 总容量 64GB，PMEM 256GB，数据集 120GB——这个容量配比很关键，它保证了 DRAM 装不下全部数据，冷热分层才有意义。Memcached 起 8 个实例，用 memtier_benchmark 压测，Key 总量大约 100M，Value 大小 1KB，读写比例 1:9。
首先要跑两个基线。基线一是“所有数据强制落在 PMEM”，用numactl --membind=2,3启动 Memcached，模拟最糟糕的数据放置；基线二是“内核默认行为”，不限制内存分配，让数据自然散落在 DRAM 和 PMEM 上。这两个基线用来回答一个问题：不用 DAMON 的时候，异构内存到底能差多少。
| 配置 | QPS | p99 延迟 | 热数据在 DRAM 的占比（估） |
|---|---|---|---|
| 全 PMEM | 18.5 万 | 2.6ms | 约 0% |
| 内核默认 | 31.2 万 | 1.5ms | 约 40% |
| DAMON 冷热分层 | 48.9 万 | 0.6ms | 约 85% |
表格里的数据是单机环境的示意值，不同硬件、不同负载差异会很大，但趋势是一致的。全 PMEM 那组数据惨不忍睹，主要因为 Memcached 的访问热点相当集中，热数据全在慢速内存上，延迟自然被拉满。内核默认组比全 PMEM 好一些，但缺乏主动迁移，大量热页仍然残留在 PMEM 上，QPS 起不来。
压测命令大致是这样：
memtier_benchmark -s 127.0.0.1 -p 11211 -n 500000 -c 50 -t 8 \ --ratio=1:9 --test-time=120建议每组压测跑三次以上，取中位数。迁移行为有阶段性波动，单次结果非常不稳定，我刚开始跑的时候被一次抖动数据误导过，差点推翻整个结论。
4.2 开启 DAMON 后的冷热分布与迁移统计
启动 DAMON 和两个 scheme 之后，我第一时间想确认的是监控数据本身是否可靠。用 damo 的 report 功能可以直接看到 region 分布：
damo report --type record | head输出会列出地址区间和对应的nr_accesses。我看到的典型特征是：一部分大 region 的 nr_accesses 长时间在 18 以上，另一部分区域则长期是 0，中间层不多。这说明 Memcached 数据的热度确实高度集中，DAMON 的 region 划分基本能抓住冷热边界。
迁移是否真的发生，看全局计数器最直接：
grep -E "pgmigrate" /proc/vmstat对比 DAMON 启动前后的数值，pgmigrate_success出现了明显增长。更细的维度可以分节点看：
cat /sys/devices/system/node/node0/vmstat/numa_pages_migrated cat /sys/devices/system/node/node3/vmstat/numa_pages_migratedDRAM 节点的迁移计数在增加，PMEM 节点的计数也在增加，对应热页迁入、冷页迁出两个方向。我还留意了业务延迟曲线，DAMON 生效后的第一个 aggregation 窗口内就有迁移发生，压测进行到一分钟左右 p99 稳定在 0.6ms。这个响应速度对一个内存数据库来说是完全可以接受的。
有个细节值得单独说：第一次跑的时候我担心迁移风暴把系统拖垮，量了一下top -H里的 kdamond 线程，CPU 占用不到 1%，后来给 scheme 加上配额之后行为更可控。迁移开销本身是真实存在的，但远没有想象中可怕。
4.3 被访问率阈值与区域大小怎么调
调参测试我做了好几轮。核心变量是 hot阈值、cold阈值、region 上限。直接上结论：
| 参数组合 | 现象 | 结论 |
|---|---|---|
| hot>=15, cold<=2, max_regions=1000 | QPS 上升明显，迁移量适中 | 推荐作为初始值 |
| hot>=6, cold<=1, max_regions=5000 | 迁移量暴增，延迟抖 | 阈值太宽，页面振荡 |
| hot>=18, cold<=1, max_regions=10000 | 冷数据仍占 DRAM，收益下降 | hot 阈值过严 |
| hot>=15, cold<=2, max_regions=100000 | 监控 CPU 占用到 3% 以上 | region 数量失控 |
推荐起点是：sampling_interval 5ms、aggregation_interval 100ms、update_interval 1s、min_nr_regions 10、max_nr_regions 10000、hot 阈值 15、cold 阈值 2。这套参数下，迁移响应时间大约在百毫秒量级，足够跟上绝大多数业务热点变化。
用聚合窗口可以推导响应时间：一个 aggregation 周期结束，DAMON 才有一次完整的 nr_accesses 报告，scheme 才会触发下一次评估，所以热点产生到迁移落地的延迟约等于 aggregation_interval，再加上迁移本身消耗的几十微秒到几毫秒。如果业务热点变化非常快，可以把 aggregation 缩到 50ms，但要注意 nr_accesses 最大值会从 20 变成 10，阈值必须按比例调整，不能照搬原来的 15。
我真正想强调的是一个工作方法：不要靠直觉设阈值。先跑一段纯监控模式，不挂任何迁移动作，让 DAMON 跑上十几分钟，然后用 damo 的 report 看 nr_accesses 的分布曲线。分布里如果有明显的双峰，阈值就应该放在峰谷之间；如果热点分布很均匀，说明负载本身不适合冷热分层，硬上迁移收益也有限。这套流程能省掉大量试错时间。
5. 这套方案背后的坑：迁移振荡、监控开销与兼容性
5.1 迁移来回“打架”：热冷阈值之间必须留死区
第一次调参时我犯过一个典型错误：把 hot 阈值设成 6，cold 阈值设成 1，结果页面在 DRAM 和 PMEM 之间反复横跳。现象很直观，pgmigrate_success暴涨到几十万，业务 p99 不降反升，整个系统的迁移路径成了新的瓶颈。
原因在于访问模式有抖动。同一页在这个窗口统计到 6 次访问，下个窗口可能只有 3 次；如果 hot 和 cold 阈值之间没有间隔，页面就会在相邻周期里不断被判定成“该迁过去”和“该迁回来”。迁移本身是写拷贝操作，不是免费的，来回搬几次，性能和带宽都浪费在搬数据上了。
正确的做法是留死区。hot 阈值和 cold 阈值之间拉开一个区间，比如 hot>=15、cold<=2，那么 nr_accesses 在 3 到 14 之间的页面不会被任何 scheme 触碰。这些页属于“中等热度”，就让它们待在当前位置别动。死区宽度到底设多少，最好结合访问分布来定。如果分布有清晰的峰谷，死区放在峰谷处最合适；分布不明显时，宁可保守一点，把死区留大。
此外还可以用 DAMON 的 quotas 做二次保险。给每个 scheme 设置一个单位时间内的迁移页数量上限，比如每 100ms 最多迁移 2000 页。这样即使某次判断出了偏差，迁移量也被限制住了，不会瞬间打爆内存带宽。
5.2 监控开销不是闹着玩的：采样间隔与 region 上限是核心旋钮
DAMON 的 CPU 开销主要来自每次 sampling 对 region 内的页表项做扫描和清位。region 越多、监控范围越大，成本越高。我实测的数据是这样的：max_regions 为 1000 的时候，kdamond 线程占用约 0.3%；调到 10000，占用约 1%；再往上到 100000，直接到 3% 以上。业务高峰期多花 3% 的 CPU，很多团队是接受不了的。
观察 kdamond 开销可以直接用：
top -H -p $(pgrep -f kdamond)这里给三条经验。第一，region 上限不要随意开大，10000 对绝大多数场景足够了；除非你明确知道热点非常碎片化，否则不要碰 100000。第二，sampling_interval 不要低于 1ms，低于这个值页表扫描频率太恐怖，DAMON 会从“监控者”变成“性能杀手”；5ms 是多数业务的安全起点。第三，paddr 模式监控整个物理内存时，一定配合过滤器把内核保留区、不可迁移页排除掉，否则监控预算都在处理无价值的内存区域。
如果在生产环境部署，我的建议是先跑一小时纯监控模式，只收集数据不做迁移，用这组数据估算 DAMON 的实际开销和各区域 nr_accesses 的分布，再把迁移动作挂上去。先把 overhead 摸清楚，再谈优化收益。
5.3 版本兼容性：migrate_hot/migrate_cold 的出现时间与必要条件
DAMON 在 5.15 进入主线，DAMOS 从 5.16 开始可用。但migrate_hot和migrate_cold这两个动作是后续补丁才加入的，我用的 6.6 LTS 里没问题，再早的版本很可能只有pageout、hugepage这些动作，没有迁移能力。如果你的内核版本偏老，写了migrate_hot之后大概率会收到参数无效的错误，那一刻先别怀疑配置，先查内核版本。
迁移动作的依赖条件有三个：CONFIG_DAMON_PADDR、CONFIG_MIGRATION、CONFIG_NUMA。其中 PADDR 是最容易被忽视的，因为很多发行版默认只开 vaddr 的编译选项。判断自己内核支不支持，最快的办法是：
zcat /proc/config.gz | grep -E "CONFIG_DAMON|CONFIG_MIGRATION"如果发行版没有/proc/config.gz，就查源码树里的.config，或者干脆用模块方式编一个 DAMON 相关选项。damo 工具本身也要注意版本匹配，旧版 damo 可能不支持新版内核的 quotas、filters、watermarks 接口，尽量用最新 release。
5.4 对比实验要小心：分配策略不能干扰归因
最后说一个实验设计上的坑。我早期跑对比时，机器上有个 cgroup 限制了 DRAM 的使用量，导致“内核默认”那组数据里大量页面被压到 PMEM 上。结果 DAMON 的收益有一部分其实是“cgroup 逼出来的”，而不是 DAMON 主动迁移的功劳。这种混淆会让人对方案效果产生严重误判。
正确的对比流程应该是：固定硬件和 BIOS 设置，压测前sync && echo 3 > /proc/sys/vm/drop_caches，清掉 page cache；用numactl固定 CPU 绑核，避免超线程干扰；把kernel.numa_balancing的设置固定，要么 0 要么 1，别在两组实验之间改；唯一允许变化的变量，就是 DAMON 和两个 scheme 开没开。每一组测试至少跑三次十分钟，结果取中位数。报告性能数据时务必备注内核版本、拓扑结构、负载类型，异构内存场景的数据可比性很弱，不带前提的结论没有参考价值。
如果你的服务器上也有 PMEM 或者 CXL 内存，我建议别急着上复杂的内存分配策略，先按文里的流程把 DAMON 的纯监控跑起来，看看 kdamond 报出来的 nr_accesses 分布，再决定你的 hot 和 cold 阈值怎么设。对我来说，这比任何纸上谈兵的方案都可靠——内存到底冷还是热，只有数据访问本身最清楚。
