实时性基础：实时操作系统（RTOS）的关键指标与Linux调度机制

在深入PREEMPT_RT补丁之前，必须先建立一套衡量"实时性"的精确坐标系。实时性并非"快"的同义词，而是对系统响应时间的一种可证明的、有界的保证。本章将首先厘清延迟、吞吐量与确定性这三个核心指标的内涵与权衡，随后区分硬实时与软实时的本质差异，最后剖析Linux内核调度器从O(1)到CFS的演进逻辑，以及实时调度策略SCHED_FIFO与SCHED_RR在其中的定位。这一基础框架将直接决定后续理解PREEMPT_RT补丁为何要修改内核的哪些核心路径。

2.1 实时性的三大关键指标：延迟、吞吐量与确定性

实时系统的设计目标不是"尽可能快"，而是"在确定的时间内完成"。这三个指标构成了评估实时性的基本维度，它们之间往往存在矛盾，需要根据应用场景进行权衡。

核心原理：指标的定义与测量

• 延迟（Latency）：从事件发生到系统响应之间的时间差。在实时系统中，延迟通常细分为中断延迟（从中断信号产生到中断处理程序开始执行）、调度延迟（从任务就绪到任务获得CPU）和执行延迟（任务实际运行时间）。PREEMPT_RT补丁主要优化的是前两者。
• 吞吐量（Throughput）：单位时间内系统处理的任务数量或数据量。对于实时系统，吞吐量通常不是首要目标，但在保证延迟上界的前提下，吞吐量越高越好。
• 确定性（Determinism）：系统行为在时间上的可重复性。一个确定性系统，其延迟分布应该非常集中，最坏情况延迟（Worst-Case Execution Time, WCET）与平均延迟的差距很小。确定性是硬实时系统的核心要求。

判断方法：如何量化实时性

工程实践中，我们通常使用以下指标来量化实时性：

案例拆解：工业机器人控制中的指标权衡

以六轴工业机器人的伺服控制环为例，其控制周期通常为1ms（即1000Hz）。在这个场景中：

• 延迟要求：从编码器采样到PWM输出更新，整个链路延迟必须小于500μs，否则会导致控制环相位裕度不足，引发震荡。
• 吞吐量要求：每个控制周期需要处理6个关节的PID计算、运动学正解/逆解，以及EtherCAT通信。在1ms内完成这些计算，对CPU吞吐量有硬性要求。
• 确定性要求：最坏情况延迟必须小于800μs，且抖动小于50μs。如果某个周期延迟达到900μs，即使平均延迟只有300μs，也会导致伺服驱动器报"跟踪误差超限"故障。

在这个案例中，确定性优先于吞吐量。我们宁愿降低控制频率到500Hz，也不允许出现延迟尖峰。这正是PREEMPT_RT补丁要解决的核心问题——消除内核中的不可预测延迟源。

常见误区与总结

2.2 硬实时与软实时的本质区别

实时系统并非铁板一块，根据错过截止时间（Deadline）的后果严重程度，可以划分为硬实时、软实时和固实时三种类型。这种分类直接决定了系统设计的目标和采用的策略。

核心原理：截止时间违反的代价

• 硬实时（Hard Real-Time）：错过截止时间会导致灾难性后果——设备损坏、人员伤亡、数据永久丢失。例如：汽车安全气囊控制系统、心脏起搏器、核反应堆保护系统。硬实时系统必须证明最坏情况延迟小于截止时间，这需要静态分析和形式化验证。
• 软实时（Soft Real-Time）：错过截止时间会降低服务质量，但不会造成灾难。例如：视频会议系统（丢帧但可接受）、在线游戏（延迟增加但可玩）。软实时系统追求的是统计保证，即99.9%的情况下满足截止时间。
• 固实时（Firm Real-Time）：介于两者之间，错过截止时间的结果是本次结果无效，但不会造成灾难。例如：雷达信号处理（错过一个扫描周期的数据就丢弃该帧）。

判断方法：你的系统属于哪一类？

可以通过以下问题来判断：

1. 如果任务晚执行10ms，会发生什么？——如果答案是"设备损坏"或"人员伤亡"，则是硬实时。
2. 如果任务晚执行10ms，用户是否会明显感知但可接受？——如果是，则是软实时。
3. 如果任务晚执行10ms，本次计算结果是否直接作废？——如果是，则是固实时。

案例拆解：从软实时到硬实时的改造代价

