1. 课程导论：为什么需要混合调度？实时任务与普通任务共存的挑战
1.1 单一调度器的局限
现代操作系统（如 Linux）需要同时承载两类截然不同的工作负载：实时任务（如自动驾驶控制、工业机器人、音频流处理）和普通任务（如 Web 浏览、文件编辑、后台更新）。单一调度策略无法同时满足两者的核心需求。
| 调度策略 | 核心目标 | 对实时任务 | 对普通任务 |
|---|---|---|---|
| 完全公平调度 (CFS) | 公平分配 CPU 时间，低延迟交互 | 无法保证截止时间，可能被普通任务抢占 | 交互流畅，吞吐量均衡 |
| 实时调度 (RT) | 严格满足截止时间，确定性执行 | 截止时间可预测，优先级绝对 | 饥饿风险，低优先级任务可能长期得不到 CPU |
核心矛盾： 实时任务要求“确定性”和“低延迟”，普通任务要求“公平性”和“高吞吐”。单一调度器无法同时提供这两种保证。
1.2 混合调度的核心挑战
当 CFS 与 RT 调度器共存于同一个内核时，必须解决以下关键问题：
- 优先级反转与继承： 高优先级实时任务等待低优先级普通任务持有的锁时，如何避免优先级反转？
- CPU 资源隔离： 如何防止实时任务过度占用 CPU 导致普通任务“饿死”？
- 调度延迟抖动： 普通任务的上下文切换和负载波动如何影响实时任务的截止时间？
- 内核抢占点设计： 实时任务能否在普通任务执行内核代码时立即抢占？
- 调度策略切换开销： 任务在 CFS 和 RT 运行队列之间迁移时的性能损耗。
典型失败案例： 在未配置混合调度的系统中，一个 CPU 密集型的普通任务（如编译）可能导致实时音频任务出现“卡顿”或“爆音”，因为 CFS 调度器无法保证音频任务的周期性唤醒延迟。
1.3 混合调度架构概览
Linux 内核通过 统一调度框架 实现 CFS 与 RT 的协作。核心思路是：RT 优先级高于 CFS，但通过带宽限制和负载均衡防止 RT 任务垄断 CPU。
1.4 关键协作机制一览
为了实现上述架构，Linux 内核引入了以下核心机制：
| 机制 | 作用 | 涉及组件 |
|---|---|---|
| RT 带宽控制 | 限制实时任务在一个周期内的最大运行时间，防止饿死 CFS 任务 | /proc/sys/kernel/sched_rt_period_us、sched_rt_runtime_us |
| 优先级继承协议 (PI) | 解决实时任务与普通任务共享锁时的优先级反转问题 | futex、rt_mutex |
| 内核抢占 (Preemption) | 允许实时任务在普通任务执行内核代码时抢占，降低调度延迟 | PREEMPT_RT 补丁、内核抢占点 |
| 负载均衡 (Load Balance) | 在多核系统中，将 RT 和 CFS 任务合理分配到不同 CPU，避免干扰 | 调度域、调度组 |
学习路径提示： 本章后续将深入分析 RT 带宽控制的实现细节、优先级继承的代码路径，以及如何通过内核配置（如
CONFIG_PREEMPT_RT）调整混合调度的行为。
1.5 实时任务与普通任务的典型共存场景
以下表格展示了不同场景下混合调度的具体需求：
| 应用场景 | 实时任务 | 普通任务 | 混合调度要求 |
|---|---|---|---|
| 自动驾驶 | 传感器融合（周期 10ms） | 日志记录、地图更新 | 传感器融合必须严格按时完成，日志不能干扰 |
| 工业机器人 | 伺服控制（周期 1ms） | HMI 界面、数据上传 | 控制周期抖动 < 100μs，界面响应可稍慢 |
| 音频工作站 | 音频处理（周期 2ms） | 文件保存、插件扫描 | 音频缓冲区不能 underrun，后台任务可延迟 |
这些场景的共同特征是：实时任务对延迟和抖动极度敏感，而普通任务对吞吐量和公平性有要求。混合调度器的设计目标就是在两者之间找到平衡点。