Linux DRM内存管理：GEM、TTM与drm_buddy解析

1. Linux DRM内存管理子系统概述

在Linux图形驱动领域，DRM（Direct Rendering Manager）子系统承担着核心的图形内存管理职责。作为一名长期从事GPU驱动开发的工程师，我经常需要深入理解DRM中的内存管理机制。今天我们就来剖析其中的三个关键组件：GEM、TTM和drm_buddy，它们构成了现代Linux图形驱动内存管理的基石。

DRM内存管理子系统采用分层设计理念，这种架构源于对不同硬件特性的适配需求。集成显卡（如Intel核显）通常共享系统内存，而独立显卡（如AMD/NVIDIA显卡）则拥有专用显存（VRAM）。这种硬件差异导致了内存管理策略的多样性，而GEM、TTM和drm_buddy正是在这种背景下诞生的互补性解决方案。

提示：理解这三个组件的关系时，可以类比建筑行业——GEM是面向客户的销售部门，TTM是负责资源调配的项目经理，drm_buddy则是具体施工的建筑工人。

在实际驱动开发中，这三个组件的选择组合取决于硬件特性：

• 简单集成显卡：仅需GEM
• 现代独立显卡：GEM + TTM + drm_buddy
• 新型混合架构：GEM + drm_buddy（如Intel Xe架构）

2. GEM：用户空间的桥梁

2.1 GEM的核心职责

Graphics Execution Manager（GEM）是DRM子系统中最上层的组件，主要负责：

• 提供标准的用户空间接口（通过ioctl系统调用）
• 管理缓冲区对象的生命周期（创建、引用计数、销毁）
• 处理不同进程间的内存共享（通过DMA-BUF机制）

在驱动开发实践中，GEM对象（struct drm_gem_object）是最基础的抽象。每个GEM对象都对应一个用户空间可见的句柄（handle），但实际内存可能位于不同位置（系统内存或VRAM）。这种抽象使得应用程序无需关心内存的具体位置。

c复制// 典型的GEM对象创建流程（驱动侧示例）
static int mygem_create(struct drm_device *dev, void *data,
                       struct drm_file *file)
{
    struct drm_mygem_create *args = data;
    struct mygem_object *obj;
    
    // 创建GEM对象
    obj = mygem_create_object(dev, args->size);
    if (IS_ERR(obj))
        return PTR_ERR(obj);
    
    // 将GEM对象关联到文件句柄
    ret = drm_gem_handle_create(file, &obj->base, &args->handle);
    drm_gem_object_put(&obj->base);
    return ret;
}

2.2 GEM的设计哲学

GEM最初由Intel工程师为集成显卡设计，体现了以下设计特点：

1. 简单优先：避免复杂的内存迁移策略
2. UMA优化：针对共享系统内存的架构优化
3. 接口稳定：保证用户空间API的长期兼容性

在早期的Intel i915驱动中，GEM直接管理系统内存分配。但随着GPU架构演进，这种简单设计逐渐显现局限性——无法高效处理独立显卡的多内存域特性。这就引出了TTM的用武之地。

注意：虽然GEM API看似简单，但在实现跨进程共享时，需要特别注意同步问题。常见的错误是忽略fence同步，导致渲染竞态条件。

3. TTM：内存策略大师

3.1 TTM的架构设计

Translation Table Maps（TTM）是比GEM更复杂的中间层组件，其主要功能包括：

• 多内存域管理（VRAM、GTT、系统RAM）
• 缓冲区迁移策略（根据使用频率动态调整位置）
• 内存回收与压缩（应对显存不足的情况）

TTM的核心数据结构是struct ttm_buffer_object，它比GEM对象包含了更多元信息：

c复制struct ttm_buffer_object {
    struct drm_gem_object base;  // 继承GEM对象
    struct ttm_bo_device *bdev;  // 所属设备
    enum ttm_bo_type type;       // 缓冲区类型
    struct ttm_resource *resource; // 当前内存位置
    // ...
};

3.2 TTM的高级特性

在实际驱动开发中，TTM提供了几个关键能力：

内存域自动迁移

