Linux drm内存管理(一) 从伙伴系统到BO：GPU内存为何需要专属管家？
1. 从伙伴系统到BO：GPU内存的特殊性
第一次接触GPU内存管理时，我下意识地认为它和CPU内存管理差不多——不就是申请一块内存然后读写吗？但真正深入DRM驱动开发后，才发现这个想法太天真了。CPU的伙伴系统就像个规整的仓库管理员，而GPU内存管理更像是个要同时协调多个仓库的物流主管。
伙伴系统管理CPU内存时，所有内存都挂在统一的内存总线上，物理属性完全一致。但GPU要同时管理多种内存：独立显存（VRAM）、共享系统内存（RAM），甚至不同厂商的显存可能采用完全不同的总线协议。这就好比你要同时管理普通仓库、冷链仓库和危险品仓库，每种仓库的出入库规则都不一样。
更麻烦的是GPU的使用模式。CPU通常以字节为单位随机访问内存，而GPU操作的最小单位是Buffer Object（BO）——相当于整箱搬运货物。一个BO可能包含纹理、着色器等完整数据单元，这些单元在显存中的物理位置对应用程序应该是透明的。这就引出了GPU内存管理的核心挑战：如何让开发者像操作普通内存一样使用BO，同时在内核层智能处理不同内存区域的物理差异？
2. GPU内存管理的三大硬伤
2.1 内存种类多如繁星
上周调试一个AMD显卡时，我数了数它要处理的内存类型：GDDR6显存、通过PCIe映射的系统内存、APU共享的UMAM内存...这还没算不同电源状态下的内存行为差异。当GPU进入S3睡眠时，显存会断电丢失数据，而系统内存却保持供电。这种物理属性的差异，使得CPU那套"一视同仁"的内存管理完全失效。
我曾在驱动代码中看到这样的注释："纹理数据优先放显存，计算中间结果可放系统内存"。这揭示了一个关键设计哲学：GPU内存管理器必须了解不同内存类型的特性，才能做出最优分配决策。就像物流系统要知道哪些货物必须冷藏，哪些可以常温运输。
2.2 总线带宽的紧箍咒
用PCIe总线连接GPU就像用吸管喝珍珠奶茶——珍珠（数据）经常卡住。实测显示，PCIe 3.0 x16的带宽只有约16GB/s，而DDR4内存带宽轻松突破50GB/s。这个数量级差异导致直接内存访问(DMA)成为必选项。
在写驱动时，我经常看到这样的优化：将频繁访问的BO锁定在显存中，减少PCIe传输。这需要内存管理器精确跟踪BO的使用模式，就像快递系统要根据包裹投递频率决定存放位置。TTM框架中的"内存域"(Memory Domain)概念正是为此而生，它能区分显存、系统内存等不同存储区域。
2.3 以Buffer Object为中心的宇宙
传统内存管理关注的是字节地址，而GPU的世界围绕BO展开。一个BO可能包含完整的渲染目标，其生命周期与图形API对象绑定。这带来两个特殊需求：
- BO需要整体迁移：当显存不足时，整个BO可能要被交换到系统内存
- BO需要多重映射：既要被GPU着色器访问，又要支持CPU通过mmap读写
这种使用模式催生了GEM的核心设计——用句柄(handle)抽象BO。应用程序通过句柄操作BO，完全不用关心其物理位置。这就像用快递单号追踪包裹，无需知道它当前在哪个中转站。
3. TTM与GEM的进化之路
3.1 TTM：全能但复杂的管家
早期接触TTM时，我被它的代码复杂度震惊了。一个简单的BO分配可能涉及：
struct ttm_buffer_object *bo; struct ttm_bo_device *bdev; ttm_bo_init(bdev, bo, size, ttm_bo_type_device, &ttm_sys_placement, 0, false, NULL, NULL, &ttm_bo_destroy);这还没考虑内存迁移、同步等操作。TTM像是个事无巨细都要管的老管家，提供了：
- 显存/内存的统一分配接口
- BO迁移的状态机管理
- 内存回收的LRU算法
但它的抽象层次太低，导致每个显卡驱动都要重复实现大量样板代码。我在AMD驱动中见过长达2000行的TTM回调函数，这显然不利于代码维护。
3.2 GEM：化繁为简的革新
GEM的出现就像给TTM套了层友好外壳。它保留了TTM的核心思想，但通过以下简化赢得开发者青睐：
- 隐藏TTM的复杂状态机，暴露简单的create/mmap/destroy接口
- 将内存策略决策下放给驱动实现
- 引入PRIME机制实现跨进程BO共享
以最简单的BO创建为例：
struct drm_gem_object *obj; obj = drm_gem_object_alloc(dev, size);GEM的巧妙之处在于：它知道何时该"装傻"。比如当Intel核显驱动处理BO分配时，GEM会明智地将决策权交给i915驱动的内存管理器，由后者决定使用 stolen memory（预留内存）还是普通系统内存。
4. 实战中的内存管理策略
4.1 混合内存的平衡术
在笔记本双显卡环境中，我经常要调试显存分配策略。好的策略应该考虑：
- 活跃度：频繁访问的BO优先放显存
- 大小：大块BO可能更适合系统内存
- 用途：纹理需要高带宽，计算缓冲区可以容忍延迟
这就像在有限的快递仓库中，要把常发货的商品放在门口，大件物品放到郊区仓库。TTM的eviction（驱逐）机制正是为此设计，它会根据LRU算法自动迁移不活跃的BO。
4.2 DMA-BUF的桥梁作用
当需要跨设备共享BO时（比如GPU到视频编解码器），DMA-BUF就派上用场了。我曾用以下代码实现导出：
struct dma_buf *export; export = drm_gem_prime_export(dev, obj, 0);这个简单的API背后，GEM要处理：
- 内存类型兼容性检查
- 可能的格式转换
- 同步点管理
这相当于为不同快递公司建立统一的包裹交换标准，避免每家都用自己的包装规范。
5. 为什么不能简单套用伙伴系统
最后回到最初的问题：伙伴系统那么好用，为什么GPU不直接拿来用？通过三个实际场景就能明白：
异构内存管理：当显存不足时，伙伴系统无法智能地将部分BO迁移到系统内存。就像普通仓库管理员不会主动把货物转移到冷链仓库。
设备特性抽象：AMD显卡的HBM显存和NVIDIA的GDDR显存访问模式完全不同，伙伴系统的页分配器无法适应这种差异。
图形API集成：Vulkan等现代API要求精细控制内存类型，伙伴系统的"一视同仁"分配策略无法满足需求。
在调试一个内存泄漏问题时，我亲眼看到错误使用伙伴系统分配显存导致的灾难——GPU连续OOM（内存不足）崩溃。改用GEM框架后，内存管理器能自动平衡显存和系统内存使用，问题迎刃而解。