让madvise真正驱动GPU内存决策：从用户态意图到内核回收策略

1. 先想清楚：madvise 在传统 CPU 路径里到底干了什么

madvise 系统调用是用户态告诉内核"这段地址空间我希望怎么被对待"的接口。比如MADV_WILLNEED表示接下来要访问，内核会把对应的页提前装入；MADV_DONTNEED表示之后不要了，内核可以直接释放掉对应的物理页（并清空 PTE，但保留 VMA），这两种语义在教科书里都写得很直白。还有一种相对新的MADV_COLD/MADV_PAGEOUT模式，用于主动把冷页下沉到回收池，进一步让用户态参与内存节奏控制。在纯 CPU 的常规情况下，这些建议会被内核 mm 层直接翻译成 page fault 预读、folio 回收或 VMA 状态清理，整个生命周期在内核通用框架里完成。

但问题是，在传统匿名映射或普通文件映射里，驱动几乎没有参与，甚至可以说 madvise 根本不 care 底层是谁。内核走完通用流程，比如zap_page_range、__folio_isolate_lru之类的逻辑，物理页就被释放。对一个没有自定义vm_ops的 VMA 来说，这套流程完全够用。可当一个 VMA 背后是 GPU 驱动管理的内存时，情况就复杂了——这个 VMA 只是整个对象映射的一个面，驱动内部还有 GPU 页表、GPU 内存堆、shrinker、hugepage 策略等一整套东西，用户嘴上说的"我不需要了"，它根本听不到。

这引出了我最近在折腾一个 GPU 驱动项目时遇到的核心问题。这个驱动（内部代号为 xe）允许用户态把一段 GPU buffer bind 到显存地址空间，同时又允许 CPU 直接 mmap 同一个对象。用户程序在业务上有明确的访问意图：有的区域一次写完长期不读，有的区域会被 CPU 和 GPU 轮番访问，有的区域只是临时暂存。但这些意图以前只能靠驱动猜——不管用户怎么设置 madvise，驱动内部对 buffer 的处置策略完全不变。结果就是：一个设置了MADV_DONTNEED的 buffer，驱动依然把它放在 LRU 队首，回收时舍不得淘汰；一个设置了MADV_WILLNEED的 buffer，驱动却因为"怕错"把它降级到了慢速内存。于是我开始思考，怎么才能让这段用户态建议真正影响 GPU 驱动的内部决策。

这篇文章面向对内核内存管理、GPU 驱动开发、系统调优感兴趣的读者。我会从 madvise 的常规语义说起，逐步拆解如何把它翻译成 GPU 驱动能够理解的内存调度信号，并给出我在实际项目中踩过的坑和验证过的思路。如果你正在处理类似的"用户态意图 -> 驱动决策"问题，这篇应该能给你一个可复现的参考框架。

2. 为什么 GPU 驱动的内存决策需要"听到"用户意图

先聊核心原因：决策面不对称。CPU 路径里，madvise 之后紧接着的 page fault 通常很快就会发生，内核有即时反馈。而 GPU buffer 的冷热判断很可能要等好几帧，甚至用户态在 CPU 上已经明确释放了映射，GPU 侧的工作还是按老节奏进行。这种情况下，madvise 就成了少数能跨越"驱动内部状态"这个黑盒的用户态信号。

另一个原因是成本。要判断一段 GPU 内存是不是真的该回收，常见的做法是定期扫描 GPU 页表的使用位，但这要么依赖硬件访问计数器，要么得做一次 GPU 软管协调，代价非常贵。而用户态已经在自己的业务逻辑里完成了类似判断，调用一次 madvise 的成本只有几百纳秒。用几百纳秒的用户态系统调用，换取驱动省掉一整轮 GPU 页表扫描，这个性价比值得动代码。xe 驱动面对的场景更是如此：它以 VM_BIND 机制为核心，用户态可以任意把同一个 GEM object 映射到多个地址空间，每个地址空间都有独立的 GPU 页表。同一块物理内存，在这一侧的地址空间里可能是"暂存只写"，在另一侧可能是"将被反复采样"。如果驱动不能用一种通用方式捕捉用户的 madvise 声明，而只是对全局 buffer 做统一 LRU 管理，那一定会在内存紧张时出现不必要的迁移和回收。

2.1 用户态访问意图是免费的高质量信号

很多同学会觉得，madvise 只是一个"建议"，内核完全可以忽略。但在驱动调优场景里，这种"建议"反而比驱动自己做的启发式预测可靠得多。因为用户不会平白无故对一段匿名映射调MADV_DONTNEED，一定是在某个业务路径里确定性地知道后续不再用这一段。相反，如果驱动自己做"启发式预测"，要么基于访问地址局部性，要么基于某种统计模型，准确率大概率不如用户直接讲出来的话。

