当前位置：首页 > news >正文

第四章：TTM分析: 4.5.1 ttm_device对三大设计目标的实现

news 2026/4/29 11:06:38

2. 统一管理异构内存域

这是ttm_device最基础的职责：将 VRAM、GTT、SYSTEM 等物理上完全不同的内存，纳入统一的管理框架。

2.1 资源管理器数组`man_drv[]`

structttm_resource_manager*man_drv[TTM_NUM_MEM_TYPES];

这是一个按内存域类型索引的指针数组。每种内存类型（由TTM_PL_SYSTEM、TTM_PL_TT、TTM_PL_VRAM等常量标识）对应数组中的一个槽位，指向该域的资源管理器实例。

访问接口简洁明了：

staticinlinestructttm_resource_manager*ttm_manager_type(structttm_device*bdev,intmem_type){returnbdev->man_drv[mem_type];}staticinlinevoidttm_set_driver_manager(structttm_device*bdev,inttype,structttm_resource_manager*manager){bdev->man_drv[type]=manager;}

驱动在初始化时，将各域的管理器注册到对应槽位。例如 amdgpu 会注册 VRAM 域（buddy 分配器）、GTT 域（区间分配器）等。之后 TTM 核心代码通过ttm_manager_type(bdev, mem_type)统一访问，无需关心底层是什么分配策略。

设计意图：一个数组统一所有内存域，上层代码用mem_type索引即可，彻底解耦"内存域的种类"与"内存域的实现"。

2.2 内建的 SYSTEM 域管理器`sysman`

structttm_resource_managersysman;

SYSTEM 域（TTM_PL_SYSTEM）是最基础的内存域——BO 暂存在系统内存中，尚未绑定到任何设备可见的地址空间。由于所有 GPU 设备都需要 SYSTEM 域作为兜底，TTM 将其直接内嵌在ttm_device中，在ttm_device_init()时自动初始化，驱动无需额外注册。

对比：VRAM、GTT 等域的管理器由驱动创建并通过ttm_set_driver_manager()注册，是"可选的、硬件相关的"；而sysman是"必有的、硬件无关的"。

2.3 页池`ttm_pool`

structttm_poolpool;

当 BO 需要系统内存 backing pages 时（即ttm_tt_populate），不直接调用伙伴系统分配，而是优先从设备的页池中获取。页池按页大小（4K、2M、1G）和缓存属性（WC、UC、cached）分桶管理，提供：

分配加速：避免频繁调用alloc_pages和set_memory_*切换缓存属性
统一接口：不管底层是 DMA coherent 内存还是普通页，页池对外接口一致

页池是"统一管理"目标在页级别的体现——不同缓存属性的页，通过同一个池子管理。

2.4 驱动回调：`ttm_tt_create`/`ttm_tt_populate`/`ttm_tt_unpopulate`

ttm_device_funcs中的这组回调定义了系统内存页的生命周期：

structttm_tt*(*ttm_tt_create)(structttm_buffer_object*bo,uint32_tpage_flags);int(*ttm_tt_populate)(structttm_device*bdev,structttm_tt*ttm,structttm_operation_ctx*ctx);void(*ttm_tt_unpopulate)(structttm_device*bdev,structttm_tt*ttm);void(*ttm_tt_destroy)(structttm_device*bdev,structttm_tt*ttm);

TTM 核心只定义"何时"需要创建/填充/释放页（比如 BO 迁移到 TT 域时需要 populate），而"如何"做则交给驱动。这让不同硬件可以定制：

是否使用 huge page
是否需要特殊的 DMA 映射（如 IOMMU bypass）
是否支持加密内存（如 AMD SEV/TMZ）

小结：man_drv[]实现域级统一，pool实现页级统一，ttm_tt_*回调实现行为级统一。三者协同，让驱动只需"注册能力"，而非"重写框架"。

3. 显存动态调度与超配

当应用的显存需求超过物理 VRAM 容量时，TTM 需要自动将不活跃的 BO 驱逐到系统内存，并在需要时迁回。ttm_device中有一组成员专门为此而设。

3.1 LRU 管理基础设施

`lru_lock`— 全局自旋锁

spinlock_tlru_lock;

TTM 的 eviction 策略基于 LRU（Least Recently Used）：最久未被访问的 BO 优先被驱逐。每个ttm_resource_manager内部维护了按优先级分桶的 LRU 链表（lru[TTM_MAX_BO_PRIORITY]），而lru_lock是保护所有这些链表的全局锁。

为什么用全局锁而非 per-manager 锁？因为 eviction 经常涉及跨域操作——从 VRAM 管理器的 LRU 中选出候选 BO，然后迁移到 TT 域。全局锁避免了跨锁死锁问题，代价是锁粒度较粗，但 eviction 本身不是热路径，这个取舍是合理的。

`unevictable`— 不可驱逐链表

structlist_headunevictable;

被 pin 住的 BO（如正在被 GPU 使用的页表 BO）或已被 swap out 的 BO，不应参与 eviction 选择。TTM 将它们从各管理器的 LRU 链表中摘出，挂到unevictable链表上，避免 eviction 扫描时的无效遍历。

这是一个简单但重要的优化：没有它，每次 eviction 都要遍历并跳过大量不可驱逐的 BO。

3.2 驱动回调中的 eviction 策略

ttm_device_funcs中有三个回调共同定义了 eviction 的决策与执行：

bool(*eviction_valuable)(structttm_buffer_object*bo,conststructttm_place*place);void(*evict_flags)(structttm_buffer_object*bo,structttm_placement*placement);int(*move)(structttm_buffer_object*bo,bool evict,structttm_operation_ctx*ctx,structttm_resource*new_mem,structttm_place*hop);

