巴尔莫斯1. 问题背景与核心挑战
1.1 STALE _mapcount问题的本质
在GPU虚拟内存管理领域，VRAM超量分配（overcommit）是提升资源利用率的重要手段。当GPU显存被完全占用时，TTM（Translation Table Maps）内存管理器需要执行驱逐（evict）操作，将旧的缓冲对象（BO）移出VRAM，为新分配腾出空间。
问题的特殊性出现在SVM（Shared Virtual Memory）场景下。与普通BO不同，SVM BO的VRAM背后关联着ZONE_DEVICE页面（struct page），这些页面通过dev_pagemap机制映射到用户进程的页表中。当TTM直接释放VRAM资源而未将这些页面迁移回系统内存时，被释放的VRAM物理帧号（PFN）会被新BO复用。此时新分配的struct page会检测到_mapcount不是预期的-1（即STALE状态），触发内核告警：
dmesg复制zone_device_page_init: STALE _mapcount=0 on pfn=0x3ffffdc00 (expected -1)
这个问题的严重性在于：
- 它会导致内存状态不一致
- 可能引发后续的内存访问异常
- 在内核日志中产生大量警告信息，影响系统监控
1.2 问题根因深度分析
普通BO的驱逐过程（VRAM→GTT）相对简单，只是移动TTM管理的内存资源，不涉及struct page状态的变化。但SVM BO的特殊性在于：
- VRAM与ZONE_DEVICE页面存在强绑定关系
- 页面的_mapcount、PTE映射等关键状态都挂载在这些PFN上
- 直接释放VRAM会破坏这种绑定关系，导致状态不一致
从内核内存管理角度看，问题的核心在于缺乏一个同步机制，确保在VRAM被重用前，所有相关的页面状态都已被正确清理。这需要我们在TTM内存管理流程中引入新的同步点。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. SVM Eviction Fence设计思想
2.1 基本设计原理
解决这个问题的核心思路是引入SVM Eviction Fence机制。其设计思想借鉴了DMA Fence的概念，但在实现上有其特殊性：
- 同步点插入：在TTM驱逐流程中插入同步点
- **状态清理保障