📚 课程目录第3章 Linux实时能力概览

3. Linux实时能力概览

在混合部署工程中，Linux 侧往往承担文件系统、网络协议栈、图形界面与设备管理等非实时或弱实时任务，而 RTOS 侧负责微秒级抖动敏感的采样、闭环控制与安全联锁。理解 Linux 实时能力的边界，是决定“哪些任务留在 Linux、哪些任务下沉到 RTOS”的前提。本节从内核抢占模型、双内核方案、调度类、中断线程化四个维度梳理 Linux 实时化的技术路线，并给出可量化的性能边界判断方法。

一、核心原理：Linux 实时化的三条技术路线

标准 Linux 内核为追求吞吐量，在自旋锁临界区、中断处理、软中断等位置存在大量不可抢占点，导致最坏情况延迟可达毫秒甚至数十毫秒。实时化改造围绕“缩短不可抢占路径”展开，形成三条主流路线：

PREEMPT_RT（单内核抢占）：将自旋锁替换为可睡眠的 rt_mutex，把中断处理程序线程化，使内核几乎完全可抢占。它保持标准 Linux 生态，实时任务与普通任务共享同一内核，最坏延迟通常在几十微秒量级。
Xenomai（双内核/Cobalt）：在 Linux 内核旁挂一个实时微内核，实时任务运行在 Cobalt 域，Linux 作为其最低优先级任务运行。通过 I-pipe 中断管道实现中断分流，硬实时延迟可稳定在十几微秒以内。
RTAI（双内核）：与 Xenomai 思路相近，通过 RTHAL/ADEOS 拦截中断，实时任务在独立调度器中运行。RTAI 历史悠久，在工业控制与科研装置中仍有存量，但社区活跃度低于 Xenomai。

三者的本质差异在于“实时任务是否与 Linux 共享内核调度路径”。单内核方案延迟略高但生态完整；双内核方案延迟更低，但实时域与 Linux 域之间的通信、内存共享和调试复杂度显著上升。

二、实时调度类：SCHED_FIFO、SCHED_RR 与 SCHED_DEADLINE

无论采用哪条路线，实时任务最终都要落到调度类上。Linux 提供三种实时调度策略：

调度类	策略特征	适用场景	注意事项
SCHED_FIFO	先进先出，同优先级不抢占，运行至阻塞或主动让出	周期性控制任务、中断下半部	高优先级任务死循环会饿死低优先级任务
SCHED_RR	同优先级时间片轮转，片长可配	多个同优先级实时任务公平共享	时间片引入额外抖动，硬实时慎用
SCHED_DEADLINE	基于 CBS 的带宽预留，按 runtime/deadline/period 约束	有明确截止期的任务集	需正确设置参数，超限会被节流

设置实时调度类的典型命令如下，需注意权限与优先级范围（1~99，数值越大优先级越高）：

# 查看当前进程调度策略与优先级
chrt -p $$

# 以 SCHED_FIFO、优先级 80 启动实时任务
chrt -f 80 ./motor_control

# 以 SCHED_DEADLINE 启动：每 10ms 周期，运行 2ms，截止期 8ms
chrt -d --sched-runtime 2000000 \
        --sched-deadline 8000000 \
        --sched-period 10000000 0 ./sampler

# 查看系统实时带宽限制
cat /proc/sys/kernel/sched_rt_runtime_us
cat /proc/sys/kernel/sched_rt_period_us

默认情况下 sched_rt_runtime_us 为 950000、sched_rt_period_us 为 1000000，即实时任务最多占用 95% CPU。若实时任务持续超限，会被强制休眠至下一周期，表现为“偶发丢周期”。硬实时场景应评估是否将该比例调至 100%，但需防止普通任务完全饿死。

三、中断线程化：把不可控延迟变成可调度对象

中断处理程序运行在不可抢占上下文，是延迟抖动的主要来源。PREEMPT_RT 将大部分中断处理程序转为内核线程，使其具备优先级并可被更高优先级实时任务抢占。关键机制包括：

强制中断线程化：通过内核参数 threadirqs 或编译选项将 IRQ 处理程序转为 irq/<num>-<name> 线程。
软中断线程化：ksoftirqd 承担软中断处理，避免在中断返回路径长时间占用 CPU。
优先级分配：中断线程默认优先级为 50，可通过 chrt 调整，使关键外设中断优先于普通实时任务。

# 查看中断线程及其调度策略
ps -eLo pid,tid,cls,rtprio,comm | grep irq/

# 将网卡中断线程优先级提升到 90
chrt -f -p 90 $(pgrep -f 'irq/.*eth0')

# 内核启动参数启用中断线程化
# GRUB_CMDLINE_LINUX="threadirqs"

中断线程化并非“零成本”：线程切换本身带来额外开销，且部分关键中断（如时钟中断、IPI）仍需保持硬中断上下文。工程上应只对延迟敏感的外设中断做优先级调优，而非盲目提升所有中断线程。

四、实时性能边界与测量方法

实时性能的核心指标是最坏情况延迟（Worst-Case Latency），而非平均延迟。常用测量工具为 cyclictest，它通过高精度定时器唤醒线程并统计唤醒偏差：

# 单线程、优先级 80、周期 1ms、运行 60 秒
cyclictest -t1 -p 80 -i 1000 -d 60 -m -n

# 典型输出
T: 0 ( 1234) P:80 I:1000 C:  60000 Min:  2 Act:  5 Avg:  4 Max:  23

其中 Max 即为最坏延迟。工程验收应关注以下边界条件：

负载耦合：在磁盘 IO、网络风暴、图形刷新同时运行时测量，而非空载测量。
CPU 隔离：通过 isolcpus 或 cpuset 将实时任务绑定到独立核，减少调度干扰。
频率与电源管理：关闭 C-state 深度睡眠与频率调节，避免唤醒延迟。
内存与缓存：使用 mlockall 锁定内存，减少缺页与换页抖动。

五、误区与复盘

常见误区一：把平均延迟当作实时能力。 实时系统只关心最坏情况。平均 5μs、最坏 2ms 的系统，对 1ms 周期任务而言是不可用的。

常见误区二：认为 PREEMPT_RT 可以替代 RTOS。 PREEMPT_RT 的最坏延迟通常在几十微秒，适合 100μs 级以上周期；若控制周期低于 50μs 或要求确定性抖动小于 10μs，仍应使用 Xenomai 或独立 MCU/RTOS。

常见误区三：忽略双内核方案的跨域成本。 Xenomai 实时域与 Linux 域之间的数据交换需通过 RTDM 或共享内存，若通信设计不当，反而引入比单内核更大的延迟。

复盘建议：在混合部署架构选型阶段，先用 cyclictest 在目标硬件上实测三条路线的延迟分布，再结合任务周期、抖动容忍度、生态依赖与团队维护能力做决策。Linux 实时能力不是“越硬越好”，而是与 RTOS 侧形成互补：Linux 负责复杂性与生态，RTOS 负责确定性与安全，边界清晰才是混合部署工程的核心价值。