4. PREEMPT RT补丁原理
在工业控制、机器人、运动控制与测试测量等场景中，Linux 常被要求承担“硬实时”任务：控制周期可能只有 100 μs～1 ms，抖动必须稳定在几十微秒以内。主线 Linux 虽然吞吐与通用性极强，但其内核设计优先考虑平均性能与公平性，并不保证最坏情况下的响应时间。PREEMPT RT（Real-Time）补丁正是为弥补这一差距而诞生的一套系统性改造，它把 Linux 内核中大量“不可抢占”的区域改造成可抢占，从而把最坏调度延迟从毫秒级压到几十微秒级。
一、历史脉络：从“抢占补丁”到主线合入
PREEMPT RT 的前身可以追溯到 2000 年代初的“Preemptible Kernel”与 Ingo Molnar 的 -rt 树。早期 Linux 只有用户态可抢占，内核态一旦进入自旋锁或中断处理，就必须运行到退出点，导致高优先级任务被低优先级任务阻塞。2004 年前后，-rt 补丁开始引入“可抢占自旋锁”和“中断线程化”两大核心机制。此后十余年，Thomas Gleixner、Sebastian Andrzej Siewior 等人持续维护，逐步把通用锁原语、定时器、RCU、per-CPU 变量等子系统改造成实时友好形式。
2024 年，PREEMPT_RT 的主要机制正式合入 Linux 6.12 主线，成为可配置的抢占模型之一。这意味着实时 Linux 不再必须依赖外部补丁树，但理解其原理仍然关键：只有知道哪些路径会引入延迟，才能正确配置内核、编写驱动并测量抖动。
二、核心思想：把“不可抢占”变成“可抢占”
实时性的本质不是“快”，而是“可预测”。主线 Linux 的延迟来源主要有四类：自旋锁临界区、中断处理、软中断与 tasklet、以及关抢占/关中断的短临界区。PREEMPT RT 的核心思想是：尽可能缩短任何不可抢占窗口，并让高优先级任务能在任意时刻抢占低优先级任务。具体手段包括：
- 自旋锁睡眠化：把 spinlock_t 替换为可睡眠的 rt_mutex，持锁期间允许抢占，避免忙等。
- 中断线程化：把大部分硬中断处理程序转为内核线程，赋予实时优先级，可被更高优先级任务抢占。
- 软中断与 tasklet 线程化：把 softirq、tasklet 移入 ksoftirqd 等线程上下文，减少不可控的延迟尖峰。
- 优先级继承：rt_mutex 支持优先级继承，缓解优先级反转。
- 高精度定时器与时钟源改造：让定时器到期处理可抢占，降低周期性任务抖动。
三、与主线 Linux 的差异对比
主线 Linux 提供 PREEMPT_NONE、PREEMPT_VOLUNTARY、PREEMPT_DYNAMIC 等模型，它们只影响内核态抢占点密度，并不改变自旋锁与中断的不可抢占本质。PREEMPT RT 则是一个完整的实时化改造，二者差异如下表所示。
| 维度 | 主线 Linux | PREEMPT RT |
|---|---|---|
| 自旋锁 | 忙等，关抢占 | rt_mutex，可睡眠、可抢占 |
| 硬中断 | 直接执行，不可抢占 | 线程化，可被高优先级抢占 |
| 软中断/tasklet | 在中断退出点批量执行 | 线程化到 ksoftirqd |
| 优先级反转 | 无系统级继承 | rt_mutex 优先级继承 |
| 最坏延迟 | 毫秒级，抖动大 | 几十微秒级，抖动小 |
| 吞吐代价 | 高 | 略低，上下文切换增多 |
四、主要改造点与配置方法
在工程中启用 PREEMPT RT，通常需要选择带 RT 支持的内核源码或 6.12+ 主线内核，并在配置阶段打开关键选项。典型配置如下：
# 内核配置关键项
CONFIG_PREEMPT_RT=y
CONFIG_HIGH_RES_TIMERS=y
CONFIG_PREEMPTION=y
CONFIG_RT_MUTEXES=y
CONFIG_DEBUG_PREEMPT=n # 生产环境关闭高开销调试
# 查看当前抢占模型
uname -a
cat /sys/kernel/realtime # 1 表示 RT 内核
# 实时任务示例：设置 SCHED_FIFO 优先级 80
chrt -f 80 ./motion_control驱动开发者需要特别注意：在 RT 内核中，普通 spin_lock 已变为可睡眠锁，因此不能在原子上下文（如硬中断、不可睡眠区域）中调用可能睡眠的函数；应使用 raw_spinlock_t 保护真正必须原子执行的短临界区。此外，中断线程化后，中断处理函数运行在进程上下文，可以调用睡眠函数，但必须评估其优先级与 CPU 亲和性。
五、典型场景与误区复盘
以一个 1 kHz 伺服控制回路为例：主线 Linux 下，周期抖动可能达到 200～800 μs，偶发超过 1 ms；启用 PREEMPT RT 并配合 isolcpus、CPU 亲和性、SCHED_FIFO 后，抖动通常可稳定在 20～50 μs。但若忽略以下误区，实时性仍会恶化：
- 误区一：打了 RT 补丁就实时。用户态仍可能被缺页、内存分配、日志刷盘阻塞，需配合 mlockall、预分配内存、关闭 swap。
- 误区二：所有中断都线程化就更好。高频网络中断线程化可能增加调度开销，应结合业务做亲和性与优先级规划。
- 误区三：忽略 SMI/NMI 与 BIOS 电源管理。这些硬件级不可屏蔽事件会直接破坏微秒级实时性，需在 BIOS 中关闭 C-state、P-state 与 SMI 相关选项。
- 误区四：用普通 mutex 保护实时任务。应使用 rt_mutex 或优先级继承机制，避免优先级反转导致高优先级任务被无限阻塞。
cyclictest -m -p 80 -n -i 1000 -l 100000，关注 Max 与 99.9% 分位延迟，而不是平均值。
理解 PREEMPT RT 的历史与核心思想，本质上是理解“可预测性优先于平均性能”的工程取舍。它通过自旋锁睡眠化、中断线程化、优先级继承等改造，把 Linux 从通用分时系统推向硬实时边界；而真正落地时，内核配置、驱动写法、用户态内存策略与硬件平台必须协同设计，才能把理论上的低延迟转化为现场可复现的稳定抖动。