4. 调度与DMA协同：DMA完成中断与任务唤醒机制、调度延迟对DMA传输的影响

DMA传输本身是硬件在跑，CPU基本不参与。但传输结束那一刻，CPU必须知道——这就是DMA完成中断的作用。中断来了，任务被唤醒，数据被处理。这个链条看似简单，实际坑很多。

我调过不少系统，发现很多人只关注DMA的带宽，却忽略了中断到任务唤醒这段路径上的延迟。说白了，DMA再快，如果CPU响应慢，整个系统的吞吐量还是上不去。

4.1 DMA完成中断的处理流程

一个典型的DMA传输完成后的软件处理路径是这样的：

1. DMA控制器完成传输，硬件置位完成标志位
2. DMA控制器向中断控制器（GIC/APIC）发送中断信号
3. 中断控制器将中断分发给某个CPU核心
4. CPU保存当前上下文，跳转到中断服务例程（ISR）
5. ISR中清除中断标志，可能做数据搬运
6. ISR退出，触发调度器检查是否有高优先级任务就绪
7. 调度器选择下一个任务执行，完成上下文切换

这里面每一步都有开销。我见过一个项目，DMA传输本身只花了50微秒，但从中断产生到任务真正拿到数据，却用了200微秒。问题出在哪？出在第4步到第7步之间的调度延迟上。

4.2 中断响应延迟的构成

中断响应延迟不是固定的。它受几个因素影响：

因素	典型延迟范围	说明
中断屏蔽时间	0.5 - 10 μs	CPU关中断执行临界区代码
中断优先级仲裁	0.1 - 1 μs	多个中断同时到达时的排队
CPU流水线排空	0.2 - 2 μs	保存现场、跳转到ISR
ISR执行时间	1 - 50 μs	取决于ISR的复杂度

我曾经在一个ARM Cortex-A72平台上测过，如果CPU正在执行一个长周期的原子操作（比如spinlock持有期间），DMA中断可能被延迟几十微秒。嗯，这里要注意——不是所有中断都能立即响应。

4.3 调度延迟：被忽视的瓶颈

ISR退出后，数据已经在了，但任务还没跑。为什么？因为调度器需要时间来决定下一个该跑谁。

调度延迟包括：

• 调度器执行时间：遍历就绪队列、计算优先级、选择下一个任务
• 上下文切换时间：保存当前任务寄存器、加载新任务寄存器、刷新TLB
• 缓存预热时间：新任务的代码和数据不在缓存中，需要从内存加载

我调过一个视频采集系统，DMA把一帧图像数据搬到了内存，ISR只用了3微秒就退出了。但任务被唤醒后，第一次访问数据时发生了大量cache miss，导致处理时间暴增。这就是典型的“调度延迟后遗症”——任务虽然醒了，但缓存是冷的。

4.4 中断下半部与任务唤醒机制

Linux内核中，DMA完成中断的处理通常分为上半部和下半部：

• 上半部（ISR）：快速处理，清除中断标志，记录状态，唤醒下半部
• 下半部（Tasklet/Softirq/Workqueue）：处理数据，唤醒等待数据的用户态任务

为什么这么分？因为ISR中不能睡眠，不能持有锁太久。而数据搬运、协议解析这些操作可能需要较长时间。

我见过一个糟糕的设计：ISR里直接做了memcpy，把DMA缓冲区数据复制到用户缓冲区。这个memcpy耗时80微秒，期间其他中断都被阻塞了。后来改成在workqueue里做复制，系统响应就好了很多。

4.5 调度延迟对DMA传输的影响模型

我们可以用一个简单的模型来分析调度延迟的影响：

DMA传输周期 = T_dma + T_int + T_sched + T_proc

其中：
T_dma  = DMA硬件传输时间
T_int  = 中断响应延迟
T_sched = 调度延迟（ISR退出到任务开始执行）
T_proc = 任务处理数据的时间

如果DMA是周期性传输（比如音频采样、视频帧），那么整个周期的上限决定了系统的实时性。调度延迟T_sched如果占比较大，就会压缩T_proc的时间窗口，甚至导致数据覆盖。

举个例子：一个音频系统每125微秒产生一个DMA传输完成中断。如果T_int + T_sched = 40微秒，留给T_proc的时间只有85微秒。一旦调度延迟波动到60微秒，任务就可能来不及处理，出现断音。

4.6 优化策略：减少调度延迟

针对调度延迟，我总结了几条实用的优化策略：

1. 优先级继承与提升：将处理DMA数据的任务优先级提高，减少被其他任务抢占的概率
2. CPU亲和性绑定：将DMA中断和数据处理任务绑定到同一个CPU核心，减少缓存迁移
3. 使用实时调度策略：在Linux中改用SCHED_FIFO或SCHED_RR，避免CFS的公平调度带来的延迟
4. 减少ISR执行时间：ISR只做最必要的事，其余交给下半部
5. 预分配与零拷贝：避免在中断路径中分配内存，使用预分配的DMA缓冲区

我记得有一次优化一个网络数据采集系统，把中断处理任务的调度策略从SCHED_OTHER改成SCHED_FIFO后，调度延迟从平均35微秒降到了8微秒。效果非常明显。

4.7 调度与DMA协同的典型流程

下面这张图展示了DMA传输完成后，从中断产生到任务处理数据的完整流程：

4.8 实测数据：调度策略对DMA传输延迟的影响

我在一个实际项目中做过对比测试，平台是ARM Cortex-A53四核，Linux 5.10内核，DMA传输64KB数据。结果如下：

调度策略	平均调度延迟	最大调度延迟	DMA总周期
SCHED_OTHER (CFS)	32 μs	128 μs	185 μs
SCHED_FIFO (优先级50)	8 μs	22 μs	161 μs
SCHED_RR (时间片10ms)	9 μs	25 μs	162 μs
SCHED_FIFO + CPU亲和性	5 μs	12 μs	158 μs

可以看到，仅仅把调度策略从CFS改成FIFO，调度延迟就降到了原来的四分之一。再加上CPU亲和性绑定，最大延迟控制在12微秒以内。对于实时性要求高的系统，这个优化非常值得做。

4.9 总结：协同设计的要点

调度与DMA的协同，说白了就是让数据从硬件到应用程序的路径尽可能短、尽可能可预测。我个人的经验是：

• 先测量，再优化。用ftrace或perf抓出中断响应和调度延迟的实际数据
• ISR要短，下半部要快，任务优先级要合理
• 缓存亲和性比想象中更重要——冷缓存带来的延迟可能比调度本身还大
• 实时调度策略不是银弹，但大多数场景下效果显著

嗯，这一章的内容就到这里。调度延迟这个坑，我踩过不止一次，希望你能少走弯路。