1. 问题背景1.1 STALE _mapcount 问题在 VRAM 超量分配overcommit场景下当 GPU VRAM 被占满时TTM 内存管理器需要驱逐evict旧的 BO 来为新的分配腾出空间。问题对于 SVMShared Virtual Memory的 BO其 VRAM 背后关联着 ZONE_DEVICE 页面struct page这些页面通过dev_pagemap机制映射到用户进程的页表中。如果 TTM 直接释放 VRAM 资源而不先将这些页面迁移回系统内存被释放的 VRAM PFN 会被新的 BO 复用导致新分配的struct page发现_mapcount不是预期的 -1STALE 状态引发内核告警zone_device_page_init: STALE _mapcount0 on pfn0x3ffffdc00 (expected -1)1.2 根因普通 BO 的驱逐VRAM → GTT只是移动 TTM 管理的内存资源不涉及struct page状态。但 SVM BO 的 VRAM 与 ZONE_DEVICE 页面绑定——页面的_mapcount、PTE 映射等状态都挂在这些 PFN 上。TTM 不了解 ZONE_DEVICE 页面的存在直接丢弃 VRAM 资源会留下悬空的页面状态。2. 解决方案概述2.1 核心思想在 SVM BO 的dma_resvreservation object上附加一个eviction fence驱逐围栏。利用 dma_fence 的enable_signaling机制在 TTM 真正驱逐前先将 ZONE_DEVICE 页面安全迁移回系统内存然后才允许 TTM 丢弃空的 VRAM 资源。2.2 两个关键配合机制作用Eviction Fence挡在 TTM 驱逐路径上触发迁移工作并延迟驱逐直到迁移完成DISCARDABLE 标志告诉 TTM驱逐时不要搬到 GTT直接丢弃 VRAM 资源因为数据已经由 fence worker 迁移到了系统内存3. 原理详解3.1 dma_fence 的 enable_signaling 机制dma_fence框架提供了一个关键回调enable_signaling当某个消费者如 TTM首次需要等待一个 fence 时框架调用enable_signaling这个回调的设计意图是告诉 fence 的生产者有人在等你了请安排 signal我们利用这个时机调度迁移工作TTM 要驱逐 BO → 发现 BO 的 dma_resv 上有一个未 signaled 的 fence → 调用 dma_fence_enable_sw_signaling() → 触发我们的 enable_signaling 回调 → 回调中调度异步工作项work item → TTM 阻塞等待 fence signal3.2 DISCARDABLE 的含义普通 BO 被 TTM 驱逐时TTM 会将数据从 VRAM 搬到 GTT系统内存中的 GPU 可访问区域。但 SVM BO 不需要这个行为SVM 页面通过 HMM/drm_pagemap 机制管理数据迁移由 eviction worker 通过 SDMA 完成迁移完成后 VRAM 的数据可直接丢弃设置 DISCARDABLE 后TTM 驱逐时直接num_placement 0丢弃 VRAM 资源即可3.3 Eviction Worker 的迁移原理Worker 使用hmm_range_fault(dev_private_ownerNULL)来触发页面迁移dev_private_owner参数的含义hmm_range_fault遍历虚拟地址范围内的每个页面遇到 device-private 页面时比较dev_private_owner与page-pgmap-owner若相同认为是自己的页面直接返回 PFN正常 GPU fault 路径使用这个若不同包括 NULL认为是外部的页面触发migrate_to_ram回调设置dev_private_owner NULL确保所有 device-private 页面都会被迁移回 RAM。迁移通过dev_pagemap框架的migrate_to_ram回调完成hmm_range_fault(ownerNULL) → 遇到 device-private page → 调用 page-pgmap-ops-migrate_to_ram() → drm_pagemap 框架处理迁移流程 → 最终调用 copy_to_ram 回调SDMA 将 VRAM 数据拷贝到系统内存 → 页面状态更新PTE 指向系统内存ZONE_DEVICE 页面被正确释放3.4 临时 MMU Interval Notifierhmm_range_fault()API 要求调用者提供一个mmu_interval_notifier用于序列号机制mmu_interval_read_begin()返回的序列号用于检测 hmm_range_fault 执行期间是否有并发的页表修改失效通知当虚拟地址范围内的页表发生变化时通知注册者Eviction worker 注册一个临时的notifier仅在迁移期间存在。其invalidate回调是空操作返回 true因为这是一次性迁移不需要跟踪后续失效事件。迁移完成后立即移除。4. 完整驱逐流程4.1 阶段一BO 创建时的准备BO 分配时完成以下准备创建 eviction fence记录进程地址空间mm和虚拟地址范围[start, end)创建 VRAM BO设置DISCARDABLE标志将 fence 附加到 BO 的dma_resv上此时 fence 处于unsignaled状态静静地挂在 BO 上等待。4.2 阶段二TTM 驱逐触发当 TTM 需要腾出 VRAM 时TTM 选中某个 SVM BO 进行驱逐发现DISCARDABLE标志设置num_placement 0丢弃模式等待 BO 的dma_resv上的 fences触发 eviction fence 的enable_signalingenable_signaling调度 eviction workerTTM 阻塞等待 fence signal4.3 阶段三Worker 执行迁移Worker 在异步工作线程中执行检查进程是否还存活mmget_not_zero若已退出则跳过迁移注册临时mmu_interval_notifier调用hmm_range_fault(ownerNULL)迁移所有 device-private 页面清理临时 notifier释放 mm 引用Signal fence— 通知 TTM 可以继续4.4 阶段四TTM 完成驱逐收到 fence signal此时所有 ZONE_DEVICE 页面已安全迁移回 RAM丢弃空的 VRAM 资源num_placement 0VRAM 空间归还给 buddy allocator可供新分配使用5. 生命周期管理5.1 Fence 引用计数Fence 的引用来自三方持有者获取时机释放时机svm_bo创建时所有页面迁移回 RAM 后框架回调释放BO 的dma_resv附加到 resv 时TTM 驱逐完成后 resv 清理Workerenable_signaling时获取引用Worker 完成后释放引用Fence 引用归零后释放mm引用mmdropRCU 延迟释放 fence 内存。6. 错误处理原则核心原则无论成功还是失败必须 signal fence。如果不 signalTTM 会永远等待导致整个 GPU 内存管理挂起。场景处理进程已退出跳过迁移直接 signal内存分配失败记录告警直接 signalhmm_range_fault返回-EBUSY重试并发修改导致hmm_range_fault超时或其他错误记录告警直接 signal7. 时序图TTM Fence Worker drm_pagemap │ │ │ │ │ evict BO │ │ │ │──wait on fence────── │ │ │ │ │ enable_signaling │ │ │ │─────────────────────│ │ │ │ schedule_work │ │ │ (blocked) │ │ │ │ │ │ mmget_not_zero │ │ │ │ notifier_insert │ │ │ │ │ │ │ │ hmm_range_fault ───│ │ │ │ (ownerNULL) │ │ │ │ │ migrate_to_ram │ │ │ │ SDMA: VRAM→RAM │ │ │ │ 页面状态更新 │ │ │─────────────────────│ │ │ │ │ │ │ │ notifier_remove │ │ │ │ mmput │ │ │ signal │ │ │ │─────────────────────│ │ │ │ fence_put │ │ │ fence signaled │ │ │ │──────────────────────│ │ │ │ │ │ │ │ discard VRAM resource│ │ │ │ (VRAM 已空, 安全丢弃) │ │ │ ▼ ▼ ▼ ▼