三者的分工形成一条完整的 eviction 决策链：

回调	职责	回答的问题
`eviction_valuable()`	筛选	“这个 BO 值得驱逐吗？”
`evict_flags()`	定向	“驱逐到哪个域？用什么 placement？”
`move()`	执行	“如何把数据搬过去？”

move()还支持multihop：当 BO 无法从 A 域直接迁移到 B 域时（如某些硬件不支持 VRAM→SYSTEM 直接 DMA），驱动可返回-EMULTIHOP并指定一个中间域（如先到 TT），TTM 核心会自动进行两跳迁移。

3.3 延迟删除工作队列`wq`

structworkqueue_struct*wq;

初始化时创建：

bdev->wq=alloc_workqueue("ttm",WQ_MEM_RECLAIM|WQ_HIGHPRI|WQ_UNBOUND,16);

BO 的销毁可能涉及等待 GPU fence 完成，不能在持有锁或中断上下文中阻塞。TTM 将这些延迟删除任务投递到wq，异步完成清理。WQ_MEM_RECLAIM标志确保即使系统内存紧张，工作队列仍能推进——否则 eviction 释放内存的路径本身会因内存不足而死锁。

3.4 Swapout 路径

当系统整体内存压力大时（如 Linux 的 shrinker 触发），TTM 提供两级 swapout：

// 设备级：遍历该设备所有使用 TT 的管理器，尝试将 BO swap 到 shmemintttm_device_swapout(structttm_device*bdev,structttm_operation_ctx*ctx,gfp_tgfp_flags);// 全局级：遍历所有 TTM 设备，轮询 swapoutintttm_global_swapout(structttm_operation_ctx*ctx,gfp_tgfp_flags);

ttm_global_swapout()的实现中有一个细节——成功 swap 后，将当前设备移到全局链表尾部（list_move_tail），实现跨设备的公平轮转，避免某个设备的 BO 被反复驱逐。

此外，swap_notify()回调在 swapout 前通知驱动，让驱动有机会做清理（如释放 GPU 页表映射）。

休眠场景下，ttm_device_prepare_hibernation()会循环调用ttm_device_swapout()直到所有 GTT BO 都被移入 shmem，确保休眠镜像中不包含设备相关的页映射。

小结：lru_lock+unevictable提供数据结构基础，三个 eviction 回调定义策略，wq保障异步执行，swapout 路径应对系统级内存压力。这套机制让 TTM 能够在 VRAM 容量有限的情况下，透明地为应用提供远超物理显存的使用体验。

4. GPU 地址映射支撑

如 4.1 节所述，TTM 不直接操作 GPU 页表，但它为地址映射提供关键的基础设施。ttm_device中有三组成员与此相关。

4.1 VMA 偏移管理`vma_manager`

structdrm_vma_offset_manager*vma_manager;

用户空间要访问 BO，需要通过mmap将其映射到进程地址空间。但多个 BO 不能映射到同一个文件偏移，因此需要一个偏移分配器为每个 BO 分配唯一的虚拟偏移。

drm_vma_offset_manager就是这个分配器。它基于drm_mm（区间分配器）管理一个巨大的虚拟偏移空间。当用户调用mmap时，DRM 核心通过偏移找到对应的 BO，再建立 CPU 页表映射。

ttm_device持有该指针（而非内嵌），因为vma_manager通常由drm_device创建并共享给 TTM，体现了 GEM 与 TTM 的协作关系。

4.2 CPU 映射失效`dev_mapping`

structaddress_space*dev_mapping;

当 BO 发生迁移（如从 VRAM 迁到 TT），其物理地址改变了，但用户空间可能仍持有旧的 CPU 映射（通过 mmap 建立的 PTE 指向旧 VRAM 地址）。如果不处理，CPU 会访问到错误的物理地址。

dev_mapping指向设备的address_space，TTM 在 BO 迁移时调用unmap_mapping_range()批量失效该 BO 对应的所有 CPU 页表项。下次用户空间访问时触发 page fault，fault handler 会根据 BO 的新物理位置重新建立映射。

这是一个被动更新策略：不主动重建所有映射，而是先失效、按需重建，避免了迁移时遍历所有映射进程的开销。

4.3 IO 内存映射回调

int(*io_mem_reserve)(structttm_device*bdev,structttm_resource*mem);void(*io_mem_free)(structttm_device*bdev,structttm_resource*mem);unsignedlong(*io_mem_pfn)(structttm_buffer_object*bo,unsignedlongpage_offset);

VRAM 对 CPU 而言是 IO 内存（MMIO），不能像普通内存一样直接访问。这组回调为 CPU 访问 VRAM 提供支持：

io_mem_reserve()：在 CPU 需要访问某个 VRAM 资源前调用，驱动在此设置 BAR 映射窗口（如 amdgpu 的 VRAM 只有部分通过 PCIe BAR 对 CPU 可见，需要动态调整映射窗口）
io_mem_free()：与reserve配对，释放映射窗口
io_mem_pfn()：为 fault handler 返回 BO 指定偏移处的 PFN（Page Frame Number），用于建立 CPU 到 VRAM 的 PTE

三者配合，让 TTM 的 fault handler（ttm_bo_vm_fault）能够透明地处理 CPU 对 VRAM BO 的 mmap 访问，驱动只需实现硬件相关的 BAR 映射细节。

小结：vma_manager解决"用户空间如何找到 BO"，dev_mapping解决"BO 搬家后 CPU 映射怎么办"，io_mem_*回调解决"CPU 如何访问 VRAM"。三者共同构成 TTM 对 CPU/GPU 地址映射的支撑体系。

🔗 导航