1. 课程导入

在嵌入式 Linux 与服务器 Linux 驱动开发中，DMA（Direct Memory Access，直接内存访问）是决定数据搬运吞吐量的关键机制。当网卡、NVMe、PCIe 采集卡、摄像头或串口高速设备需要持续搬运大量数据时，CPU 逐字节拷贝的方式会迅速成为瓶颈。DMA 让外设与内存之间直接传输数据，CPU 只负责配置描述符、启动通道和处理完成中断，从而把宝贵的算力留给协议栈、业务逻辑和用户态应用。

然而，“用了 DMA”并不等于“高吞吐”。很多驱动在功能上完全正确，却在压力测试中表现出吞吐上不去、CPU 占用异常、延迟抖动大、偶发丢包或数据损坏等问题。本课程的目标，是建立一套从性能指标到硬件机制、从驱动代码到内核工具的完整分析方法，让你能够定位 DMA 传输链路上的真实瓶颈，并给出可验证的优化方案。

核心概念：DMA 传输链路上的五个关键对象

理解 DMA 性能，首先要建立“数据从设备到用户态”的完整路径模型。这条路径上通常存在五个关键对象：设备（发起或接收 DMA 的硬件）、DMA 控制器或设备自带 DMA 引擎、物理内存缓冲区、CPU cache 与 IOMMU/SMMU、以及驱动中的描述符环与中断处理。任何一个环节配置不当，都会让理论带宽大打折扣。

例如，流式 DMA 映射（dma_map_single）如果忘记在传输前后正确同步（dma_sync_single_for_device / for_cpu），就可能读到 cache 中的旧数据；描述符环过浅会导致设备频繁等待驱动补充缓冲区；中断合并参数过于激进则会增加单次延迟，过于保守又会推高 CPU 中断开销。这些都不是“写对功能”能自动解决的问题，而是性能分析要覆盖的对象。

方法流程：从指标到验证的闭环

性能分析最忌讳“凭感觉改参数”。推荐按以下流程推进：

1. 建立基线指标：明确吞吐（MB/s 或 Gb/s）、平均延迟、P99 延迟、CPU 占用率、中断频率。没有基线，任何优化都无法判断是否有效。
2. 观测链路：用 perf top 看热点函数，用 ftrace 跟踪 dma_map_*、dma_sync_* 调用频次，用 /proc/interrupts 观察中断分布。
3. 定位瓶颈：判断是内存带宽、cache 一致性、描述符环深度、IOMMU 映射开销，还是中断处理过重。
4. 参数调优：调整中断合并、NAPI 权重、描述符环大小、DMA 掩码、CPU 亲和性、预取策略。
5. 回归验证：在相同压力模型下复测，确认吞吐提升且延迟未恶化，并记录配置差异。

# 典型观测命令示例
cat /proc/interrupts | grep -E "eth|nvme|dma"
perf top -g -p $(pgrep -f your_driver)
echo 1 > /sys/kernel/debug/tracing/events/dma/enable
cat /sys/kernel/debug/tracing/trace_pipe
ethtool -S eth0 | grep -E "rx_|tx_|drop|err"

案例场景：一次网卡吞吐不达标的排查

某千兆网卡在 iperf3 测试中只能跑到 420 Mb/s，CPU 单核 softirq 占用接近 90%。初步怀疑是中断过多。通过 /proc/interrupts 发现所有 RX 中断都集中在 CPU0，且每秒中断数超过 8 万次。进一步用 ftrace 观察，发现驱动每次中断只处理一个描述符，没有启用 NAPI 轮询合并。调整中断合并参数并启用 NAPI 后，中断数降到每秒 1.2 万次，吞吐提升到 910 Mb/s，CPU 占用降到 35%。这个案例说明：DMA 性能问题往往不在 DMA 本身，而在中断与轮询的配合策略。

误区与复盘