很多人排查 Linux 实时性问题时，第一反应通常是看这些地方：
• 调度器
• 线程优先级
• 绑核策略
• cyclictest 结果
• CPU 负载
这些当然重要。
但现场还有一个经常被低估、却能直接把系统时序拖垮的因素：
驱动。
驱动不是简单的“把硬件跑起来”。它经常站在系统最靠前、最敏感的位置：
• 中断路径
• DMA 路径
• 线程唤醒路径
• 锁竞争路径
• 内核和设备交界路径
所以驱动一旦写得不好，坏掉的往往不是局部性能，而是：
整台系统的实时性。
一句话先讲明白
驱动会毁掉实时性，不是因为它“代码慢一点”，而是因为它常常运行在最靠前、最容易打断别人、最容易制造等待和尖峰的位置；一旦中断、锁、DMA、唤醒这些路径写重了，高优先级实时线程也会被直接拖慢。
第一，为什么驱动对实时性影响特别大？
普通应用线程慢了，通常只影响自己。
驱动慢了，影响的可能是：
• 中断响应
• 线程唤醒
• DMA 完成处理
• 内核关键路径
• 共享资源访问
• 高优先级任务的运行时机
也就是说，驱动经常站在“别人开始干活之前”。
如果驱动在前面卡住，后面的实时线程即使优先级再高，也只能等。
所以很多实时问题表面看是：
线程没按时跑。
但根子可能是：
驱动把线程该运行之前的路径拖长了。
第二，最常见问题一：中断处理太重
驱动最典型的问题就是：
ISR 里做得太多。
比如在中断里做这些事：
• 大量循环
• 大块数据处理
• 复杂状态机
• 长时间寄存器轮询
• 大量日志打印
• 本该放到线程里的业务逻辑
这类写法对实时系统伤害很直接：
中断路径一变长，其他线程就更难及时运行。
现场表现通常是：
• 周期线程晚醒
• 调度延迟增大
• 偶发尖峰明显
• 高优先级线程被前置工作挡住
实时驱动的基本原则是：
中断顶部只做最少必要动作，能后移的全部后移。
在 PREEMPT_RT 系统里，大部分中断会线程化，但这不代表中断处理可以随便写重。中断线程如果优先级、绑核、持锁设计不好，一样会压住关键实时任务。
第三，最常见问题二：关中断和禁止抢占时间太长
实时系统最怕的不是平均慢，而是某些路径突然不能被打断。
驱动里常见的危险写法包括：
• 长时间 local_irq_disable()
• 大范围 preempt_disable()
• 长临界区
• 关中断后做复杂逻辑
• 关中断后访问慢设备
• 关中断后打印日志
这些操作会直接扩大系统的不可抢占时间。
结果就是：
实时线程明明优先级最高，但内核当前这段代码不能被抢占，它也只能等。
所以判断驱动是否破坏实时性，不能只看 CPU 占用，还要看：
最长关中断时间、最长禁止抢占时间、最长持锁时间。
这些才是真正决定最坏延迟的关键指标。
第四，最常见问题三：锁设计太差
驱动里有共享资源很正常，问题在于很多驱动锁用得太重。
典型坏味道包括：
• 持锁范围太大
• 锁里做复杂逻辑
• 锁里做 I/O
• 锁里等待硬件状态
• 中断路径和线程路径共用重锁
• 低优先级上下文长期持锁
这类问题出现后，后果通常不是“锁效率低一点”，而是：
高优先级实时线程被驱动里的等待链拖住。
如果再叠加中优先级线程抢占，就可能形成优先级反转。
所以很多问题看起来像调度器不稳定，本质其实是：
驱动锁设计把实时线程堵住了。
实时驱动里，锁要遵守三条原则：
• 锁范围要小
• 锁内逻辑要短
• 锁内不要做慢操作
第五，最常见问题四：唤醒路径不干净
很多实时线程不是自己凭空运行，而是靠驱动事件唤醒。
比如：
• 中断到了
• DMA 完成了
• 数据到齐了
• 设备状态变化了
如果驱动唤醒路径写得拖泥带水，实时线程就会醒晚。
常见问题包括：
• 事件到了但没有第一时间唤醒
• 唤醒前做了大量无关处理
• 唤醒条件判断复杂且不稳定
• 驱动线程和业务线程职责混在一起
• 多层 workqueue 转发导致延迟不可控
这类问题最容易误导排查方向。
表面看是：
实时线程自己醒晚了。
实际可能是：
驱动没有及时把它唤醒。
所以实时系统里，驱动事件路径要尽量直接：
事件确认后，先唤醒关键线程；非关键处理后移。
第六，最常见问题五：DMA 路径不稳
DMA 本来是为了减轻 CPU 负担，但驱动写不好时，DMA 也会制造实时性问题。
常见坑包括：
• DMA 完成处理太长
• cache 同步时机混乱
• DMA buffer 管理混乱
• 运行时频繁申请释放 DMA 内存
• 完成中断打到关键实时核
• DMA 回调里夹带大量业务处理
这类问题的特点通常是：
平时能跑，偶尔慢。
因为 DMA 相关开销并不总是稳定的。一旦实时线程依赖这条路径，系统就容易出现抖动和尖峰。
所以 DMA 不是天然实时友好。
关键在于：
DMA buffer 要提前准备，完成路径要短，cache 同步要明确，IRQ 亲和性要避开关键实时核。
第七，最常见问题六：关键路径里做不可预测操作
实时系统最怕长尾。
驱动关键路径里尤其要避免这些操作：
• 动态内存分配
• 大量日志打印
• 字符串格式化
• 复杂错误恢复
• 运行时创建对象
• 长时间等待设备状态
• 扫描式查找和大块拷贝
这些操作平时可能没问题，但一旦落在中断、唤醒、DMA 完成、实时数据路径上，就会带来不可预测延迟。
对实时系统来说，真正危险的不是平均耗时，而是：
偶发最长耗时。
所以驱动热路径必须保持可预测。
第八，怎么判断是不是驱动拖垮了实时性？
如果看到下面这些现象，就要重点怀疑驱动：
• 某个设备一工作，系统就开始抖
• 停掉设备或驱动后，实时性明显变好
• cyclictest 空闲时正常，设备忙时尖峰明显
• 高优先级线程超时总和某类硬件事件相关
• 某个 IRQ 在关键 CPU 上特别活跃
• 延迟尖峰总跟在驱动回调或中断处理之后
• ftrace 里能看到长时间 irq-off、preempt-off 或持锁等待
这类问题有一个共同点：
不是系统一直差，而是设备一参与，系统才开始差。
这时不要只调线程优先级，要把驱动路径拉出来看。
第九，应该怎么查？
工程上不要只看一个 cyclictest 数字。
更有效的是把延迟链拆开：
• 看 /proc/interrupts，确认 IRQ 是否打到关键核
• 用 cyclictest 对比设备空闲和设备忙两种场景
• 用 ftrace 看 irqsoff、preemptoff、wakeup
• 用 rtla timerlat 或 rtla osnoise 看内核噪声来源
• 看驱动中断、DMA 完成、唤醒、持锁路径耗时
• 对关键路径加时间戳，确认尖峰发生在哪一段
排查重点不是问“哪个线程慢”，而是问：
实时线程为什么没能在该运行的时间点运行？
很多答案都藏在驱动里。
第十，怎么避免驱动毁掉实时性？
最有效的做法就几条。
1. 中断顶部要短
ISR 只做确认事件、清中断、保存必要状态、唤醒后续处理。
复杂逻辑放到线程或专门的实时任务里。
2. 少关中断，少禁止抢占
必须关的时候，范围要极短。
不要在关中断或禁止抢占区里做 I/O、日志、循环等待。
3. 锁要短、轻、清晰
锁内不要放慢操作。
中断路径、实时线程路径、后台路径不要随便共用一把大锁。
4. 唤醒路径要直接
事件到了，尽快唤醒关键实时线程。
统计、诊断、日志、状态整理后移。
5. DMA 路径要稳定
DMA buffer 提前分配，完成处理保持短路径，IRQ 亲和性避开关键核。
6. 关键路径不要做动态分配和重日志
这些操作最容易制造偶发长尾。
7. 驱动设计要和实时线程模型一起看
不能只看驱动功能是否正常，还要看它会不会拖慢上层周期线程。
最后一句话记住
驱动写得不好，会直接毁掉 Linux 实时性，不是因为它自己多占了几微秒，而是因为它卡在中断、唤醒、DMA、锁竞争、关中断这些最靠前的关键路径上；这些路径一旦变重、变乱、变得不可抢占，高优先级实时线程的时序就会被直接打碎。