某医疗影像设备公司开发了一款超声诊断仪，最初基于标准Linux（软实时）实现。在临床测试中发现，当系统负载较高时，图像帧率从30fps下降到15fps，且偶尔出现画面冻结（延迟超过200ms）。虽然不危及生命，但医生无法准确判断胎儿心跳，属于服务质量严重下降。

改造方案：引入PREEMPT_RT补丁，将图像采集线程设置为SCHED_FIFO优先级80，显示线程设置为优先级70。改造后，在最坏情况下（同时进行文件存储和网络传输），图像帧率稳定在28-30fps，最大延迟从200ms降低到15ms。这个案例说明：软实时系统通过合理的实时化改造，可以逼近硬实时的性能边界，但无法做到形式化证明。

常见误区与总结

2.3 Linux内核调度器基础：从O(1)到CFS

Linux内核的调度器经历了从O(1)到CFS（Completely Fair Scheduler）的演进，这一演进反映了对交互性、公平性和可扩展性的不同权衡。理解这一演进过程，有助于理解PREEMPT_RT补丁为何要修改调度器的某些行为。

核心原理：两种调度器的设计哲学

O(1)调度器的优势在于调度延迟恒定，适合实时性要求较高的场景。但其缺点是启发式判断交互式任务不够准确，且时间片固定导致响应时间不稳定。CFS通过红黑树和vruntime实现了完美的公平性，但调度延迟随任务数对数增长。

判断方法：何时选择哪种调度器？

在PREEMPT_RT补丁的语境下，我们通常不直接选择O(1)或CFS，而是关注实时调度策略如何与CFS共存。CFS中的普通任务（SCHED_NORMAL）与实时任务（SCHED_FIFO/SCHED_RR）是分开管理的：实时任务优先于所有普通任务执行。

案例拆解：CFS在实时场景下的不足

假设一个系统运行着两个任务：任务A是数据采集（SCHED_NORMAL），任务B是控制输出（SCHED_FIFO优先级50）。在CFS下，任务A和任务B的调度行为如下：

• 任务B（实时）就绪时，立即抢占任务A（普通），无论任务A的vruntime多小。
• 任务A只有在任务B阻塞或完成时才能运行。
• 如果任务B是CPU密集型，任务A可能长时间得不到运行，导致数据采集缓冲区溢出。

这个案例说明：CFS的公平性只适用于普通任务之间，实时任务通过优先级机制获得的CPU优先权。PREEMPT_RT补丁进一步强化了这种机制，确保实时任务在内核态也能被及时抢占。

常见误区与总结

2.4 实时调度策略：SCHED_FIFO与SCHED_RR

Linux提供了两种实时调度策略，它们与普通策略（SCHED_NORMAL）的根本区别在于：实时任务不会被普通任务抢占，除非实时任务主动让出CPU或阻塞。这两种策略的差异在于同优先级任务之间的调度方式。

核心原理：两种策略的行为差异

• SCHED_FIFO（先入先出）：同一优先级的任务按照就绪顺序执行，没有时间片限制。一个SCHED_FIFO任务一旦获得CPU，会一直运行直到：①主动调用sched_yield()；②阻塞在等待事件；③被更高优先级的任务抢占。这种策略适合执行时间短、需要严格顺序的任务。
• SCHED_RR（轮转）：同一优先级的任务按照时间片轮转执行。每个任务运行一个固定的时间片（默认100ms，可通过sched_rr_get_interval()查询），时间片用完后被放到队列尾部。这种策略适合多个同优先级任务需要公平分享CPU的场景。

判断方法：如何选择SCHED_FIFO还是SCHED_RR？

案例拆解：多传感器数据融合的优先级设计

考虑一个自动驾驶的感知系统，包含三个任务：

• 任务A：激光雷达点云处理（周期10ms，执行时间2ms）
• 任务B：摄像头图像识别（周期33ms，执行时间15ms）
• 任务C：毫米波雷达数据处理（周期20ms，执行时间1ms）

设计策略：

1. 将任务A设为SCHED_FIFO优先级80，因为点云处理是安全关键路径，且执行时间短。
2. 将任务C设为SCHED_FIFO优先级70，因为毫米波雷达数据量小，处理快。
3. 将任务B设为SCHED_RR优先级60，因为图像识别计算量大，且允许被中断。

这样设计的好处是：任务A和C作为高优先级FIFO任务，能保证在周期内完成；任务B作为RR任务，在低优先级下公平分享CPU，即使偶尔被抢占，也不会影响安全关键任务。

常见误区与总结