CFS 目标延迟与最小粒度

目标延迟的本质与设计动机

1. 理想模型的困境

• 理论目标：
  CFS的终极理想是模拟“完美多任务处理器”，让每个进程在任意时间段内获得1/n的处理器时间（n为可运行进程数）。例如：
  • 若有2个进程，每个进程应占用50%的CPU时间；
  • 若有20个进程，每个应占用5%的CPU时间。
• 现实矛盾：
  若严格遵循理想模型，每个进程的时间片趋近于无限小（如20个进程时每个仅分到1ms），导致：
  • 频繁进程切换：每次切换需保存/恢复上下文、刷新缓存，产生显著性能损耗；
  • 吞吐量骤降：CPU时间被切换开销浪费，实际任务执行效率低下。

2. 目标延迟的折中设计

• 核心作用：
  目标延迟是CFS为平衡理想公平性与现实性能而引入的调度周期（默认20ms）。它定义了一个时间窗口，在此窗口内尽可能公平地分配CPU时间。本质为希望每个进程在多长时间内至少被调度一次。
• 运作逻辑：
  • 动态分配时间片：根据进程权重（由nice值决定）和当前可运行进程数，计算每个进程在目标延迟周期内应运行的时间。

---

目标延迟的实例解析

1. 基础场景

• 目标延迟=20ms，2个同优先级进程：
  • 每个进程分到20ms / 2 = 10ms，轮流运行直到周期结束。
• 目标延迟=20ms，4个同优先级进程：
  • 每个进程分到20ms / 4 = 5ms，轮流运行。

2. 极端场景与最小粒度

• 问题：若进程数极大（如1000个），按目标延迟计算的时间片可能极小（20ms / 1000 = 0.02ms），频繁的上下文切换会导致很大的切换开销。
• 解决方案：引入最小粒度（默认1ms）作为时间片下限：
  • 每个进程至少运行1ms，即使目标延迟周期会被拉长（总时间=进程数×1ms）。
  • 牺牲局部公平性：1000个进程时，总调度周期变为1000ms（而非20ms），但避免了切换开销爆炸。

---

目标延迟的权衡：交互性 vs 吞吐量

1. 目标延迟越小（如5ms）

• 优势：
  • 交互性更强（进程更频繁被调度），适合桌面系统或实时任务。
• 代价：
  • 吞吐量下降（切换开销占比增加）；
  • 缓存效率降低（进程频繁切换导致缓存未命中）。

2. 目标延迟越大（如100ms）

• 优势：
  • 吞吐量更高（切换开销占比降低），适合计算密集型服务器。
• 代价：
  • 交互性延迟（进程需等待更久才能运行）。

---

目标延迟与Nice值的联动

1. 权重机制

• nice值决定进程的权重，影响其在目标延迟周期内的CPU时间占比。
• 示例：
  • nice=0（默认权重）和nice=5（权重为默认的1/3）：
    • 目标延迟=20ms时，两者分到15ms和5ms（权重比3:1）。
  • 若两者nice值分别为10和15（差值仍为5），时间片分配比例仍为3:1。

2. 相对性规则

• 绝对nice值无关：只有进程间的nice值差值影响时间片比例。
• 几何加权：每相差1个nice值，权重按比例变化（通常为1.25倍）。

---

总结：目标延迟的意义

1. 核心价值：
   在理想公平性与现实性能间找到平衡点，通过限制调度周期长度，避免无限小时间片导致的性能灾难。
2. 参数调优：
   目标延迟是Linux内核可调参数（/proc/sys/kernel/sched_latency_ns），用户可根据场景动态调整：
   • 交互型应用（如桌面）：降低目标延迟（如10ms）；
   • 计算密集型任务（如服务器）：提高目标延迟（如50ms）。
3. 妥协的智慧：
   CFS并非完美公平，但通过目标延迟和最小粒度的配合，在大多数实际场景（数百个进程）中实现了高效的近似公平调度。