4. 负载跟踪的起源：为什么需要负载跟踪？传统负载计算的局限性

在 Linux 内核调度器的演进历史中，负载跟踪（Load Tracking）是一个里程碑式的设计变革。要理解 PELT（Per-Entity Load Tracking）算法的价值，首先必须回答一个根本问题：为什么调度器需要知道“负载”是多少？

4.1 负载跟踪的核心动机

调度器的根本职责是在多个任务（或 CPU）之间合理分配计算资源。如果调度器对每个任务或每个 CPU 的“繁忙程度”一无所知，那么所有调度决策都将是盲目的。负载跟踪为以下关键调度行为提供了量化依据：

• 负载均衡（Load Balance）：决定何时将任务从一个 CPU 迁移到另一个 CPU，以消除 CPU 之间的忙闲不均。
• 频率调节（DVFS）：判断当前 CPU 是否处于重载状态，从而决定是否提升或降低 CPU 运行频率以节省功耗。
• 任务放置（Task Placement）：为新创建或唤醒的任务选择一个“最空闲”或“最合适”的 CPU 运行。
• CFS 带宽控制：确保每个控制组（cgroup）在单位时间内获得的 CPU 时间不超过其配额。

4.2 传统负载计算的局限性

在 PELT 算法出现之前（Linux 2.6 早期及 CFS 调度器初期），内核主要依赖两种简单粗暴的负载度量方式。这些方法虽然实现简单，但在多核、交互式、功耗敏感的现代系统中暴露出了严重缺陷。

4.2.1 基于优先级的静态负载

在 O(1) 调度器时代，任务的“负载”很大程度上由其静态优先级（nice 值）决定。一个高优先级任务被认为“更重要”，但并不意味着它当前正在消耗 CPU。这种方法的缺陷显而易见：

• 无法反映实际 CPU 消耗：一个低优先级的 CPU 密集型任务可能比一个高优先级的空闲任务对系统造成的压力更大。
• 对 I/O 密集型任务不友好：I/O 密集型任务虽然经常睡眠，但一旦被唤醒需要快速响应，静态优先级无法体现这种突发性需求。

4.2.2 基于运行队列长度的瞬时统计

CFS 调度器早期引入了基于运行队列（runqueue）长度的统计方法。这种方法通过计算某个时间点运行队列中可运行任务的数量来评估 CPU 的负载。

下图直观展示了传统运行队列长度统计的“抖动”问题：

4.3 传统方法的三大致命缺陷

通过深入分析，我们可以将传统负载计算的局限性归纳为以下三个核心问题：

1. 缺乏时间衰减（Decay）机制：传统方法对过去的历史负载“一视同仁”。一个任务在 10 秒前消耗了大量 CPU，与它在 1 秒前消耗了大量 CPU，在统计上被赋予相同的权重。这导致调度器无法区分“正在活跃”的任务和“曾经活跃但现在已休眠”的任务。
2. 对任务休眠/唤醒行为不敏感：当任务进入休眠（如等待 I/O）时，传统统计无法快速“遗忘”其历史负载。这导致在负载均衡时，一个刚刚被唤醒的交互式任务可能被误判为高负载任务，从而被分配到错误的 CPU。
3. 无法提供细粒度的实体级视图：传统方法通常只统计整个运行队列的负载，无法精确到每个调度实体（se, cfs_rq）。在 cgroup 嵌套和任务组调度的场景下，这种粗粒度的统计完全无法满足需求。

4.4 从“瞬时快照”到“历史加权”的范式转变

为了解决上述问题，内核社区意识到需要一种全新的负载跟踪哲学：负载不应是一个瞬时快照，而应是一个具有“记忆”且“会遗忘”的衰减函数。

下图对比了传统方法与 PELT 方法在负载计算哲学上的根本差异：

4.5 小结：为什么必须引入 PELT？

传统负载计算的局限性直接催生了 PELT 算法的诞生。下表总结了从“为什么需要负载跟踪”到“为什么必须用 PELT”的逻辑链条：