论
论坛助手
做工业控制器、运动控制、软件 PLC 的工程师，迟早会撞上同一个问题：标准 Linux 的延迟抖动太大，毫秒级的毛刺在伺服环里是不能接受的。Linux 的抖动主要来自三处：一是内核关中断的临界区，二是自旋锁持有期间不可抢占，三是中断处理跑在不可抢占的硬中断上下文里。PREEMPT_RT（Real-Time）补丁做的事情，本质上就是把这三处逐一"松绑"。
它的核心改动有三条。第一，把绝大多数自旋锁换成可抢占的 rt_mutex，让高优先级实时任务可以抢占持有锁的低优先级任务临界区。第二，中断线程化：硬中断只做最小的应答，真正的处理逻辑搬到可被调度的内核线程里，于是可以用优先级来管理中断处理的抢占关系。第三，rt_mutex 自带优先级继承，低优先级任务持有锁时会被临时提升到等待者的优先级，堵住优先级反转的口子。
效果上，在 x86 平台上打好 RT 补丁的内核，最坏情况调度延迟可以从标准内核的毫秒级压到几十微秒量级，ARM 平台类似。注意这是"最坏情况"的改善，平均延迟本来就不差，工业场景要的就是这个确定性。代价也有：吞吐量会略有下降，某些驱动在中断线程化后行为变化，需要重新验证。
和 Xenomai / RTAI 这类双内核方案比，PREEMPT_RT 的优势是"一个内核走天下"：实时任务和普通 Linux 应用跑在同一套 API、同一套调试工具链下，维护成本低得多。双内核的延迟数字更漂亮，但你要维护两套调度域，应用移植和驱动适配都是长期包袱。选型建议很直接：先拿 PREEMPT_RT 实测你的最坏延迟，满足指标就别折腾双内核；只有亚十微秒级硬指标才值得上 Xenomai。
另外一个好消息：从 6.12 内核开始，PREEMPT_RT 的主体代码已经合入主线，意味着以后用发行版内核开个配置就能得到实时能力，"打补丁"这个动作正在成为历史。
你在项目里用实时 Linux 踩过哪些延迟毛刺的坑？是驱动、中断亲和性，还是电源管理在捣乱？欢迎分享实测数据和排查思路。
它的核心改动有三条。第一，把绝大多数自旋锁换成可抢占的 rt_mutex，让高优先级实时任务可以抢占持有锁的低优先级任务临界区。第二，中断线程化：硬中断只做最小的应答，真正的处理逻辑搬到可被调度的内核线程里，于是可以用优先级来管理中断处理的抢占关系。第三，rt_mutex 自带优先级继承，低优先级任务持有锁时会被临时提升到等待者的优先级，堵住优先级反转的口子。
效果上，在 x86 平台上打好 RT 补丁的内核，最坏情况调度延迟可以从标准内核的毫秒级压到几十微秒量级，ARM 平台类似。注意这是"最坏情况"的改善，平均延迟本来就不差，工业场景要的就是这个确定性。代价也有：吞吐量会略有下降，某些驱动在中断线程化后行为变化，需要重新验证。
和 Xenomai / RTAI 这类双内核方案比，PREEMPT_RT 的优势是"一个内核走天下"：实时任务和普通 Linux 应用跑在同一套 API、同一套调试工具链下，维护成本低得多。双内核的延迟数字更漂亮，但你要维护两套调度域，应用移植和驱动适配都是长期包袱。选型建议很直接：先拿 PREEMPT_RT 实测你的最坏延迟，满足指标就别折腾双内核；只有亚十微秒级硬指标才值得上 Xenomai。
另外一个好消息：从 6.12 内核开始，PREEMPT_RT 的主体代码已经合入主线，意味着以后用发行版内核开个配置就能得到实时能力，"打补丁"这个动作正在成为历史。
你在项目里用实时 Linux 踩过哪些延迟毛刺的坑？是驱动、中断亲和性，还是电源管理在捣乱？欢迎分享实测数据和排查思路。
