SCHED_FIFO、SCHED_RR、SCHED_DEADLINE有什么区别？机器人实时控制到底该怎么选？

在前面的文章中，我们一直在讨论一个问题：

ROS 2为什么需要实时Linux？

答案其实已经越来越清晰。

一个机器人控制任务能不能及时完成，不仅取决于控制算法本身运行多快，还取决于线程什么时候能够获得CPU、运行过程中会不会被其他任务干扰、是否存在锁竞争，以及系统最坏情况下到底会产生多大的调度延迟。

而这一切最终都会落到一个非常基础的问题：

Linux到底应该按照什么规则调度这些线程？

这就是Linux调度策略存在的意义。

在普通Linux应用中，我们经常不需要主动关注调度策略。程序启动之后，操作系统负责管理线程运行。

但在机器人实时控制系统中，一个1kHz的关节控制线程和一个后台日志线程显然不应该拥有完全相同的调度优先级和运行规则。

例如：

机器人系统 1kHz关节控制 100Hz状态估计 60Hz视觉处理 20Hz路径规划 日志记录 网络通信 UI显示

如果这些任务全部按照完全相同的调度方式参与CPU竞争，那么当系统负载升高时，关键控制任务就可能出现不可预测的等待。

因此，实时系统需要建立一套更加明确的调度关系。

Linux中最常见的实时调度策略包括：

SCHED_FIFO SCHED_RR SCHED_DEADLINE

它们都可以用于实时任务，但设计思想并不一样。

简单概括：

SCHED_FIFO更强调实时优先级和先到先运行；SCHED_RR在同优先级实时任务之间进行时间片轮转；SCHED_DEADLINE则直接围绕任务的运行预算、周期和截止时间进行调度。

理解这三种策略，不只是为了记住三个Linux参数，更重要的是理解：

机器人系统究竟应该如何描述一个“实时任务”。

一、SCHED_FIFO：让关键实时任务拥有更明确的优先级

先来看最经典的SCHED_FIFO。

FIFO就是：

First In, First Out

可以把它理解成一种强调实时优先级的调度方式。

假设现在有三个实时线程：

控制线程 Priority 90 状态估计线程 Priority 70 日志线程 Priority 50

当它们同时处于可运行状态时，高优先级线程具有更高的调度优先权。

可以简单理解成：

Priority 90 ↓ 控制线程 ↓ 优先获得CPU

如果控制线程运行期间没有主动阻塞或让出CPU，那么它可以持续运行。

只有当：

更高优先级实时线程出现

或者当前线程：

阻塞 主动让出CPU 进入等待

等情况发生时，调度器才会切换到其他任务。

因此，SCHED_FIFO非常适合表达一种关系：

这个任务比其他任务重要，而且一旦准备好运行，就应该尽快获得CPU。

这和机器人控制的很多任务非常契合。

例如：

关节控制 ↓ Priority 90 状态估计 ↓ Priority 70 日志记录 ↓ 普通任务

当关节控制任务Ready之后，可以优先获得CPU。

SCHED_FIFO为什么适合实时控制？

机器人控制有一个很典型的特点：

不同任务的重要程度不同。

例如一个机械臂系统：

1kHz关节控制 500Hz状态估计 100Hz通信 30Hz视觉 10Hz日志

这些任务不能简单地看成“大家都一样重要”。

因为：

1kHz控制

往往拥有更严格的时间约束。

而：

日志记录

即使晚几百毫秒，也通常不会影响关节控制。

所以可以建立类似：

高优先级 │ ├── 关节控制 ├── 实时硬件接口 └── 安全相关任务 ↓ 中优先级 │ ├── 状态估计 └── 部分传感器处理 ↓ 低优先级 │ ├── 日志 ├── 数据记录 └── 后台服务

这就是实时优先级设计。

但是，SCHED_FIFO并不是“优先级越高越好”

这里存在一个非常重要的误区。

如果一个线程：

Priority = 99

是不是意味着：

只要它运行，整个机器人系统就一定实时？

显然不是。

例如：

控制线程 Priority 90 ↓ 执行一段很长的计算 ↓ 持续占用CPU

如果这个任务设计不合理，它可能长时间阻塞其他任务。

更严重的是，如果存在：

死循环 无限计算 长时间锁持有 不可控阻塞

那么高优先级反而可能成为系统风险。

所以实时系统中有一个非常重要的原则：

高优先级线程必须短、确定、可控。

尤其是在实时控制路径中，应尽量避免：

文件I/O 复杂日志 长时间Mutex 动态内存操作 不可预测网络操作

等可能产生较大时间不确定性的操作。

