番外篇：戏说 DRM 子系统 —显存租房那些事儿

0. 引子

咱们先说下CPU 内存的逻辑：每个进程都有自己的 “虚拟地址小房子”，但物理内存就一个 “大别墅”，所以得靠 MMU（硬件翻译官）和 VMA、page（软件管理员）协调。

而 GPU 场景更复杂 —— 不仅有系统内存和 GPU 专属的显存（VRAM） 两块 “地皮”，还得让多个进程、CPU 和 GPU 两个 “硬件打工人” 同时干活，甚至进程间还要共享 “地皮”，这不乱套了？​

但神奇的是，当一个进程打开 GPU 设备时，它会产生一种 “错觉”：这 GPU 是我一个人的！显存想申请就申请、想释放就释放，心情好还能分享给其他进程。这背后是谁在 “圆谎”？答案就是 DRM 子系统里的 “空间大管家”——drm_mm。​

1. drm_mm：给进程画 “虚拟大饼” 的空间管理器​

drm_mm 的核心工作，就是给每个进程画一块 “连续的逻辑空间大饼”：​

• 这块空间的大小，等于 GPU 设备的容量，让进程觉得 “整个 GPU 存储都是我的”。注：不同的物理空间(GTT/VRAM)可以用不同的drm_mm管理器；​

• 但注意！这只是逻辑空间，不是真实的物理内存 / 显存 。​

2. drm_vma_offset_manager：解决 mmap 的 “offset 难题”​

进程（用户态）想读写一个 GPU 缓冲区（bo，相当于 “存储集装箱”），第一步得做 mmap—— 把 bo 映射到自己的虚拟地址空间，这样才能直接操作。但 mmap 有个硬性要求，得指定三个参数：file（要映射的文件）、offset（文件内偏移）、si