当然，madvise 的局限性也很明显：它只能作用于 VMA 上的一个区间，粒度偏粗；它没有优先级的语义，"非常重要"和"最好留着"都只能通过MADV_WILLNEED来表达。所以驱动在把 madvise 转成内部决策时，最好不要直接用二态 bool，而是转成一个有量级的分数，这样后续调度策略才有调整空间。下文会专门讲这个分数如何设计。

2.2 从"建议"到"决策"，中间至少隔了三层

我在设计最初版本时，差点把问题的粒度搞错了。以为只需要在某个 vm_ops 回调里把 madvise 收到的操作记录下来就能影响决策，但忽略了三个关键层次。

• 第一层是系统调用层：内核把用户传来的 madvise 操作统一处理，最终会通过清理或修改相应 VMA 上的 PTE 来体现，操作完并不会通知驱动"我刚刚对一个 VMA 做了一个 madvise 操作"。
• 第二层是VMA 层：VMA 是用户地址空间的描述，驱动可以在 mmap 时塞入自己的 vm_ops，但这些 vm_ops 里并没有 madvise 事件回调。VMA 发生的更细粒度变更，比如 madvise 之后页面变得不再映射，倒是可以通过 mmu_notifier 观察到。
• 第三层是驱动内部层：驱动维护着自己的对象生命周期、GPU 页表映射、内存回收队列，它与 VMA 已经隔了一层。VMA 上的 madvise 信号如果不主动翻译并传给内部内存管理器，它就会在下一步被静默丢弃。

理解了这三层，再看我的实现思路就顺了：不搞"为 madvise 发明一个内核回调"这种事，而是老老实实借助 VMA 的 fault 与 mmu_notifier，把用户意图以驱动能看懂的方式"转发"到驱动内部的 per-object 状态里。这样既能达到目的，又不破坏内核 mm 的通用机制。

3. xe驱动里实现用户意图采集：从系统调用到VMA事件

明确了上面三层，实现路径就清晰了——不需要拦截 do_madvise，只需要在 VMA 和 notifier 侧注册足够的感知点。VMA 让驱动知道"用户这段映射在哪个地址范围被访问/释放"，mmu_notifier 让驱动知道"地址空间这一页已经被 CPU 页表移除了"。两者信息一拼，就能推断：madvise(DONTNEED) 对该 VMA 区间产生了一次"清 PTE"事件，且之后的 fault 事件又没有马上到来——那这段区间大概率是用户冷掉的区域。

当然，严格从内核视角看，一个 VMA 的清 PTE 也可能是 munmap 导致的，不一定是 madvise。所以我的做法是在驱动里把清 PTE 事件记录在案，并不急于下结论，而是等几毫秒或者等到驱动下一次调度触发时再综合判断。munmap 之后 VMA 会消失，但驱动只要在 address_space detached 回调里把状态清掉即可；madvise 之后 VMA 还在，驱动就还能在后续 fault 里把它再标记回来。用"事件 + 状态机"来区分用户意图，比直接试图找 madvise 参数更可靠，而且完全基于现有内核机制。

3.1 需要打点的内核通知点

实际实现里，我至少在三个地方做了埋点。

一是vm_operations_struct里的fault回调。GPU buffer 的 CPU mmap 在首访时会产生 fault，驱动据此可以把相应 VM 区间从"冷态"标记为"热态"。这是接收用户 WILLNEED 意图的天然入口。

二是mmu_notifier_ops里的invalidate_range_start/end回调。当 CPU 侧 PTE 被清掉时，包括 madvise DONTNEED 产生的 zap，这个 notifier 会被调用。我把这个事件当作"用户可能不再需要这段地址上的 CPU 访问能力"的信号。

三是vm_ops->close或split回调。前者用于 VMA 被销毁时清理驱动内部的状态项，后者用于 VMA 区间被拆分时保证 per-interval 状态准确。madvise 在部分区间场景下可能触发 VMA 分裂，因此 split 回调也必须处理。

我把这三个点统称为"用户意图采集层"。它的产物是一张按 VMA 区间索引的状态表，里面记录着每个区间最后一次热事件、最后一次冷事件，以及热事件发生次数。这张表本身是驱动内部内存管理器的输入，不直接决定回收。

3.2 一个最小骨架

为了讲清楚状态机，我贴一段我当时用来验证思路的最小骨架（这里做了简化，只表达核心逻辑，不是某个官方驱动的完整代码）：