因此SCHED_FIFO真正的价值不是：

“把控制线程优先级调到最高。”

而是：

让不同实时任务之间建立清晰的时间优先级关系。

二、SCHED_RR：当多个实时任务同优先级时怎么办？

如果SCHED_FIFO解决的是：

“不同优先级任务谁优先？”

那么SCHED_RR主要解决另外一个问题：

如果两个实时任务拥有相同优先级，应该怎么办？

例如：

Thread A Priority 80 Thread B Priority 80 Thread C Priority 80

如果采用SCHED_FIFO，那么同一个优先级下，任务可能按照进入运行状态的顺序持续运行，直到发生适当的调度事件。

而SCHED_RR则加入了时间片轮转机制。

可以简单理解成：

Thread A ↓ 运行一个时间片 ↓ Thread B ↓ 运行一个时间片 ↓ Thread C ↓ 运行一个时间片 ↓ Thread A

也就是说：

SCHED_FIFO → 同优先级任务更强调先到先运行 SCHED_RR → 同优先级任务之间进行轮转

为什么机器人系统可能需要同优先级任务？

一个复杂机器人系统中，可能存在多个具有类似实时要求的任务。

例如：

控制任务A：左臂 Priority 80 控制任务B：右臂 Priority 80

或者：

传感器处理A Priority 70 传感器处理B Priority 70

如果这些任务确实具有相近的实时优先级，那么SCHED_RR可以提供更加明确的轮转机制。

但这里同样不能简单理解为：

“SCHED_RR一定比SCHED_FIFO更好。”

因为这两者解决的问题不同。

如果系统中有一个真正关键的1kHz控制任务：

Priority 90

而几个普通实时任务：

Priority 70

那么直接建立清晰的优先级关系，可能更加重要。

所以选择调度策略的前提不是：

哪个参数更先进？

而是：

我的任务具有什么时间特征？

三、SCHED_DEADLINE：从“优先级”转向“时间约束”

如果说：

SCHED_FIFO SCHED_RR

主要还是围绕“优先级”来思考，那么SCHED_DEADLINE则提供了另一种非常重要的思路：

直接描述一个任务的时间约束。

这对于周期性机器人控制任务尤其有意义。

例如：

关节控制任务 每1ms运行一次 每次最多需要100μs CPU时间 必须在周期内完成

这个任务实际上已经具有几个非常明确的时间属性：

Period Runtime Deadline

可以把它简单理解成：

Period ↓ 多久需要运行一次？ Runtime ↓ 每次需要多少CPU运行时间？ Deadline ↓ 最晚什么时候必须完成？

例如：

Period = 1ms Runtime = 100μs Deadline = 1ms

这比简单说：

Priority = 90

包含了更加具体的时间信息。

因此SCHED_DEADLINE对于周期性实时任务具有非常明显的意义。

四、三种调度策略放在一起，到底有什么区别？

可以用一个非常直观的方式理解：

可以进一步把它们理解成三种不同的“任务描述方式”。

SCHED_FIFO： “我的任务很重要， 请优先让我运行。” SCHED_RR： “我的任务很重要， 但和同优先级任务之间需要轮流运行。” SCHED_DEADLINE： “我的任务每隔一段时间需要运行一定时间， 并且必须在截止时间前完成。”

对于机器人开发者来说，这种理解比死记参数更加重要。

因为真正的实时任务设计，本质上就是：

把机器人的任务时间特征转换成操作系统能够理解的调度约束。

五、为什么1kHz机器人控制特别适合从Deadline角度思考？

我们来看一个具体例子。

假设一个机械臂关节控制周期：

1ms

也就是：

1000Hz

假设控制算法实际执行：

100μs

那么可以粗略表示为：

每1ms： |←──────────── 1ms ────────────→| [控制计算100μs]

理想情况下：

0ms 1ms 2ms 3ms │----------│----------│----------│ ↑ ↑ ↑ 控制 控制 控制

但如果某一次调度发生延迟：

0ms 1ms 2ms │----------│----------│ ↑ 控制任务

那么这个周期就可能错过。

所以真正的问题并不是：

控制算法运行100μs

而是：

控制任务能不能在规定时间内启动？ + 能不能在规定时间内执行完成？

因此可以进一步把控制任务描述成：

周期： 1ms 执行预算： 100μs 截止时间： 1ms

这正是Deadline思维。

六、但SCHED_DEADLINE也不能解决所有问题

这是理解实时Linux时必须强调的一点。

如果一个线程设置了：

SCHED_DEADLINE

并不意味着：

机器人系统 = 100%实时

