1. 调度延迟概述
1.1 调度延迟的定义
调度延迟（Scheduling Latency）是指从某个任务变为可运行状态到该任务实际获得 CPU 并开始执行之间的时间间隔。在抢占式调度系统中，调度延迟是衡量调度器响应速度的核心指标，直接影响系统的交互体验与实时性。
核心公式：调度延迟 = 任务就绪时刻 → 任务首次获得 CPU 的时刻
调度延迟由以下三个子阶段构成：
- 唤醒延迟：任务从阻塞/睡眠状态被唤醒，到被加入运行队列的时间。
- 排队延迟：任务在运行队列中等待被调度的时间，受当前运行队列长度和优先级影响。
- 上下文切换延迟：调度器完成进程上下文保存与恢复、页表切换等操作所花费的时间。
| 延迟分量 | 典型触发场景 | 影响因素 |
|---|---|---|
| 唤醒延迟 | I/O 完成中断唤醒等待进程 | 中断处理效率、唤醒队列实现 |
| 排队延迟 | 高优先级任务等待低优先级任务释放 CPU | 调度算法、时间片大小、任务数量 |
| 上下文切换延迟 | 时钟中断触发调度决策 | 硬件 TLB 刷新、寄存器保存/恢复开销 |
关键认知：调度延迟 ≠ 响应时间。响应时间还包括任务执行本身的时间；调度延迟仅关注"等待 CPU 的时间"。
1.2 调度延迟对系统性能的影响
调度延迟并非越小越好，也非越大越差，其影响因系统类型而异：
- 交互式系统（桌面/移动）：调度延迟直接影响用户感知的流畅度。延迟超过 20ms 时，用户会明显感到卡顿或点击无响应。
- 实时系统（工业控制/自动驾驶）：调度延迟必须满足硬性截止时间（deadline）。一次超时可能导致设备损坏或安全事故。
- 批处理系统（服务器/科学计算）：调度延迟对吞吐量影响较小，过度追求低延迟反而会因频繁上下文切换降低整体效率。
| 系统类型 | 调度延迟敏感度 | 典型容忍上限 | 主要关注点 |
|---|---|---|---|
| 硬实时系统 | 极高 | 微秒级 ~ 毫秒级 | 确定性、最坏情况延迟 |
| 软实时系统（音视频） | 高 | 10ms ~ 50ms | 平均延迟、抖动 |
| 交互式桌面 | 中 | 50ms ~ 200ms | 响应平滑度 |
| 批处理/服务器 | 低 | 秒级 | 吞吐量、CPU 利用率 |
常见误区：降低调度延迟并不总是提升性能。当时间片过短时，上下文切换开销占比上升，导致有效计算时间减少，吞吐量反而下降。调度延迟与吞吐量之间存在经典的"权衡曲线"。
1.3 实时性与公平性的权衡
调度延迟的优化方向取决于系统对实时性和公平性的侧重。这两个目标在本质上是冲突的：
- 实时性优先：要求高优先级任务或紧急任务能立即抢占 CPU，即使这意味着低优先级任务可能被长时间饿死。
- 公平性优先：要求所有任务按权重或优先级获得比例化的 CPU 时间，每个任务都能在可预期的时间内得到调度。
现代通用操作系统（如 Linux）采用混合策略，在公平调度框架内引入实时优先级机制，试图兼顾两者：
| 调度策略 | 实时性 | 公平性 | 典型应用 |
|---|---|---|---|
| FIFO / RR（实时） | 极高 | 低（可能饿死） | 工业控制、音频处理 |
| CFS（完全公平） | 中 | 高 | 桌面、服务器通用场景 |
| EDF（最早截止时间优先） | 高（硬实时） | 中 | 实时多媒体、嵌入式 |
| O(1) / 多级反馈队列 | 中高 | 中 | 传统 Unix、交互式系统 |
设计原则：没有绝对"最优"的调度器，只有"最适合"特定负载的调度器。调度延迟的优化必须在实时性、公平性和吞吐量之间找到平衡点。
1.4 调度延迟与时钟中断的关系
在大多数通用操作系统中，调度决策并非连续进行，而是由时钟中断周期性触发。时钟中断是调度延迟的"心跳"：
- 固定周期中断：每次时钟中断到来时，内核检查当前进程是否用尽时间片，是否需要重新调度。
- 调度延迟的下限：即使任务在中断刚结束后就变为就绪，也必须等待下一个时钟中断才能被调度。因此，时钟中断周期决定了调度延迟的理论下限。
- vruntime 更新：在 CFS 调度器中，每次时钟中断都会更新当前进程的 vruntime，用于维护红黑树的排序。
思考题：如果时钟中断周期为 4ms，一个高优先级任务在中断触发后 0.1ms 变为就绪，它的调度延迟至少是多少？（答案：约 3.9ms，因为要等到下一个中断周期）
本章后续将深入分析时钟中断如何驱动 vruntime 更新，以及这种机制如何影响调度延迟的统计分布。