2. Linux实时性挑战
嵌入式 Linux 在实时场景下面临的核心矛盾在于：通用内核为追求高吞吐与公平调度，引入了大量不可抢占的临界区与关中断操作，导致任务唤醒、中断响应与上下文切换的延迟不可控。本章从调度器演进、抢占模型分级与延迟来源三个维度，系统梳理实时性瓶颈的根因。
关键认知： 实时性不是“快”，而是“可预测的延迟上限”。PREEMPT_RT 的目标是将最坏情况延迟从数十毫秒压缩到数百微秒以内。
2.1 Linux 内核调度器演进
调度器决定了 CPU 资源如何在多个任务间分配。实时性要求调度器支持优先级抢占、低切换开销与可预测的调度点。
| 调度器版本 | 内核版本 | 核心算法 | 实时性特征 |
|---|---|---|---|
| O(n) 调度器 | 2.4 及之前 | 全局循环扫描 runqueue | 无实时支持，O(n) 复杂度，不可预测 |
| O(1) 调度器 | 2.6.0 ~ 2.6.22 | 优先级位图 + 双 runqueue | O(1) 复杂度，支持 SCHED_FIFO/RR |
| CFS (完全公平调度) | 2.6.23 起 | 红黑树 + 虚拟运行时间 vruntime | 公平优先，实时任务仍依赖 SCHED_FIFO/RR |
| RT 调度类增强 | 3.14 起 | RT group scheduling + bandwidth control | 防止实时任务饿死，支持 throttling |
| PREEMPT_RT 完全抢占 | 5.x / 6.x (主线合入中) | 所有自旋锁可抢占 + 中断线程化 | 最坏情况延迟 < 200μs (x86) |
演进主线： 从 O(n) → O(1) → CFS 解决了调度复杂度问题；从 PREEMPT_NONE → PREEMPT_RT 解决了内核态不可抢占问题。两者共同决定了实时任务的响应延迟。
2.2 内核抢占模型：四种配置对比
Linux 内核提供四种抢占模型，从“几乎不抢占”到“完全实时抢占”，决定了内核态代码被高优先级任务打断的时机与粒度。
| 抢占模型 | 内核配置宏 | 抢占点 | 最坏情况延迟 | 适用场景 |
|---|---|---|---|---|
| PREEMPT_NONE | CONFIG_PREEMPT_NONE | 仅系统调用返回 / 显式调度点 | 10 ~ 100 ms | 服务器、桌面、批处理 |
| PREEMPT_VOLUNTARY | CONFIG_PREEMPT_VOLUNTARY | 系统调用返回 + 显式 cond_resched() | 1 ~ 10 ms | 轻度实时需求的嵌入式 |
| PREEMPT (全称 PREEMPT_LL) | CONFIG_PREEMPT | 系统调用返回 + 内核态几乎所有显式抢占点 | 200 μs ~ 1 ms | 低延迟桌面、软实时嵌入式 |
| PREEMPT_RT | CONFIG_PREEMPT_RT | 所有自旋锁替换为可抢占的 rt_mutex + 中断线程化 | 50 ~ 200 μs | 硬实时工业控制、机器人、航空 |
常见误区： 即使启用 PREEMPT_RT，如果应用程序使用 SCHED_OTHER（非实时调度策略），仍然无法获得确定性延迟。实时性 = 抢占模型 + 调度策略 + 中断处理方式三者的组合。
2.3 中断延迟与调度延迟来源
实时性测试的核心是测量两类延迟：中断延迟（Interrupt Latency）和 调度延迟（Scheduling Latency）。两者共同决定了任务从事件发生到开始执行的总响应时间。
2.3.1 中断延迟来源
中断延迟 = 硬件延迟 + 内核关中断时间 + 中断处理程序执行时间。
- 硬件延迟： 中断控制器仲裁、CPU 流水线冲刷、缓存缺失，通常固定且较小（几十 ns ~ 几 μs）。
- 内核关中断时间： 最关键的不可控因素。在 PREEMPT_NONE 下，驱动或内核路径可能长时间调用
local_irq_disable()，导致中断被屏蔽数百 μs 甚至数 ms。 - 中断处理程序执行时间： 传统 top-half 处理程序在关中断上下文中执行，若处理逻辑复杂，会阻塞后续中断。
PREEMPT_RT 的解决： 将中断处理程序强制线程化（threaded IRQ），使中断处理在可抢占的内核线程中执行，关中断区间仅保留在硬件上下文切换的最小窗口内（通常 < 10 μs）。
2.3.2 调度延迟来源
调度延迟 = 中断处理完成 → 调度器选择下一个任务 → 上下文切换完成的时间。
| 延迟来源 | 描述 | 典型影响范围 | PREEMPT_RT 优化 |
|---|---|---|---|
| 自旋锁持有时间 | 低优先级任务持有锁，高优先级任务忙等 | 10 ~ 500 μs | rt_mutex 支持优先级继承，避免优先级反转 |
| 关抢占区间 | 内核路径调用 preempt_disable() 后不可被抢占 | 50 ~ 1000 μs | 最小化关抢占区间，替换为可睡眠锁 |
| RCU 宽限期 | RCU 同步等待所有读者退出 | 100 μs ~ 10 ms | RCU 可抢占 (PREEMPT_RCU) |
| TLB 刷新生效 | 上下文切换时 TLB 失效导致后续指令延迟 | 1 ~ 10 μs | 大页 / 减少进程切换频率 |
| 缓存污染 | 频繁上下文切换导致 L1/L2 缓存失效 | 5 ~ 50 μs | CPU 隔离 + 任务绑定 |
2.4 优先级反转与实时性恶化
优先级反转（Priority Inversion）是实时系统中经典的延迟恶化场景：低优先级任务持有高优先级任务所需的资源，导致高优先级任务被阻塞，而中等优先级任务抢占 CPU 使低优先级任务无法释放资源。
经典案例： 1997 年火星探路者（Mars Pathfinder）因优先级反转导致系统频繁复位。修复方案正是优先级继承协议（Priority Inheritance Protocol），这也是 PREEMPT_RT 中 rt_mutex 的核心机制。
PREEMPT_RT 通过以下机制解决优先级反转：
- rt_mutex 优先级继承： 当高优先级任务等待低优先级任务持有的锁时，低优先级任务临时继承高优先级任务的优先级，避免被中等优先级任务抢占。
- 可睡眠自旋锁： 传统 spin_lock 在等待时忙等且关抢占，rt_mutex 在等待时睡眠并让出 CPU，允许其他任务运行。
2.5 本章小结
- Linux 调度器从 O(n) 演进到 CFS，解决了调度复杂度问题，但实时性仍依赖抢占模型与调度策略的组合。
- 四种抢占模型（NONE / VOLUNTARY / PREEMPT / PREEMPT_RT）在内核态可抢占范围上逐级增强，PREEMPT_RT 通过锁替换与中断线程化实现所有临界区可抢占。
- 中断延迟主要来自内核关中断区间，调度延迟主要来自自旋锁竞争、关抢占区间与 RCU 宽限期。
- 优先级反转是实时性恶化的典型场景，PREEMPT_RT 通过 rt_mutex 优先级继承机制提供有界延迟保证。
下一阶段： 在掌握延迟来源后，第 3 章将介绍如何用 cyclictest、hackbench、ftrace 等工具实际测量这些延迟，并建立实时性基准测试流程。