DMA-BUF与mmap共享内存对比分析

ikun-fans

于 2025-06-03 14:08:18 发布

阅读量981

点赞数 5

CC 4.0 BY-SA版权

文章标签： linux c++

本文链接：https://blog.csdn.net/u012456479/article/details/148400570

DMA-BUF 和传统的 mmap 共享内存（如 POSIX shm_open + mmap 或 SysV shmget）在功能上有重叠，但设计目标和适用场景有本质区别。DMA-BUF 在特定场景下可以替代 mmap，但并非所有场景都适用。下面从多个维度深入分析：

一、核心区别：设计目标

特性	传统 mmap 共享内存	DMA-BUF
核心目标	进程间高效数据共享	跨设备/跨驱动零拷贝共享内存
主要使用者	用户态进程	内核驱动 (DRM, V4L2, GPU, VPU, 编解码器等)
硬件交互	无直接硬件加速支持	原生支持 DMA 操作，硬件可直接访问
同步机制	用户态自行解决 (如信号量)	内核态同步原语 (`dma_fence`, `sync_file`)
内存管理	由内核或用户管理	由导出内存的设备驱动管理
适用层级	用户态 ↔ 用户态	用户态 ↔ 内核态 ↔ 硬件设备

二、DMA-BUF 能否替代 mmap？

✅ 可以替代的场景（DMA-BUF 优势明显）

需要硬件加速器直接访问数据：
- 场景示例： GPU 渲染 → 视频编码器输出。
- 优势： DMA-BUF 允许硬件设备直接读写内存，无需 CPU 参与拷贝。
- 传统 mmap 瓶颈： 数据需先由 GPU 驱动读到 CPU，再通过 mmap 到用户态，最后拷贝到编码器驱动 → 两次冗余拷贝。
跨驱动/跨子系统传递内存：
- 场景示例： Camera 采集 (V4L2) → GPU 处理 (DRM) → 显示器输出。
- 优势： DMA-BUF 是 Linux 内核标准的跨驱动共享框架，所有主流驱动（DRM/V4L2/DMAengine）均支持。
- 传统 mmap 瓶颈： 不同驱动间无法直接共享 mmap 的内存（需通过用户态中转拷贝）。
零拷贝视频处理管线：
- 场景示例： GStreamer/FFmpeg 中的 vaapi/v4l2 插件。
- 优势： DMA-BUF 实现 硬件解码 → 处理 → 编码 → 输出全程零拷贝。
- 传统 mmap 瓶颈： 每一阶段都需将数据映射到用户态再传递 → 性能损失。

❌ 不推荐替代的场景（mmap 更简单高效）

纯用户态进程间通信 (IPC)：
- 场景示例： 两个进程共享一个配置结构体或日志缓冲区。
- 原因： mmap 使用简单（shm_open + mmap 几行代码搞定），而 DMA-BUF 需要复杂的 ioctl 交互和同步管理。
- 关键区别： 无需硬件参与时，DMA-BUF 的同步机制 (dma_fence) 反而成为负担。
小数据量高频交换：
- 场景示例： 实时更新的传感器数据（每秒千次）。
- 原因： DMA-BUF 的同步开销 (fence 等待/触发) 可能高于数据拷贝本身。
- 优化建议： mmap 共享内存 + 用户态原子操作（如 CAS）更轻量。
非 Linux 系统或旧内核：
- 场景示例： 需兼容 Windows/macOS 或 Linux 内核 < 3.3。
- 原因： DMA-BUF 是 Linux 特有机制（且依赖较新驱动）。

三、技术实现对比

🔧 内存映射机制

能力	传统 mmap	DMA-BUF
映射到用户空间	直接支持 (`mmap` 系统调用)	支持 (通过 `mmap` DMA-BUF 文件描述符)
内核驱动访问	需额外开发（非标准）	原生支持 (驱动通过 `dma_buf_ops` 操作)
硬件 DMA 访问	不支持	原生支持 (物理地址/SCG 列表透传)
内存类型	普通物理内存	可包含设备专用内存 (如 GPU VRAM)

⚙️ 同步机制

复制

下载

// DMA-BUF 的同步原语示例 (内核态)
struct dma_fence *fence = exporter_device_create_fence();
importer_device_submit_work(work, fence); 
dma_fence_wait(fence, timeout);

DMA-BUF: 使用 dma_fence 或 sync_file 实现精确的硬件间依赖链（如“GPU 渲染完成 → 编码器开始工作”）。
传统 mmap: 只能通过用户态信号量/互斥锁同步 → 无法控制硬件执行顺序。

四、性能对比

操作	传统 mmap 路径	DMA-BUF 路径
数据从 A 设备 → B 设备	1. A 设备 → CPU (DMA) 2. CPU → 用户内存 (mmap) 3. 用户内存 → CPU 4. CPU → B 设备 (DMA)	A 设备 → B 设备 (直接 DMA)
CPU 参与度	高 (拷贝 + 映射)	极低 (仅元数据传递)
延迟	高 (微秒级)	低 (纳秒级同步)
吞吐量	受限于 PCIe/Copy 带宽	接近硬件极限

📌 关键结论：涉及硬件加速器时，DMA-BUF 性能碾压 mmap（避免 2-4 次冗余拷贝）！

五、典型应用案例

1. Wayland 显示服务器

图表

代码

下载

GPU渲染

DMA-BUF 导出

DMA-BUF 导入

应用程序

GPU Buffer

Wayland Compositor

Kernel Mode Setting

显示器

全程零拷贝： 应用渲染的 GPU 缓冲区直接通过 DMA-BUF 送显。

2. Chrome 硬件加速渲染

视频播放： 解码器输出 DMA-BUF → GPU 着色器后处理 → 显示器输出。
减少功耗： 避免移动端 CPU 参与拷贝，显著提升续航。

3. AI 推理管线

复制

下载

// 典型推理流程
camera_buf = v4l2_export_dmabuf();          // 摄像头采集
gpu_preprocess(camera_buf, &preprocessed);  // GPU 预处理
npu_infer(preprocessed, &result);           // NPU 推理
display_show(result);                       // 结果显示

所有环节通过 DMA-BUF 传递数据，CPU 仅调度任务。

六、总结：何时选择哪种技术？

场景	推荐方案	原因
进程间共享数据（无硬件参与）	mmap 共享内存	简单高效，编程模型直观
硬件加速器流水线（GPU/VPU/NPU）	DMA-BUF	零拷贝，硬件间直接通信
用户态与内核驱动交换大数据	DMA-BUF	避免用户态 ↔ 内核态拷贝
高频小数据 IPC	mmap + 原子操作	DMA-BUF 同步开销过大
跨平台兼容需求	mmap	DMA-BUF 是 Linux 特有机制

核心结论：
DMA-BUF 是解决 硬件设备间零拷贝共享 的终极方案，而传统 mmap 是 纯软件层共享 的利器。
在涉及硬件加速器（GPU/视频编解码器/AI 加速器）的场景中，DMA-BUF 是无可替代的基础设施；而对于纯用户态的数据共享，mmap 仍是更优选择。两者在 Linux 生态中互补共存，而非替代关系。