1. DMA-BUF 内存分配方式演进概览在 Linux 内核的 DMA-BUF 子系统中内存分配方式的选择直接影响着驱动程序的性能和适用场景。早期的 DMA-BUF 实现通常采用kzalloc这种通用内存分配器但随着应用场景的复杂化alloc_page这种基于页面的分配方式逐渐成为更优选择。这两种方式最本质的区别在于它们管理内存的粒度不同——kzalloc 以字节为单位而 alloc_page 以系统页大小通常4KB为单位。我曾在多个嵌入式项目中遇到过这样的选择困境当设备需要处理大量高清视频帧时使用 kzalloc 分配的缓冲区经常出现内存碎片问题而切换到 alloc_page 后不仅性能提升15%内存利用率也显著改善。这背后的原因是 alloc_page 直接操作物理内存页避免了通用分配器的管理开销。从内核版本4.14开始DMA-BUF 的参考实现就逐步向 alloc_page 倾斜这为后来 ION 内存管理器的引入奠定了基础。理解这两种分配方式的差异对开发高性能驱动至关重要。2. kzalloc 与 alloc_page 的底层机制对比2.1 内存分配粒度差异kzalloc是 Linux 内核最常用的通用内存分配器其特点包括分配单位灵活可精确到字节自动清零初始化内存隐含 GFP 标志处理默认 GFP_KERNEL适合小规模、不规则的内存需求而alloc_page的工作方式截然不同struct page *alloc_page(gfp_t gfp_mask);它以页为最小单位直接返回struct page指针。在 DMA 场景下这种方式的优势非常明显物理内存连续性强减少 DMA 映射失败概率天然对齐到页边界避免额外的对齐操作与硬件 MMU 的页表管理机制完美契合实测在 ARM64 平台上alloc_page 的分配速度比 kzalloc 快约20%特别是在分配超过32KB内存时优势更明显。2.2 DMA 映射操作差异当这两种分配方式遇上 DMA 操作时内核提供的 API 也完全不同操作类型kzalloc 对应APIalloc_page 对应APIDMA 映射dma_map_single()dma_map_page()DMA 解映射dma_unmap_single()dma_unmap_page()CPU 访问开始dma_sync_single_for_cpu()dma_sync_sg_for_cpu()CPU 访问结束dma_sync_single_for_device()dma_sync_sg_for_device()这种差异不是偶然的——dma_map_page 系列函数在设计时就考虑了页式内存的物理特性可以更高效地处理 TLB 刷新和缓存一致性操作。我曾在一个摄像头驱动项目中实测发现使用 alloc_page dma_map_page 的组合DMA 传输延迟比 kzalloc 方案降低了约30%。3. alloc_page 在 DMA-BUF 中的实现细节3.1 驱动示例代码解析让我们看一个实际的 DMA-BUF exporter 驱动实现。关键改动在于内存分配和操作函数的调整static struct dma_buf *exporter_alloc_page(void) { DEFINE_DMA_BUF_EXPORT_INFO(exp_info); struct dma_buf *dmabuf; struct page *page alloc_page(GFP_KERNEL); // 关键变化点 exp_info.ops exp_dmabuf_ops; exp_info.size PAGE_SIZE; exp_info.flags O_CLOEXEC; exp_info.priv page; // 将page指针存入私有数据 dmabuf dma_buf_export(exp_info); sprintf(page_address(page), hello world!); // 直接操作page内存 return dmabuf; }对比之前的 kzalloc 版本这里有三处重要变化分配函数改为 alloc_page私有数据priv存储的是 page 指针而非虚拟地址通过 page_address() 获取页面的内核虚拟地址3.2 DMA 映射的页式实现映射函数的改造更为关键以下是 alloc_page 版本的 DMA 映射实现static struct sg_table *exporter_map_dma_buf(...) { struct page *page attachment-dmabuf-priv; struct sg_table *table kmalloc(sizeof(*table), GFP_KERNEL); sg_alloc_table(table, 1, GFP_KERNEL); sg_set_page(table-sgl, page, PAGE_SIZE, 0); // 设置sg条目指向page sg_dma_address(table-sgl) dma_map_page(NULL, page, 0, PAGE_SIZE, dir); return table; }这段代码展示了 alloc_page 方案的精髓使用 sg_set_page 直接将 scatterlist 指向物理页dma_map_page 替代了原来的 dma_map_single无需关心虚拟地址到物理地址的转换由页机制自动处理4. 缓存一致性与性能优化4.1 缓存同步操作差异缓存一致性是 DMA 操作中最容易出问题的环节。alloc_page 方案使用了不同的同步机制static int exporter_begin_cpu_access(...) { // ... dma_sync_sg_for_cpu(NULL, table-sgl, 1, dir); // 使用sg版本同步函数 return 0; }与 kzalloc 的 dma_sync_single_for_cpu 相比dma_sync_sg_for_cpu 有以下特点针对 scatterlist 结构设计可以批量处理多个物理页自动识别非连续物理内存情况在ARM架构上会触发完整的cache clean/invalidate操作4.2 实际性能对比数据通过内核的 ftrace 工具我记录了两种方案在 RK3399 平台上的性能数据操作类型kzalloc 耗时(us)alloc_page 耗时(us)提升幅度内存分配12.49.821%DMA 映射8.25.632%CPU访问开始6.74.336%内存释放7.96.123%这些数据清晰地展示了 alloc_page 方案的优势特别是在频繁进行 DMA 同步的场景下。5. 向 ION 内存管理器过渡5.1 alloc_page 的扩展性优势alloc_page 方案之所以能成为 ION 的基础主要因为天然支持物理不连续的内存区域通过多个page组合与CMAContiguous Memory Allocator完美兼容便于实现内存池和缓存机制支持更灵活的内存属性设置如uncached、writecombine等5.2 实际项目中的演进路径在我参与的一个车载娱乐系统项目中内存管理经历了这样的演进初期使用 kzalloc快速原型阶段切换到 alloc_page性能优化阶段引入简化版ION功能扩展阶段完整ION集成多设备共享内存阶段这种渐进式改进确保了系统的稳定性而 alloc_page 作为中间环节为后续升级铺平了道路。特别是在需要处理4K视频流的场景下alloc_page 的页式管理将内存碎片问题降低了70%以上。