struct xe_intent_state { struct mmu_interval_notifier min; /* 监视一段CPU映射 */ unsigned long last_hot_jiffies; unsigned long last_cold_jiffies; unsigned int hot_count; unsigned int cool_down_ms; }; static vm_fault_t xe_vma_fault(struct vm_fault *vmf) { struct xe_intent_state *st = vmf->vma->vm_private_data; st->last_hot_jiffies = jiffies; st->hot_count++; return xe_handle_fault(vmf); } static bool xe_mmu_invalidate(struct mmu_interval_notifier *min, const struct mmu_notifier_range *range, unsigned long cur_seq) { struct xe_intent_state *st = container_of(min, struct xe_intent_state, min); unsigned long last = st->last_hot_jiffies; /* 如果这个范围此前一段时间都没有fault，判断为冷端 */ if (!time_after(jiffies, last + msecs_to_jiffies(st->cool_down_ms))) return true; st->last_cold_jiffies = jiffies; xe_feed_memory_reclaimer(st); /* 把状态喂给驱动内部决策器 */ return true; } static void xe_vma_close(struct vm_area_struct *vma) { struct xe_intent_state *st = vma->vm_private_data; xe_free_intent_state(st); }

fault回调负责捕获 WILLNEED 类意图，invalidate回调负责捕获 DONTNEED 类意图。这里有一个关键参数cool_down_ms，它用来消除短期抖动：用户可能刚 fault 完，下一刹那又调 madvise(DONTNEED)，驱动不该立刻把这块内存降级，而是给它一段冷却窗口，避免频繁状态翻转造成回收器震荡。这段代码本身不复杂，但它揭示了整个采集层的核心设计哲学：用事件驱动状态迁移，而不是试图精确还原 madvise 的每一句话。

3.3 为什么不用 page_fault 和 mmap 的简单堆砌

有人会问：既然有了 fault（热）和 invalidate（冷），直接两个计数不就完事了吗？为什么要搞冷却窗口？我实践下来发现，真实用户程序访问模式远没有教科书干净。比如一个资源加载器，它先 mmap 整块 buffer，然后立刻 madvise(WILLNEED) 预取，驱动如果把这个当成"热"，那没问题；但它又可能在加载完成后对同一段调用 madvise(DONTNEED) 来主动释放 CPU PTE，之后 GPU 工作队列过几帧才真正用到这段数据。

如果驱动在 dontneed 的瞬间就把它判定为冷，然后立刻把对应 GPU 页迁移到慢速内存，等 GPU 命令真正执行时再迁回来，反而制造了比不实现 madvise 更严重的抖动。所以我在内部分了至少四态：活跃热、最近热、冷却中、确定冷。madvise 触发的 invalidate 只把状态从"活跃热/最近热"降到"冷却中"，要连续两次冷事件并间隔超过阈值，才最终变为"确定冷"。这本质上就是给"用户意图"加了一个阻尼器，让驱动不会在一个调度周期内被用户态的抖动带偏。

4. 意图如何变成全局内存决策：优先级分值与回收策略联动

采集层拿到状态之后，真正麻烦的是：怎么让这些意图影响到驱动内部的内存调度？一个 GPU 驱动内部往往有多个内存域：设备本地显存、系统内存、还有可能是一部分可回收的 CPU 页池。对这些内存域，驱动有自己的分配器、回收器和迁移逻辑。如果意图只在 VMA 区间层面打转，是没法指导全局决策的。所以需要有一个"意图分值"的概念，把离散事件映射成一个连续整数，驱动内部内存管理器再以这个分值为参考做排序。

我为每个 GEM 对象维护了一张区间列表，每个区间会累积一个intent_score。这个分数不是简单累加，而是按事件时间衰减：fault 加 N 分，invalidate 减 M 分，衰减系数用指数移动平均。细节不展开，核心是：做大内存回收时，驱动把所有待选对象按这个分数排序，分数最低的先淘汰。这套逻辑放在驱动的shrinker回调里，可以直接参与全局内存压力下的回收，不需要额外用户态介入。

4.1 把建议折算成分数

我给出一个我当时在实验板上用过的映射表，注意这只是参考值，不是标准答案：

这个表第一次出来的时候，团队里有人质疑：为什么不直接 MADV_DONTNEED 就把页释放掉，省得后面再扫描？我解释：GPU 内存释放涉及底层页表 shootdown、fence 等待，成本远高于 CPU 侧释放一个 PTE；如果用户 dontneed 之后几帧又要用，代价是灾难性的。所以宁可让回收器保守一点，也不要让用户态一句"暂时不要"就破坏 GPU 执行流。从最终效果看，这个保守设计是正确的。

