Linux DRM 内存管理子系统的概念关系理解：gem、ttm、drm_buddy

概述

在 Linux 直接渲染管理器子系统中，drm_buddy、GEM 和 TTM 是三个重要的内存管理组件。它们并不是互斥的关系，而是服务于内存管理堆栈的不同层级，协同工作以实现高效的 GPU 内存管理。

核心组件

1. GEM

定位：用户空间 API 和缓冲区句柄管理

主要职责

• 为用户空间应用程序（如 Mesa/OpenGL）提供标准的缓冲区管理 API
• 通过 ioctl 接口管理内存句柄（handles）的创建、映射和共享
• 处理缓冲区对象的引用计数和生命周期管理

设计特点

• 简洁性：最初为统一内存架构（UMA）系统设计，避免复杂的内存迁移
• 硬件目标：主要面向集成显卡，GPU 共享系统主内存
• 用户友好：提供简单直观的用户空间接口

使用范围

几乎所有现代 DRM 驱动程序都使用 GEM 作为用户空间接口标准。

2. TTM (Translation Table Manager)

定位：高层缓冲区放置与迁移管理器

主要职责

• 管理缓冲区对象的完整生命周期
• 决定缓冲区应该存放的位置（VRAM、GTT 或系统内存）
• 处理内存域之间的缓冲区迁移和交换
• 实现复杂的内存驱逐策略

设计特点

• 复杂性高：专为具有多种内存类型的独立显卡设计
• 硬件目标：独立显卡，管理专用 VRAM
• 功能全面：处理系统 RAM 和 VRAM 之间的所有复杂操作

使用范围

• AMD 驱动程序（amdgpu）
• NVIDIA 开源驱动（Nouveau）
• VMware 虚拟显卡驱动

典型工作流程

用户请求 → TTM 评估 → 选择内存域 → 必要时驱逐旧缓冲区 → 调用底层分配器

3. drm_buddy

定位：底层物理块分配器

主要职责

• 管理内存池（如 VRAM）的内部物理布局
• 使用 buddy 算法进行高效的页级别分配
• 减少内存碎片，提高分配效率
• 作为 TTM 或其他管理器的后端分配引擎

设计特点

• 模块化：可以被不同驱动程序插入使用
• 硬件目标：现代独立显卡的 VRAM 管理
• 专注性：专注于 buddy 分配算法的实现

使用范围

• Intel 驱动程序（i915/Xe）
• AMD 驱动程序（amdgpu）作为 TTM 的底层分配器

Buddy 算法优势

• 快速分配和释放
• 自动合并相邻空闲块
• 减少外部碎片
• 支持不同大小的内存请求

三者关系详解

drm_buddy 与 TTM 的关系

虽然 TTM 是处理复杂操作的高层管理器，drm_buddy 是其底层分配后端：

协作示例：

amdgpu 驱动： TTM (决策层) → 决定使用 VRAM ↓ drm_buddy (执行层) → 在 VRAM 中找到具体的物理页

drm_buddy 与 GEM 的关系

GEM 提供用户空间接口，drm_buddy 是内核内部工具：

协作示例：

用户空间应用： 调用 GEM ioctl (创建缓冲区) ↓ 内核驱动接收请求 ↓ 调用 drm_buddy 分配物理内存 ↓ 返回 GEM 句柄给用户空间

完整对比表

工作流程示例

场景：应用程序请求创建一个 GPU 缓冲区

1. 用户空间应用 └─> 调用 GEM API: "我需要一个 16MB 的缓冲区" │ 2. GEM 层（内核） └─> 创建 GEM 对象，分配句柄 │ 3. TTM 层（如果驱动使用 TTM） └─> 决策："这个缓冲区应该放入 VRAM" └─> 检查 VRAM 空间 └─> 如果需要，驱逐旧缓冲区 │ 4. drm_buddy 层 └─> 在 VRAM 中执行 buddy 分配 └─> 找到连续的物理页块 └─> 返回物理地址 │ 5. 返回路径 └─> TTM 更新页表 └─> GEM 完成对象初始化 └─> 返回句柄给用户空间

驱动程序实现模式

模式 1：GEM + drm_buddy（简单型）

适用于：现代集成显卡或简单独立显卡

Intel i915/Xe: - GEM 提供用户接口 - drm_buddy 管理 VRAM 分配 - 无需 TTM 的复杂迁移逻辑

模式 2：GEM + TTM + drm_buddy（完整型）

适用于：复杂的独立显卡

AMD amdgpu: - GEM 提供用户接口 - TTM 处理内存放置和迁移 - drm_buddy 作为 TTM 的底层分配器

模式 3：仅 GEM（传统型）

适用于：简单的 UMA 系统

部分集成显卡驱动： - 仅使用 GEM - 直接使用系统内存 - 无需 VRAM 管理

关键概念总结

一句话总结

GEM告诉内核 “我需要一个缓冲区”
TTM决定 “这个缓冲区应该放入 VRAM”
drm_buddy在 VRAM 中找到确切的物理页来存放它

层次关系

┌─────────────────────────────────────┐ │ 用户空间应用（OpenGL/Vulkan） │ └──────────────┬──────────────────────┘ │ ioctl ┌──────────────▼──────────────────────┐ │ GEM (用户空间接口层) │ └──────────────┬──────────────────────┘ ┌──────────────▼──────────────────────┐ │ TTM (策略与迁移层) - 可选 │ └──────────────┬──────────────────────┘ ┌──────────────▼──────────────────────┐ │ drm_buddy (物理分配层) │ └──────────────┬──────────────────────┘ ┌──────────────▼──────────────────────┐ │ 物理 VRAM / 系统内存 │ └─────────────────────────────────────┘

实际应用场景

场景 1：游戏加载大纹理

1. GEM：应用请求创建纹理缓冲区
2. TTM：判断纹理应该在 VRAM 中以获得最佳性能
3. drm_buddy：在 VRAM 中分配连续的物理页
4. 结果：GPU 可以高速访问纹理数据

场景 2：内存压力下的缓冲区驱逐

1. TTM：检测到 VRAM 不足
2. TTM：选择不常用的缓冲区驱逐到系统内存
3. drm_buddy：释放 VRAM 物理页
4. drm_buddy：为新请求分配刚释放的空间

场景 3：多进程共享缓冲区

1. GEM：进程 A 创建缓冲区，获得句柄
2. GEM：通过 DMA-BUF 导出句柄
3. GEM：进程 B 导入句柄，共享同一物理内存
4. 底层：drm_buddy 分配的物理页被两个进程共享

参考资源

• Linux DRM 官方文档
• Intel i915 drm_buddy 实现
• AMD GPU 驱动文档

结论

DRM 内存管理子系统通过三个层次的组件实现了灵活高效的 GPU 内存管理：

• GEM提供统一的用户空间接口
• TTM处理复杂的内存策略和迁移
• drm_buddy提供高效的物理内存分配

这种分层设计使得驱动程序可以根据硬件特性选择合适的组件组合，既保证了接口的统一性，又提供了实现的灵活性。