因为调度只是整个系统的一部分。

例如：

ROS 2 ↓ DDS ↓ Executor ↓ Thread ↓ Scheduler ↓ CPU ↓ IRQ ↓ Driver ↓ Hardware

如果问题发生在：

DDS通信

调度器无法直接解决。

如果问题发生在：

Mutex锁竞争

单纯改变调度策略也无法彻底解决。

如果问题发生在：

驱动

调度策略同样无法凭空修复。

如果问题来自：

CPU缓存 内存访问 I/O 硬件中断

也不能只靠SCHED_DEADLINE解决。

所以：

实时调度策略是实时系统的重要组成部分，但不是实时系统的全部。

七、ROS 2中的Executor为什么需要和Linux调度策略结合？

现在再回到ROS 2。

ROS 2的Executor负责管理Callback。

例如：

Sensor Callback Control Callback State Callback

Executor负责：

发现哪些Callback可以执行 管理Callback执行

但真正执行这些Callback的，仍然是线程。

于是：

ROS 2 Executor ↓ Thread ↓ Linux Scheduler ↓ CPU

这意味着：

Executor解决的是“ROS 2层面哪些工作需要执行”，而Linux Scheduler解决的是“线程什么时候获得CPU”。

这两个层次不能混淆。

例如一个控制Callback已经Ready：

Control Callback ↓ Executor发现 ↓ Thread Ready

接下来：

Thread Ready ↓ 等待Linux调度 ↓ Thread Running

如果此时CPU正在处理大量任务，那么真正的执行时间仍然取决于系统调度和资源状态。

因此，在ROS 2实时系统设计中，往往需要同时关注：

Callback Group Executor Thread Scheduling Policy Priority CPU Affinity IRQ Affinity Core Isolation

它们是不同层面的机制，但共同影响最终控制周期。

八、一个实际的ROS 2机器人任务应该怎么设计？

假设现在有一个人形机器人控制系统。

可以把任务简单划分成：

任务 频率 关节控制 1kHz 姿态估计 500Hz IMU处理 500Hz 状态估计 100Hz 视觉 30Hz 路径规划 10Hz 日志 非实时 UI 非实时

一个可能的设计思路是：

高实时等级 关节控制 ↓ 高实时优先级 ↓ 专用CPU核心 ↓ 实时调度 中实时等级 状态估计 ↓ 中等优先级 ↓ 实时CPU或共享CPU 普通任务 视觉 规划 日志 UI ↓ 普通CPU资源

这里最重要的不是具体设置多少Priority，而是建立：

任务分类 → 时间约束 → 优先级 → CPU资源 → 调度策略

这样的完整关系。

例如：

1kHz关节控制 ↓ 严格周期 ↓ 高实时优先级 ↓ CPU隔离 ↓ 减少IRQ干扰 ↓ 实时同步机制

而：

日志 ↓ 没有严格Deadline ↓ 普通调度 ↓ 不能干扰实时控制

这样设计之后，系统的实时性才有可能真正得到保障。

九、为什么“实时优先级设计”本身也是一门工程？

很多初学者看到实时Linux之后，会产生一个非常简单的想法：

控制线程 → Priority 99 其他线程 → Priority 1

然后认为：

“这样不就实时了吗？”

实际上远远没有这么简单。

因为真实机器人系统存在任务之间的依赖关系。

例如：

控制线程 ↓ 等待状态估计数据 ↓ 状态估计线程

如果状态估计线程优先级过低，那么可能出现：

控制线程等待 ↓ 状态估计没有及时运行 ↓ 控制任务拿不到最新数据

这时候单纯提高控制线程优先级反而可能没有意义。

再例如：

控制线程 ↓ 获取共享数据Mutex ↑ 数据线程

如果低优先级数据线程持有锁：

高优先级控制线程 ↓ 等待锁 ↑ 低优先级线程

又会出现优先级反转。

因此实时调度设计必须从：

单线程优先级

升级到：

任务之间的依赖关系

再进一步考虑：

锁 通信 CPU IRQ 内存 驱动

这就是实时系统工程和普通应用开发之间的重要区别。

十、SCHED_FIFO、SCHED_RR、SCHED_DEADLINE并不是“谁最好”，而是适合什么任务

到这里，我们已经可以得出一个非常重要的结论。

不要简单问：

SCHED_FIFO、SCHED_RR、SCHED_DEADLINE哪个最好？

更合理的问题应该是：

我的机器人任务具有什么样的时间特征？

如果任务主要需要：

明确的实时优先级

那么SCHED_FIFO可能是一种常见选择。

如果存在：

