dma-coherent设备树属性解析：缓存一致性对DMA驱动性能的影响

直接从一个我最近在 RK3566 板子上排查的问题说起。SDK 自带的设备树里gmac0、sdmmc、vop这些节点下面都挂着dma-coherent这个属性当时带我的老工程师只说了一句外设访问内存和 CPU 缓存保持一致用的也没细讲。直到自己动手改了一个外设的 DTS把dma-coherent删掉之后网络吞吐量直接掉了三成才意识到这一行字背后牵扯的是整套 DMA 缓存一致性机制。这篇文章就把dma-coherent从设备树到内核实现、从硬件原理到驱动行为彻底拆开讲清楚。1. dma-coherent 要向内核表达的事情缓存一致性到底由谁负责1.1 先从DMA 为什么会踩到缓存说起现代 SoC 里CPU 访问内存并不是直接读写 DDR而是经过多级缓存L1、L2部分还有 L3。缓存将最近访问的数据留在离 CPU 更近的地方命中时不用再去访问慢速的 DDR。但也正因为有这一层外设通过 DMA 直接读写内存时就产生了一个经典问题CPU 写了一个数据到某个内存地址这个数据实际可能停留在 Cache 里还没有被写回write back到真正的物理内存外设 DMA 直接去读物理内存读到的却是旧数据反过来外设 DMA 把新数据写进了物理内存CPU 再去读时Cache 里存的还是旧值于是 CPU 读到的也是旧数据。这种现象在嵌入式开发里非常致命。它不像编译错误那样直接报错而是表现为偶尔数据不对莫名其妙丢包图像撕裂花屏看起来正常的代码跑起来结果却是错的这类隐蔽故障。1.2 dma-coherent 属性的语义告诉内核这个设备自己处理一致性设备树里给某个设备节点加上dma-coherent;这一行时内核会通过of_dma_is_coherent()解析到该设备是DMA 一致性设备。在 Linux 中这个标志最终会被记录为dev-dma_coherent true。它的含义是这个外设访问内存时硬件层面已经保证了与 CPU 缓存的一致性。也就是说外设和 CPU 看到的是同一份数据不需要软件去手动做缓存同步。至于硬件是怎么保证的可能因为总线协议支持如 ARM 的 ACE/CHI 总线具备硬件一致性监听能力、也可能因为该外设本身带 snoop 逻辑、或者是该外设的 DMA 缓冲区被放在了一个不被缓存的地址区域这些对内核来说并不关心内核只需要知道这个设备不需要我做软件同步。反过来如果设备节点没有dma-coherent属性内核默认认为该设备是非一致性的。那么在 DMA 操作前后驱动必须调用一系列缓存同步操作确保数据在 CPU 与设备之间正确传递。很多刚入行的人会把dma-coherent和设备支持 DMA混为一谈这是第一层误解。几乎所有外设都支持 DMA但支持 DMA不等于DMA 过程中内存是一致的。这里需要区分两个完全不同的层次。含义设备支持 DMA设备是 DMA coherent能否通过 DMA 搬运数据是是硬件是否保证缓存一致性不保证保证驱动是否需要同步 Cache是否对应设备树写法无 dma-coherent有 dma-coherent1.3 ARM 世界里一致的分量在 ARM 体系里DMA 一致性能力往往和总线互联架构强相关。比较新的 SoC 会采用 CCI、CCN 或 CMN 这类缓存一致性互联总线连接 CPU 簇和各个外设。当外设通过一致性端口发起访问时总线会主动去 CPU 的 Cache 里查找是否有对应缓存行如果有的话会做 snoop监听操作保证外设读到的数据是 CPU Cache 里的最新版本外设写入的数据也能同步更新到 Cache 中或使对应缓存行失效。而一些老平台或低成本平台外设的 DMA 走的是普通非一致性端口总线上完全没有监听逻辑这种情况下硬件不保证一致性只能靠软件来维护。所以dma-coherent看似是设备树里一行可有可无的配置实际上它对应的是这套芯片硬件架构到底有没有为这个外设提供一致性通道这个底层事实。配置错了不是软件逻辑的问题是对硬件能力描述失真引发的问题是玄学级的。2. 软件维护一致性到底有多贵dma_alloc_coherent 与 dma_map_single 的分岔路2.1 驱动开发者能感知到的最直接差异假设你写一个驱动要给设备分配一块 DMA 缓冲区。不管设备树里有没有dma-coherent你都可以用同一个 APIdma_alloc_coherent()。但是内核在这条调用链路上的行为是完全不同的对于dma_coherent为 true 的设备dma_alloc_coherent()分配好内存后直接返回不需要后续任何缓存维护对于dma_coherent为 false 的设备分配内存时内核会确保这块地址在 CPU 侧不被缓存或者使用非缓存映射或者分配后再做清理操作以保证设备能看到正确数据。同理当驱动使用流式 DMA 映射时差异体现在dma_map_single()和dma_unmap_single()内部。非一致性设备在 map 和 unmap 时会调用底层架构相关的dma_sync_single_for_device()/dma_sync_single_for_cpu()做 cache clean、invalidate 或两者都做。这些操作的开销随着缓冲区大小和操作频率线性增长。举例来说一个千兆网卡每个网络包在发送和接收时都要做一次 DMA map/unmap如果每次都要清理几 KB 的缓存行CPU 开销非常大。这也是我开头说的那个案例里删掉dma-coherent后吞吐量掉三成的原因——所有的时间都花在 cache 同步上了。2.2 内核源码里的关键判断分支在较新的内核5.x 及以上中DMA 映射的标准实现是dma_direct_map_page()、dma_direct_unmap_page()等函数。这里面有一个核心判断static inline bool dma_direct_sync_single_for_device(struct device *dev, dma_addr_t addr, size_t size, enum dma_data_direction dir) { if (dev_is_dma_coherent(dev)) return false; arch_sync_dma_for_device(dev, phys, size, dir); return true; }代码逻辑非常简单如果设备是 coherent 的那么同步函数直接返回什么都不做只有非 coherent 设备才会走arch_sync_dma_for_device()去操作缓存。同样的逻辑也存在于dma_direct_alloc()中。内核会基于dev_is_dma_coherent()来决定使用哪种内存分配策略void *dma_direct_alloc(struct device *dev, size_t size, dma_addr_t *dma_handle, gfp_t gfp, unsigned long attrs) { ... if (dev_is_dma_coherent(dev)) { /* 使用普通页分配直接线性映射不做特殊处理 */ page __dma_direct_alloc_pages(dev, size, gfp ~__GFP_DMA, true); ... } else { /* 需要保证内存是非缓存映射或使用 DMA 池 */ ... if (IS_ENABLED(CONFIG_DMA_DIRECT_POOL)) page dma_direct_alloc_from_pool(dev, size, phys, gfp); ... } }这个分支让两种设备的驱动运行路径存在巨大差异。理解了这一点你就能明白DTS 里那行属性最终改变的是内核 DMA 子系统对内存一致性责任方的判断。2.3 不只是性能损失错误配置还可能导致数据错乱如果硬件实际不支持一致性却错误地添加了dma-coherent后果比性能下降严重得多。假设一个外设 DMA 写了一块内存但 CPU 的 Cache 里还保留着同一地址的旧值。由于dma-coherent告诉内核不用管一致性驱动就不会做 invalidate 操作CPU 后续读取时会命中 Cache 里的旧值。如果这块内存正好是网络接收缓冲区就会周期性出现数据校验错误如果是显示缓冲区就有可能出现画面残留或局部花屏如果是存储控制器则会不定时出现文件系统损坏。我实际排查过一个 USB 摄像头花屏问题最后定位到是 BSP 的工程师在 USB 节点上错误地添加了dma-coherent而那块 SoC 的 USB 控制器并不具备硬件一致性能力。去掉属性后花屏立刻消失。这类问题往往不固定频率复现单抓一次 log 可能完全看不到异常所以排查起来非常消耗时间。3. RK3566 平台实际设备树分析那些带 dma-coherent 的节点分别是什么情况3.1 RK3566 里常见的 dma-coherent 配置概况RK3566/RK3568 是 Rockchip 面向 AIoT 市场的中端 SoC集成度比较高。在官方 SDK 的rk3566.dtsi中不少外设节点都带有dma-coherent属性。我基于实际使用过的 SDK 版本Linux 4.19 / 5.10 分支梳理了一下节点是否常见 dma-coherent硬件一致性来源gmac0/gmac1以太网通常不带走普通 AXI软件同步sdmmc/sdmmc2存储不一定看 SDK 版本dwmmc 控制器通过 IDMAC 访问内存vop显示控制器带通过 IOMMU 访问扫描内存vpu/rga视频编解码/图像加速带通过 IOMMU 访问usb3/dwc3不带dwc3 内部有缓存但主机侧仍需同步pcie视情况与 RC 的配置有关display-subsystem常见带显示链路整体一致性这个表不是绝对的因为 Rockchip 不同版本的 SDK 会调整设备树配置但整体趋势是需要经过 IOMMU 访问内存的多媒体外设倾向于配置dma-coherent而传统的网络、存储、USB 这类对实时性要求高、数据吞吐量大的设备大多不配置。3.2 为什么显示和视频编解码节点要配置 dma-coherent以 VOPVideo Output Processor显示控制器为例它需要不停地从内存中读取 framebuffer 数据以 60 帧每秒的速度输出到屏幕。一帧 1080p 的 RGBA 数据大概是 8MB 左右每秒要读 480MB 以上。如果每一帧都要靠 CPU 去维护 Cache 一致性开销是不可接受的。更重要的是显示通路上的 buffer 经常是由 GPU、CPU、VPU 等多个模块共同写入的。如果有任何一方写入后数据还留在 Cache 里没有被写回 DDRVOP 扫描到的就可能是旧帧或半新半旧的帧形成画面撕裂。所以 RK3566 的 VOP 节点不仅配置了dma-coherent还会配套iommus属性让显示控制器通过 IOMMU 来访问物理内存。这种情况下硬件通路保证了一致性驱动不用每次刷新都去做dma_sync_*操作。这也是 RK 平台显示性能的一个重要保障。3.3 为什么网卡和存储控制器通常不配置以太网 MACGMAC的工作模式是驱动把 sk_buff 的 DMA 地址写到 DMA 描述符中MAC 控制器自动从内存搬运数据。这个过程中如果硬件不保证一致就必须由驱动在每个包的发送/接收路径上做缓存同步。Rockchip 的 GMAC 节点在 DTS 中很少有dma-coherent因为它的 DMA 引擎不具备总线监听能力。驱动中使用dma_map_single()配合dma_unmap_single()和dma_sync_single_*()来保证正确性。如果贸然加上dma-coherent实际是告诉内核你不用做缓存同步了但硬件并没有这个能力包就会出错。同理SD/MMC 控制器走 IDMAC 传输数据DMA 描述符和数据缓冲区都必须与 CPU 的数据保持一致。如果错误配置dma-coherent最典型的症状就是写入 SD 卡的文件偶尔校验不对甚至出现 ext4 报错。3.4 rk3566-aiot 板级 DTS 中的实际形态在实际的 rk3566-aiot 板级 DTS 里你会看到这样的写法vop { status okay; assigned-clock-rates 594000000; }; vop_mmu { status okay; }; gmac0 { phy-mode rgmii-id; clock_in_out input; snps,reset-gpio gpio2 RK_PC4 GPIO_ACTIVE_HIGH; snps,reset-active-low; status okay; };注意这里vop是disabled的gmac0中没有任何dma-coherent配置。不是因为板级文件忘了写而是 SoC 级rk3566.dtsi已经继承了相关属性而 GMAC 是明确不需要dma-coherent的。很多人在移植时喜欢参考其他平台把 dma-coherent 全加上这是非常危险的习惯。4. 配置缺失或错误配置的故障现象与完整排查链路4.1 故障一以太网随机丢包iperf 吞吐量异常波动我先说一下这个真实案例。某块 RK3566 板子CPU 是高负载时网络丢包率明显上升iperf -u测试丢包率在 0.5% 到 8% 之间波动iperf -t的 TCP 吞吐量很不稳定有时 900Mbps 有时 400Mbps。排查的第一步是确认 GMAC 节点是否有dma-coherent。用命令查看设备树ls /proc/device-tree/gmac0/ cat /proc/device-tree/gmac0/dma-coherent 2/dev/null如果这个文件存在说明设备树里有这个属性。当时我们查到板级 DTS 中确实加上了dma-coherent原因是硬件工程师参考了另一颗平台的设计认为网卡要高性能所以加一致性配置——但实际上这颗 SoC 的 GMAC DMA 并不具备硬件 snoop 能力。定位过程就是对比验证把dma-coherent从 gmac0 节点删除重新编译 DTS烧录后网络恢复正常。为了更严谨又在另一块板子上反向测试不加dma-coherent时抓包然后加上后再抓包确认故障复现与配置的因果关系。这里要补充一个关键知识点**GMAC 的 DMA 描述符descriptor在 cacheable 内存中时如果硬件不保证一致性而软件又跳过了 cache 同步MAC 控制器读取描述符时很可能会读到过期的内容表现为发送队列卡死或随机丢包。**这种故障的偶发性很强和数据在缓存中的位置、访问时序都有关。4.2 故障二显示画面出现随机撕裂和残留另一个案例是显示链路。某块 RK3568 板子在使用 GPU 渲染后又通过 RGA 做格式转换屏幕上偶尔出现水平撕裂线严重时整个画面会有几帧的残留。排查链路是这样的先怀疑 GPU 和 RGA 驱动查看 dmesg 有无错误用v4l2-compliance和 modetest 工具做基本验证确认 framebuffer 的物理地址分配方式检查设备树中rga和vop节点的dma-coherent属性是否被改动过。最后发现是因为 RGA 节点被我们此前做功耗优化时误加了dma-coherentfalse设备树里没有dma-coherentfalse这种写法实际是错误地删除了该属性导致 RGA 驱动在每次 DMA 操作后没有做 cache invalidate上一次 GPU 写入的残留数据被 CPU Cache 保留RGA 读到旧数据。RK3566 的 RGA 走 IOMMU且硬件支持一致性。这个节点的dma-coherent是不能动的。恢复属性后撕裂和残留消失。4.3 一个系统的排查套路如果你在 RK3566 或类似 ARM 平台上遇到疑似 DMA 缓存一致性引发的随机故障可以按下面的步骤排查确认当前设备树的实际属性不要只看源码里的dtsi要直接查看运行中的设备树。/proc/device-tree/下的内容反映了实际生效的配置。在驱动里打印一致性状态写一个小的调试驱动或者在现有驱动中加打印输出dev_is_dma_coherent(dev)的值。确认内核实际感知到的状态。对照 SoC 手册确认硬件能力看该外设的 DMA 是否走 CCI/CMN 等一致性端口。若没有明确说明一般默认为非一致性不要轻易给设备添加dma-coherent。做二分对比验证只修改目标设备节点的dma-coherent属性其他不动。编一个只有这一处差异的内核和设备树上线对比测试。如果你拿到的是 Rockchip 官方 SDK最简单靠谱的方法是对比官方评估板的 DTS。官方版本通常经过大量测试节点属性不太会出错。自己做定制板时尽量保持这些属性不变。/proc/device-tree/vop/ 下存在的属性文件 compatible status reg interrupts clocks clock-names resets reset-names power-domains dma-coherent -- 存在即表示内核认为该设备 coherent iommus ...4.4 使用内核调试手段验证 cache 同步行为除了看故障现象还可以通过内核的 debug 接口验证驱动是否在执行 cache 同步操作。在开启了CONFIG_DMA_API_DEBUG的内核中DMA API 会做额外检查能侦测到例如map/unmap 次数不匹配同步方向使用错误这类问题。虽然它不能直接告诉你dma-coherent配得对不对但能帮你确认驱动与内核 DMA 子系统的交互是否符合预期。更直观的做法是用 ftrace 跟踪 DMA 同步函数echo dma_map_single /sys/kernel/debug/tracing/set_ftrace_filter echo function /sys/kernel/debug/tracing/current_tracer cat /sys/kernel/debug/tracing/trace观察某个设备操作期间是否有大量dma_direct_sync_single_for_device被调用。如果配置了dma-coherent还有大量这类调用说明内核没有生效如果没有配置但有大量调用说明同步操作本身就是导致性能下降的根源。5. 从 ARM DMA 子系统的底层设计看 dma-coherent 的边界条件5.1 一致性并不等于性能一定好听到硬件保证一致性时很多人的第一反应是那最好每个设备都配上。实际上并非如此。设备树里加不加dma-coherent最终决定的是 DMA 子系统的行为策略而不是外设本身的硬件质量。对于不支持一致性的硬件强行配置只会引入数据错误。对于支持一致性的硬件加上这个属性能够省去 cache 维护开销但并不意味着驱动就可以不正确使用 DMA API——依然要保证内存分配、映射、使用顺序是合理的。硬件一致性通常依赖于监听操作snoop而 snoop 本身也有功耗和带宽代价。但相比软件一次性 clean/invalidate 整块缓冲区硬件的按需监听粒度更细总体开销通常更低这也是为什么多媒体设备特别依赖这个特性。5.2 dev-dma_coherent 与 DMA 掩码的关系驱动初始化时通常会调用dma_set_mask_and_coherent()或dma_set_mask()设置 DMA 地址范围。这里容易混淆两个概念dma_mask决定了设备可访问的 DMA 地址范围dma_coherent决定设备与 CPU 的内存一致性策略。两者是独立的。即使设备配置了dma-coherent驱动依然要根据 SoC 的地址映射设置正确的 DMA 掩码。比如某个外设只能访问 32 位地址空间那么掩码就应该设置为DMA_BIT_MASK(32)与是否 coherent 没有关系。实际开发中我看到不少人把这两个概念混在一起导致修改掩码时顺带把dma-coherent也加了或删了引发连锁故障。5.3 IOMMU 介入后的一致性语义RK3566 的 VPU、RGA、VOP 等多媒体设备通常通过 IOMMU 访问内存。这种情况下设备发出的地址经过 IOMMU 转换成物理地址。IOMMU 对缓存一致性的影响要分两种情况如果 IOMMU 自身的页表遍历和转换过程不影响总线事务的一致性属性那么dma-coherent语义仍然有效如果使能了 IOMMU 且其配置强制改变了一致性属性那么即使设备树里配了dma-coherent实际硬件行为也可能不符合预期。这也是为什么 Rockchip SDK 中多媒体设备往往同时配置iommus和dma-coherent。这两者并不冲突它们解决的是不同层的问题IOMMU 解决地址转换和保护dma-coherent解决缓存一致性。由于 IOMMU 的存在运行时的 IOVA 可能与物理地址不同驱动通过 DMA API 拿到的dma_addr_t往往是 IOVA 而不是物理地址。此时如果要做调试不能直接把dma_addr_t当物理地址用需要经过 IOMMU 的地址转换反查。这类问题排查起来更容易绕建议先把 IOMMU 的日志打开# 使能 IOMMU debug echo 1 /sys/kernel/debug/iommu/arm-smmu/address # 路径因内核版本而异5.4 DMA 池与非一致性内存映射的底层处理对于非 coherent 设备dma_alloc_coherent()内部并不是每次都用 uncached 映射它更常见的方式是从 CMA 或 atomic pool 分配物理连续内存在页表中将这段内存映射为 uncached 或 write-through返回虚拟地址给 CPU返回 DMA 地址给设备。这样CPU 和 DMA 对同一段物理内存的访问都是绕过缓存或直写的从根上避免了一致性问题。这个方案对驱动代码来说是最省心的因为不需要每次操作都手动同步。但缺点是分配较慢且不适合高频 map/unmap 的流式场景。因此流式 DMAdma_map_single走的是另一个路径map 时不改变页表属性只做 cache cleanunmap 时做 invalidate。这也是dma-coherent属性影响最直接的地方。如果你的设备既不是真正硬件一致也没有走dma_alloc_coherent分配内存而是用dma_map_single做流式映射那么dma-coherent配置错误的影响会被放大很多倍。6. 实际开发中判断一个设备是否该配置 dma-coherent 的几条经验准则6.1 先查 SoC 手册再看 SDK 参考设计我第一次在正式项目里判断一个外设是否需要dma-coherent时遵循的顺序非常简单查 Rockchip 的 TRMTechnical Reference Manual中该外设的 DMA 章节看是否有 Cache Coherence、Snoop、Coherent Interface 之类的描述看官方 SDK 中该节点在rk3566.dtsi和评估板dts中的写法如果官方代码在不同 SDK 版本里有差异以与当前内核版本对应的 SDK 为准。大多数情况下第 3 步就可以给出明确结论。芯片原厂的设计是经过大量验证的不要去挑战它。6.2 依据外设工作特点区分两类设备可以把所有外设粗略分为两类长期驻留缓冲区型显示 framebuffer、编解码输入输出 buffer、GPU 资源。这类缓冲区生命周期长且经常被 CPU 和多个外设交替访问。如果硬件支持一致性强烈建议配置dma-coherent否则每个操作都同步缓存会严重影响性能。高频流式传输型网卡收发包、存储读写、USB 传输。这类数据流是一次性消费驱动使用完就释放。它们更适合流式 DMA API 软件同步的方式即使硬件支持一致性也未必需要配置dma-coherent因为逐包同步的开销在某些场景下反而可控。这是很多人在芯片选型和 DTS 编写时没有想过的问题dma-coherent不只是一个能开就开的性能开关它与驱动的 DMA 使用模型强相关。同一个外设驱动如果用dma_alloc_coherent分配长生命周期缓冲区和用dma_map_single做短生命周期映射对dma-coherent属性的敏感度完全不同。6.3 设备树中属性的继承与覆盖机制还有一个常见的坑dma-coherent属性是可以继承的。在设备树中如果一个父节点定义了dma-coherent而子节点没有显式覆盖内核解析时通常会继承父节点的一致性设置。usb_host0 { dma-coherent; /* 父节点配置了 */ usb_controller: usbff400000 { /* 子节点未配置 dma-coherent但可能继承父节点 */ }; };这种情况下如果你把dma-coherent加在了父节点上它的影响范围可能比预期大得多波及所有子设备。遇到过有人把dma-coherent加到了根节点上结果整个系统的外设都被视为 coherent引发各种偶发故障。排查到最后发现设备树根节点多了一行属性。所以遇到奇怪的 DMA 问题时除了看目标节点也要多看它上层的节点有没有配置。使用dtc反编译实际运行的设备树可以帮助你快速确认dtc -I fs -O dts /proc/device-tree -o current.dts grep -n dma-coherent current.dts | head -506.4 如果确定要修改按最小化原则操作如果你是在做定制板移植确实需要修改某个节点的dma-coherent配置尽量遵循最小化原则只修改目标外设节点不要动父节点、根节点只添加或删除dma-coherent;这一行不做无关改动修改后必须做完整回归测试重点是 DMA 密集型场景保留修改前后的 DTS 对比记录方便后续回溯。我曾经在一个项目里见过有人在优化性能时批量给所有dma-coherent相关的驱动打 patch结果把网络控制器的 DMA 缓冲区从一致性分配改成了流式映射又把设备树属性删了性能没提升多少反而引入了一堆随机崩溃。调试最后花了整整两周。7. 几个容易混淆的概念dma-coherent、dma-noncoherent、DMA_ATTR_NON_CONSISTENT 与缓存策略7.1dma-noncoherent属性是存在的Linux 设备树规范中除了dma-coherent还定义了dma-noncoherent属性。两者互斥如果同时出现以dma-noncoherent为准内核的实现里of_dma_is_coherent会先检查dma-noncoherent。不过实际项目中大多时候只要不写dma-coherent设备就默认被视为 non-coherent所以很少看到有人显式写dma-noncoherent。但在一些复杂的设备树中父节点可能配置了dma-coherent而子节点需要显式否定时就会用dma-noncoherent来覆盖parent { dma-coherent; child { dma-noncoherent; }; };这种情况在自定义硬件设计中并不罕见。理解这个覆盖关系能帮你避免父节点有 coherent子节点却表现异常这种问题。7.2 与DMA_ATTR_NON_CONSISTENT的关系dma_alloc_attrs()中有一个标志位DMA_ATTR_NON_CONSISTENT它表示这次分配的内存不需要保持一致性驱动可以在每次访问前手动同步。这个标志与设备树里有没有dma-coherent是两层概念设备树属性描述的是设备硬件特性DMA_ATTR_NON_CONSISTENT是一次具体分配的属性。即使设备被标记为 coherent驱动依然可以在某次分配时指定DMA_ATTR_NON_CONSISTENT内核会尊重这个请求返回一个可以手动同步的内存。反过来非 coherent 设备也可能因为内核的分配策略拿到一块映射为 uncached 的内存而天然保持一致。不过实际驱动代码中DMA_ATTR_NON_CONSISTENT用得并不算多大多设备依赖默认的 coherent / non-coherent 策略。知道它的存在主要是为了在阅读内核代码时不至于看到attrs参数就发懵。7.3 缓存策略 page attributes 与 dma-coherent 的关系ARM 架构下页表项的 MAIRMemory Attribute Indirection Register定义了不同的内存属性包括 Normal Cacheable、Normal Non-Cacheable、Device 等。DMA 内存是否使用 Cacheable 映射与设备的dma_coherent标志相关但不是完全等同。从源码角度dma_direct_alloc()中如果设备是 non-coherent会使用pgprot_dmacoherent()映射如果设备是 coherent则使用普通可缓存映射。这里的关键在于同为 non-coherent 设备如果分配的内存物理地址落在某个自定义映射区域页表属性可能也不同。调试时如果你的驱动直接访问phys_to_virt()转换出来的地址而不是使用 DMA API 返回的虚拟地址就容易绕过内核正常的缓存属性设置产生莫名其妙的问题。7.4 一块内存被多个设备共享时的配置注意点如果一块内存同时被 CPU、一个 coherent 设备和一个 non-coherent 设备使用事情会变得复杂。此时不能简单依赖设备树的dma-coherent驱动必须在每次设备切换访问时主动做必要的同步否则会有隐患。举个例子一个视频编码器VPUcoherent输出 buffer同时被 USB gadgetnon-coherent读取。VPU 写入后驱动不能只依赖 VPU 的一致性保证还需要在 USB 的 DMA 操作前把数据同步到内存中可见。这提醒我们dma-coherent只是描述了设备和 CPU 之间的关系。当多个设备共享内存时你还得考虑设备之间的关系软件必须做出额外处理。8. 实测验证方法如何确认 dma-coherent 配置对性能的影响8.1 一个可以复现的网络性能对比实验我之前在做 RK3566 的验收测试时专门设计过一个验证dma-coherent影响的实验分享出来供大家参考。实验平台是一块 RK3566 开发板系统版本为 Linux 5.10测试对象是 GMAC0 千兆网卡。测试步骤先保持官方 DTS 默认配置不带dma-coherent使用iperf3 -c server -t 60测 TCP 吞吐量再在gmac0节点添加dma-coherent;重新编译 DTS 并烧录重复同一测试记录两组数据对比并观察dmesg中是否有 DMA 相关错误同时用ethtool -S eth0查看网卡的错误计数。结果是带dma-coherent时吞吐量明显下降且tx_dropped、rx_crc_errors等计数器异常。这里不给出具体数字因为不同内核版本、不同 DTS 配置下的表现会有所差异。重点是通过这样的 A/B 对比实验你可以明确掌握该外设在当前平台上的一致性行为。8.2 通过 ftrace 观察 cache 同步开销如果你不确定某条路径上 cache 同步到底花了多少时间可以用 ftrace 的 function_graph 跟踪特定函数echo p:myprobe dma_direct_sync_single_for_device /sys/kernel/debug/tracing/kprobe_events echo 1 /sys/kernel/debug/tracing/events/kprobes/myprobe/enable或者用 perf 直接采样perf record -e cache-misses -ag -- sleep 10 perf report如果dma_direct_sync_single_for_device频繁出现在热点路径上说明设备没有享受硬件一致性驱动正在花费大量时间做软件同步。这未必是问题——如果硬件本身不支持一致性这是正常行为但如果硬件支持而你期望的是更高性能就需要确认 DTS 中是否遗漏了dma-coherent。8.3 用 dmesg 和内核日志确认一致性状态内核在设备初始化时会打印一部分设备信息。在驱动中主动打印dev_is_dma_coherent是最直接的确认方式static int my_probe(struct platform_device *pdev) { struct device *dev pdev-dev; dev_info(dev, coherent: %d\n, dev_is_dma_coherent(dev)); dev_info(dev, dma_mask: %llx\n, (unsigned long long)*dev-dma_mask); return 0; }运行后通过dmesg | grep coherent就能确认内核是否如预期地认为该设备是 DMA 一致的。对比设备树里是否真的有dma-coherent属性可以快速发现解析问题。8.4 压测工具与场景建议在确认 DMA 一致性配置是否稳定时建议覆盖以下压力场景网络iperf3 -u -b 1000M -t 300长时间 UDP 打流观察丢包率存储fio --rwrandwrite --bs4k --size1G --numjobs4 --runtime60随机写观察 IO 错误显示连续播放视频 2 小时以上观察是否有花屏、撕裂多媒体gst-launch-1.0 v4l2src ! mpph264enc ! fakesink持续编码 30 分钟观察是否有输入输出错误。只有压测通过修改才算真正安全。偶发性缓存一致性问题的特点就是概率低、复现难一次两次测试通过很可能只是运气好。9. 回到最初的问题dts 中某设备配置 dma-coherent 到底起什么作用把前面所有内容收拢成一句话就是dma-coherent告诉内核这个设备在 DMA 访问内存时硬件已经保证了与 CPU 缓存的一致性内核无需为它做软件的 Cache 同步操作驱动走的是一致性高速通道。具体到 RK3566 这类平台上对于 VOP、RGA、VPU 这类硬件确实支持一致性的多媒体外设配置dma-coherent是必需的少了会花屏、撕裂、性能暴跌对于 GMAC、SDMMC 这类走普通 AXI、依赖软件维护一致性的外设配置dma-coherent是错误的多了一定会出现随机数据错误在设备树里增删这一行属性必须建立在对硬件能力的准确理解上不能凭感觉或参考不相关平台的设计。下次再看到设备树里某个节点下面挂着dma-coherent;就不只是知道这行是干嘛的的层面而是要能判断出这颗 SoC 的哪个总线端口为这个设备提供了硬件一致性驱动是长生命周期驻留缓冲区还是高频流式映射这个配置如果错了最可能的故障模式是什么把这三个问题想清楚DTS 里的这一行字对你来说才算是真正读懂了。