mermaid复制graph LR
    A[用户提交渲染任务] --> B{TTM决策}
    B -->|高频使用| C[迁移到VRAM]
    B -->|低频使用| D[迁移到系统内存]

显存回收策略
当VRAM不足时，TTM会：

1. 按LRU算法选择候选缓冲区
2. 检查缓冲区是否可回收（无正在执行的命令引用）
3. 执行迁移并释放VRAM空间

实际案例：AMD显卡的显存管理
在AMDGPU驱动中，TTM管理着复杂的显存层次：

• 高性能VRAM（如HBM2）
• 系统内存备份区域
• GART（Graphics Aperture Remapping Table）空间

c复制// AMDGPU中TTM初始化的关键代码片段
int amdgpu_ttm_init(struct amdgpu_device *adev)
{
    // 初始化TTM设备
    ttm_bo_device_init(&adev->mman.bdev, &amdgpu_bo_driver,
                      adev->ddev->anon_inode->i_mapping,
                      adev->ddev->vma_offset_manager,
                      false);
    
    // 设置内存域
    amdgpu_ttm_set_buffer_funcs_status(adev, true);
    
    // 初始化VRAM和GTT域
    amdgpu_ttm_init_mem_type(adev, TTM_PL_VRAM, &adev->mman.vram_mm);
    amdgpu_ttm_init_mem_type(adev, TTM_PL_TT, &adev->mman.gtt_mm);
}

经验分享：在调试TTM迁移问题时，建议启用dynamic_debug打印，可以观察缓冲区在不同内存域间的迁移过程。命令示例：

bash复制echo 'file amdgpu* +p' > /sys/kernel/debug/dynamic_debug/control

4. drm_buddy：物理内存的艺术家

4.1 Buddy分配器原理

drm_buddy是Linux DRM子系统中较新的成员，它实现了经典的Buddy内存分配算法。其核心特点包括：

• 基于2^n大小的块分配
• 自动合并相邻空闲块
• 最小化外部碎片

Buddy算法的优势在GPU场景尤为明显：

1. 大块连续分配：适合纹理等大资源
2. 快速分配/释放：O(logN)时间复杂度
3. 碎片控制：通过合并减少内存空洞

4.2 drm_buddy的实现细节

在Intel i915驱动中，drm_buddy管理着显存的物理布局。关键数据结构包括：

c复制struct drm_buddy_block {
    struct list_head link;  // 空闲链表
    struct list_head tmp_link;
    u64 start;             // 起始地址
    u64 size;              // 块大小
    unsigned int order;    // 块阶数
};

典型分配流程：

1. 从最大阶（如10阶=1MB块）开始搜索
2. 如果找到合适块，立即分配
3. 否则将大块分裂为两个"伙伴"小块
4. 递归执行直到找到合适大小的块

性能优化技巧：

• 维护不同阶的空闲列表，加速搜索
• 使用红黑树管理分配块
• 实现延迟合并策略，避免频繁合并/分裂

c复制// drm_buddy分配核心代码简化版
int drm_buddy_alloc_blocks(struct drm_buddy *mm,
                          u64 start, u64 end,
                          u64 size, u64 min_page_size,
                          struct list_head *blocks)
{
    for (order = fls(size) - 1; order >= 0; order--) {
        if (size < (1ULL << order))
            continue;
        
        list_for_each_entry(block, &mm->free_list[order], link) {
            if (block->start >= start && block->start + size <= end) {
                list_move_tail(&block->link, blocks);
                return 0;
            }
        }
    }
    return -ENOSPC;
}

5. 三者的协同工作

5.1 典型工作流程

以游戏加载4K纹理为例，三个组件的协作过程：

1. GEM接口层

   • 游戏引擎调用DRM_IOCTL_GEM_CREATE
   • 创建GEM对象并返回句柄

2. TTM策略层

   • 判定纹理应放入VRAM
   • 检查VRAM空间，必要时触发回收
   • 选择合适的内存域（TTM_PL_VRAM）

3. drm_buddy执行层

   • 在VRAM中分配16MB连续空间
   • 使用buddy算法找到最佳匹配块
   • 返回物理地址给TTM

5.2 性能调优实践

在实际项目中，我们通过以下策略优化内存管理：