多个相同实时优先级任务

需要进行轮转，那么SCHED_RR可以提供相应机制。

如果任务具有非常明确的：

Period Runtime Deadline

那么SCHED_DEADLINE则提供了更加直接的时间约束表达方式。

因此：

实时任务 │ ├── 优先级驱动 │ ↓ │ SCHED_FIFO │ ├── 同优先级轮转 │ ↓ │ SCHED_RR │ └── 时间约束驱动 ↓ SCHED_DEADLINE

但无论使用哪一种调度策略，都不能忽略一个事实：

调度器只能决定线程如何竞争CPU，而不能自动把整个机器人系统变成确定性系统。

真正的实时系统还需要：

实时调度 + CPU核心隔离 + IRQ隔离 + 实时同步 + 资源管理 + 驱动优化 + 应用实时编程

共同完成。

十一、从实时调度继续向下：为什么“调度器”还不是全部？

到这里，我们已经从ROS 2一路追到了：

ROS 2 ↓ Executor ↓ Thread ↓ Linux Scheduler ↓ SCHED_FIFO / SCHED_RR / SCHED_DEADLINE

但如果继续往下追问，还会发现一个更加关键的问题：

即使调度器知道哪个线程最重要，CPU真的能够完全按照这个线程的需求运行吗？

答案仍然不是简单的“是”。

因为CPU上还有：

IRQ 软中断 内核任务 缓存 内存访问 驱动 DMA 锁 其他CPU之间的同步

甚至：

系统后台任务

都可能影响实时控制。

所以实时系统真正需要解决的问题其实已经从：

“哪个线程优先？”

进一步变成：

“如何让关键线程拥有相对稳定、可预测的运行环境？”

这就再次回到了前面文章讨论过的：

CPU Affinity IRQ Affinity Core Isolation

以及更加底层的：

资源隔离

如果说实时调度解决的是：

谁优先运行？

那么核心隔离解决的就是：

谁可以进入这个CPU？

而资源隔离进一步解决：

关键任务需要的CPU、内存、同步和系统资源，如何减少其他任务的干扰？

这三者结合起来，才构成更加完整的实时运行环境。

对于工业机器人、机械臂、人形机器人以及其他高实时性控制系统，如果仅仅依赖应用层调整优先级，往往还不够。

当系统对亚毫秒级甚至更严格的响应时间、最坏情况延迟、确定性以及资源隔离提出更高要求时，就需要把实时能力进一步下沉到操作系统和系统架构层面。

这也是实时操作系统和普通Linux运行环境之间真正值得研究的差异。

例如在面向这类场景的实时操作系统设计中，可以通过包括望获rtLinux在内的实时操作系统基础设施，从调度、核心隔离、资源隔离等多个层面构建更加确定的运行环境，为ROS 2及机器人控制应用提供底层支撑。

最终，一个完整的机器人实时控制链路应该更接近：

┌───────────────────────────────┐ │ ROS 2应用 │ │ Node / Topic / Control │ ├───────────────────────────────┤ │ Executor │ ├───────────────────────────────┤ │ Callback / Thread │ ├───────────────────────────────┤ │ 实时调度策略 │ │ FIFO / RR / DEADLINE │ ├───────────────────────────────┤ │ CPU / IRQ / Core │ │ Affinity / Isolation │ ├───────────────────────────────┤ │ 实时同步与资源管理 │ ├───────────────────────────────┤ │ 驱动 / 硬件 │ └───────────────────────────────┘

这也是理解机器人实时操作系统的一个重要思路：

实时性不是一个参数，而是一整套系统工程。

从ROS 2的Callback，到Executor，再到Linux线程，从SCHED_FIFO、SCHED_RR、SCHED_DEADLINE，到CPU核心隔离、IRQ隔离和资源隔离，每一层都可能影响最终的控制周期。

而当机器人从“能够运行”进一步走向：

高频控制 + 复杂AI计算 + 多传感器融合 + 多线程并行 + 大规模部署

实时系统真正面临的挑战，也就不再只是“调度一个线程”，而是：

如何让实时任务与非实时任务在同一台机器上长期稳定共存。

这也是下一阶段更加值得深入讨论的问题。

下一篇，我们继续往系统架构层推进：

《ROS 2实时控制为什么需要资源隔离？当AI、视觉和机器人控制跑在同一颗CPU上会发生什么？》

重点分析当机器人同时运行ROS 2 + AI推理 + 视觉 + 路径规划 + 1kHz运动控制时，为什么“CPU够用”依然不代表“实时性够用”，以及CPU、内存、中断、线程等资源如何进一步进行隔离。