4.2 与驱动 shriner 联动

xe 驱动的回收入口并不止一条。一类是全局内存压力触发的shrink_slab回调，另一类是 GPU 内部漫游式回收器。我在两条路径上都挂上了intent_score排序。

在shrink_slab回调里，驱动会先遍历所有绑定到地址空间的 GEM 对象，对每个对象算出一个综合得分：对象的intent_score越低，说明用户最近越不活跃，回收优先级越高。最终回收器从低分到高分开刀；但在真正释放前，还要检查该对象是否有尚未完成的 GPU 命令引用。如果还有 active fence 引用，就跳过。这一步非常关键，否则会产生一个经典 bug：用户态调完 madvise(DONTNEED)，驱动回收了内存，结果 GPU 命令队列里仍然引用旧地址，下一次执行直接 GPU hang。

从实现角度看，shrinker 本意是"能回收多少就回收多少"，但 GPU 场景里必须同时满足"回收可以安全发生"和"回收成本合理"两个约束。intent_score只负责回答"哪个对象回收最合理"，而 fence 检查回答"哪个对象现在真的安全"，两者必须同时通过才算完成决策。

4.3 与 HUGEPAGE 策略的联动

内存决策里还有一个容易被忽略的点：大页策略。GPU 驱动通常会在系统分配时尝试 2MB 对齐的物理页，但这会带来更高的内存占用与碎片压力。如果 madvise 里带了 MADV_HUGEPAGE，驱动可以把这一块的物理页分配偏好调高，反之如果用户没有大页诉求，驱动的分配器就走更保守的 order-0 路径。

同样要考虑时序问题。madvise(HUGEPAGE) 是用户态在 mmap 之后调用的，而驱动的物理页分配往往发生在 GPU bind 的时候。如果 bind 发生在 madvise 之前，这个意图就来不及生效。因此我在驱动里把 HUGEPAGE 意图也作为"分配时提示"存起来，当 GPU bind 接口真正分配物理页时再查一次。某种程度上，这等于把用户意图延迟到真正需要它的决策点前。毕竟用户态的一些设置并不是为了立刻改变当前状态，而是为了改变"下一次资源分配时采用什么策略"，驱动按这个思路去消费它，才能保证意图不丢失在时序缝隙里。

5. 实测效果与踩坑：哪些"用户意图"真的有用

在讲踩坑前，先说我拿到的实测数据，虽然是实验室环境，但方向性已经很明确。实验分三组：第一组完全不调用 madvise，第二组只在加载完成后调 MADV_DONTNEED，第三组则是先 MADV_WILLNEED 预取，运行一段时间后再 DONTNEED。在固定内存压力下跑同一套 GPU 负载：

• 第一组内存回收次数最多，且绝大多数回收都发生在"用户早已确定不再需要"的区域，浪费严重。
• 第二组比第一组好一些，但存在冷却窗口过短带来的脉冲式回迁。
• 第三组整体回收次数最少，性能吞吐波动也最小，说明"WILLNEED + DONTNEED"组合拳确实能帮助驱动避开无用页的扫描。

这个结果算不上多么惊艳，但至少证实了一件事：用户意图这件事，不靠驱动去猜，直接让用户告诉内核，对 GPU 内存决策是有实际帮助的。不过，只要真正跑起来，坑就接着来了。以下是我踩得最深的三条，每条都花了我至少一个晚上。

5.1 MADV_DONTNEED 不等于同步释放

我最初犯的错是：把 invalidate 回调里收到的范围当成"可以立刻回收"。结果立刻触发了我上面提到的 GPU fence 问题。修复的方式是给回收路径增加一个准入门槛：只有当该内存块上的 GPU fence 全部 signal 之后，才允许真正做物理页释放。也就是说，madvise(DONTNEED) 在 GPU 语义里只是"用户已经不关心 CPU 侧访问"，驱动内核还需要配合命令完成状态去定夺。

调试过程中最有用的一个工具是给驱动打印一份简单的状态时间线，把 fault、invalidate、fence signal、实际回收这几类事件拼在一起。一旦发现"invalidate 之后立刻被回收，但时间线上还有未 signal 的 fence"，基本就能确定问题出现在这个门槛缺失上。这种排查方式比单纯在代码里翻逻辑要快得多，因为问题本质是时序错位。

5.2 冷却窗口设太短会让回收器产生抖动

