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 域管理器sysmanstructttm_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_poolstructttm_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_unpopulatettm_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 策略基于 LRULeast 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并指定一个中间域如先到 TTTTM 核心会自动进行两跳迁移。3.3 延迟删除工作队列wqstructworkqueue_struct*wq;初始化时创建bdev-wqalloc_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_lockunevictable提供数据结构基础三个 eviction 回调定义策略wq保障异步执行swapout 路径应对系统级内存压力。这套机制让 TTM 能够在 VRAM 容量有限的情况下透明地为应用提供远超物理显存的使用体验。4. GPU 地址映射支撑如 4.1 节所述TTM 不直接操作 GPU 页表但它为地址映射提供关键的基础设施。ttm_device中有三组成员与此相关。4.1 VMA 偏移管理vma_managerstructdrm_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_mappingstructaddress_space*dev_mapping;当 BO 发生迁移如从 VRAM 迁到 TT其物理地址改变了但用户空间可能仍持有旧的 CPU 映射通过 mmap 建立的 PTE 指向旧 VRAM 地址。如果不处理CPU 会访问到错误的物理地址。dev_mapping指向设备的address_spaceTTM 在 BO 迁移时调用unmap_mapping_range()批量失效该 BO 对应的所有 CPU 页表项。下次用户空间访问时触发 page faultfault 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 指定偏移处的 PFNPage Frame Number用于建立 CPU 到 VRAM 的 PTE三者配合让 TTM 的 fault handlerttm_bo_vm_fault能够透明地处理 CPU 对 VRAM BO 的 mmap 访问驱动只需实现硬件相关的 BAR 映射细节。小结vma_manager解决用户空间如何找到 BOdev_mapping解决BO 搬家后 CPU 映射怎么办io_mem_*回调解决CPU 如何访问 VRAM。三者共同构成 TTM 对 CPU/GPU 地址映射的支撑体系。 导航上一节4.5 ttm_device 设计与实现解析下一节4.5.2 ttm_device 初始化与全局管理返回目录: linux drm子系统技术实现分析产品化应用分享专栏目录