GEM层优化

• 实现自定义的gem_prime_import回调，加速跨进程共享
• 使用drm_gem_object的resv锁优化并发访问

TTM层调优

table复制| 参数                | 默认值 | 优化建议         | 影响               |
|---------------------|--------|------------------|--------------------|
| ttm_page_pool_size  | 256    | 增大到1024       | 减少分配延迟       |
| ttm_dma32_pages     | 0      | 设为1（启用）    | 32位设备性能提升   |
| ttm_agp_alloc       | 1      | 根据硬件调整     | 影响AGP纹理上传    |

drm_buddy优化

• 调整最大阶数（max_order）匹配硬件特性
• 实现自定义的alloc_range回调处理特殊内存区域
• 监控碎片率，必要时主动触发内存整理

关键提示：在AMDGPU驱动中，可以通过amdgpu_ttm_pool参数调整内存池行为。例如设置amdgpu.ttm_pool=1可以启用更积极的内存回收策略。

6. 疑难问题排查

6.1 常见问题与解决方案

问题1：VRAM分配失败

• 现象：dmesg中出现TTM out of memory错误
• 排查步骤：
  1. 检查cat /sys/class/drm/card0/device/mem_info_vram_total
  2. 确认是否有内存泄漏（drm_mm_dump_table）
  3. 调整TTM回收策略参数

问题2：内存碎片严重

• 现象：连续分配失败，但总空闲内存充足
• 解决方案：
  • 短期：手动触发echo 1 > /sys/kernel/debug/dri/0/buddy_frag
  • 长期：优化应用程序的内存分配模式

问题3：跨进程共享性能差

• 现象：DMA-BUF导入导出耗时过长
• 优化方法：
  • 使用O_CLOEXEC标志创建句柄
  • 实现gem_prime_import_sg_table加速导入

6.2 调试工具推荐

1. DRM DebugFS接口

   bash复制# 查看GEM对象信息
   cat /sys/kernel/debug/dri/0/gem
   
   # 检查TTM内存域状态
   cat /sys/kernel/debug/dri/0/ttm_pools
   

2. FTrace跟踪

   bash复制echo 1 > /sys/kernel/debug/tracing/events/drm/enable
   cat /sys/kernel/debug/tracing/trace_pipe
   

3. 自定义调试打印
   在驱动代码中添加：

   c复制DRM_DEBUG_DRIVER("Allocated %llu bytes at %p\n", size, ptr);
   

7. 演进趋势与最佳实践

7.1 技术演进方向

当前DRM内存管理子系统的发展趋势：

1. drm_buddy的普及：逐渐替代传统的TTM分配器
2. 异构内存支持：统一管理CPU内存和GPU显存
3. AI工作负载优化：针对大模型训练的特殊分配策略

7.2 开发实践建议

基于多年驱动开发经验，我总结出以下最佳实践：

GEM开发要点

• 保持ioctl接口的向后兼容
• 实现完整的DMA-BUF操作集
• 谨慎处理用户空间指针验证

TTM集成技巧

c复制// 正确的TTM后端初始化示例
static struct ttm_device_funcs my_ttm_bo_driver = {
    .ttm_tt_create = my_ttm_tt_create,
    .eviction_valuable = ttm_bo_eviction_valuable,
    .evict_flags = my_bo_evict_flags,
};

int my_init_ttm(struct my_device *dev)
{
    return ttm_device_init(&dev->ttm_dev, &my_ttm_bo_driver,
                         dev->ddev->dev, dev->ddev->anon_inode->i_mapping,
                         dev->ddev->vma_offset_manager, false);
}

drm_buddy优化建议

• 根据硬件页表特性调整最小分配大小
• 实现get_pages回调支持压缩内存
• 监控/sys/kernel/debug/dri/0/buddy状态

在结束之前，我想分享一个实际调试案例：某次在AMDGPU驱动中，我们发现4K分辨率下游戏会出现间歇性卡顿。通过分析TTM迁移日志，最终定位到是VRAM回收策略过于激进导致的。调整amdgpu.vram_page_cache参数后，性能得到了显著改善。这个案例生动说明了理解DRM内存管理机制对图形驱动开发的重要性。