linux下，设备DMA数据至0xF0000000，使用mmap映射，然后memcpy，效率相当低，16M需要400ms，有办法提高？

Posted 2023-05-07

用户内存，一般memcpy 16M数据只要几十ms

参考技术A 你要先找到瓶颈在哪里？
1）设备dma速率。 不要映射，直接在内核memcpy 设备DMA数据，看速率

2）mmap效率。 不要用DMA的内存做映射，用内核申请的内存做映射，然后在用户控件memcpy，看速率

3）用户memcpy效率。这个你已经测试过了，不是问题 参考技术B 楼主找到问题所在了吗？我现在遇到跟楼主一样的问题，942080个字节memcpy，mmap的拷贝到malloc地址，需要108Ms。也在找原因。

Linux内存从0到1学习笔记(8.11 dma-buf导出器和导入器使用示例 二）

        除了前面介绍的非常重要的导出器操作管理结构体dma_buf_ops，我们再来了解下设备缓冲区的附着数据（attachment data）的结构体以及共享缓冲区对象的构成结构体dma_buf。

一，dma_buf_attachment解读

dma_buf_attachment结构体中持有设备缓冲区的附件数据。

include/linux/dma-buf.h（linux 5.18）

/**
 * 此结构保存dma_buf缓冲区与其用户设备之间的附件信息或连接信息。该列表包含附加到缓冲区的每个设备的一个附件结构。
 * 通过调用 dma_buf_attach（） 创建附件，并通过调用 dma_buf_detach（） 再次释放。启动传输所需的 DMA 映射本身由 dma_buf_map_attachment（） 创建，并通过调用dma_buf_unmap_attachment（） 再次释放。
 */
struct dma_buf_attachment 
	struct dma_buf *dmabuf;//当前设备附件所对应的缓冲区
	struct device *dev;//附件上面缓冲区的设备
	struct list_head node;//dma_buf_attachment的列表，受dmabuf的dma_resv锁保护。
	struct sg_table *sgt;//缓存的映射
	enum dma_data_direction dir;//缓存的映射的目录
	bool peer2peer;//如果导入器可以在没有内存页的情况下处理对等资源，则为 true
	const struct dma_buf_attach_ops *importer_ops;//表示导入器针对当前附件的操作，如果提供dma_buf_map/unmap_attachment（）&