第二处坑是冷却窗口设太短。我在某个早期版本里把它设成 1 毫秒，结果内存在 70% 水位附近来回震荡：刚把一页迁移回慢速区，下一帧 fault 事件又把它拉回热区，反复横跳。后来我把默认值提高到 50 毫秒，并做了一个自适应：如果驱动的热事件频率很高，冷却窗口动态调大；如果长时间静默，则调小。这样测试下来，状态翻转次数降了一个数量级。

这里没有放之四海而皆准的推荐值，它跟你的负载模型、GPU 调度频率、页表扫描周期都密切相关。我的经验是：一开始选一个偏稳妥的大值，再用统计状态翻转次数作为指标去收敛，比一上来就找一个神秘最优值靠谱得多。

5.3 mmu_notifier 回调里的锁不得不注意

第三个坑比较内核化：mmu_interval_notifier的 invalidate 回调运行在 mmap 写锁或其他 folio 锁的上下文中，你在里面做的任何操作都不能去拿一个可能产生递归锁的锁。我最开始天真地在回调里调用了驱动的xe_feed_memory_reclaimer，而这个函数内部会去拿一个全局的 obj_lock；恰好另一个线程持有 obj_lock 在做 GPU bind，且已经在等待 mmu_notifier 完成，于是直接形成 ABBA 死锁。

后来我把回调里真正需要做的工作分成了两部分：回调内只记录事件、标记一个 dirty flag；统一放到驱动的工作队列里，再执行对象状态更新与回收策略调整。这样回调路径变成了纯轻量级通知，不会有锁依赖。这个经验对任何做 GPU 驱动的人都有参考价值——mmu_notifier 回调不是让你做业务操作的地方，它只是一个带时序保证的信号源头。

5.4 I/O-less 场景下的 false positive

还有一个细节容易被忽略：有些用户态程序会为了"清理页表缓存"而对一块几乎从不访问的映射调 MADV_DONTNEED，但后续驱动侧却因为一个十分低频的 GPU 事件又需要读这块内存。这种场景下，如果驱动太相信 DONTNEED 信号，把对应的 GPU 页直接放回系统复用池，那么下一次 GPU 访问就会打一次缺页，产生一次明显的尾部延迟。

我的缓解办法是：在驱动里为这类"低频再访问"场景留下快速恢复路径。如果回收出去的内存是最近刚被 DONTNEED 过的，驱动会把它放入一个专门的小型保留池，而不是直接归还给伙伴系统。保留池容量有限，但在大多数业务场景下足以吸收用户态误报带来的尾巴。这种做法听起来有点浪费，实际却能让整机内存压力测试下的长尾延迟明显变短。

6. 我理解的边界：madvise 等用户意图永远只是"概率建议"

最后想聊一个设计理念层面的事。madvise 在设计上就不是一条命令，它的语义是"建议"，用户态告诉内核一个倾向性判断，但内核可以根据实际情况忽略。驱动在消费这个信号时，应当始终保持同样的姿态：把它当作降低预测成本的特征，而不是当作削减一致性的许可证明。

• MADV_DONTNEED不代表立即释放，更不能因此忽略 GPU fence。
• MADV_WILLNEED不代表必须留在这里，它只提高了一个优先级，真正的迁移决策仍然要以内存压力与访问时延采样为准。
• MADV_HUGEPAGE只是告诉驱动"我喜欢大页"，但如果当前碎片化严重，驱动仍然应该退回普通页。

这种保守姿态还有一个额外的好处：即使某个用户态程序对 madvise 使用完全错误，比如把正在使用的 buffer 标记成 DONTNEED，驱动也不会立刻做破坏性操作，最多是把它降为低优先级，后续访问时再恢复。而如果驱动把建议当命令执行，一点误用就会变成实打实的 GPU 故障。

回到我最初做这套实现的原因：用户态对内存的访问模式，本身就是整个系统中成本最低、最准确的一种提示。传统 CPU 路径里它已经被利用得很充分，而到了 GPU 驱动背景下，因为多了一个"地址空间"层，它很容易被忽略。通过把 madvise 事件采集、意图分值、回收策略联动三层拼起来，xe 驱动的内存管理终于不再是一个只看对象生命周期命令的黑盒子，而是能感知用户真实意图的自适应系统。

这里再分享一个我实际调试时常用的技巧：给驱动加一个 debugfs 接口，把每个 GEM 对象当前的intent_score和状态机字段 dump 出来。当你发现用户态明明调用了 madvise 但驱动内存行为没变化时，第一件事不是去查内核 mm，而是去查这个分数有没有被正确记录。如果分数对了，说明采集层没问题；如果分数一直没变，那大概率是 VMA 或者 notifier 某个回调没注册上。这个排查顺序能帮你省下一整个下午。