4. CPU空闲管理（CPU Idle）：CPU Idle框架与C-State深度解析

CPU空闲管理，说白了就是让CPU在没事干的时候能歇着。别小看这个“歇着”，在嵌入式设备里，CPU空闲时的功耗往往决定了整机的续航表现。我见过不少团队，应用层优化做得飞起，结果一看CPU空闲功耗，好家伙，比跑负载时低不了多少——那前面的优化全白干了。

这一章我们聚焦三个核心问题：CPU Idle框架怎么工作的？C-State到底是什么？ARM平台上的WFI和WFI+深度睡眠怎么配？

4.1 CPU Idle框架：谁在管CPU睡觉这件事？

Linux内核里，CPU Idle框架负责管理CPU的空闲状态。它的核心逻辑很简单：当CPU的idle线程运行时，框架会选择一个合适的空闲状态让CPU进入。

框架分三层：

  • Governor（ governors ）：决策层，决定进哪个C-State。常见的有 menu 和 ladder。
  • Driver（驱动层）：硬件抽象层，提供具体进入/退出空闲状态的接口。
  • Core（核心层）：调度和协调层，把governor和driver串起来。

我个人习惯先看 /sys/devices/system/cpu/cpu0/cpuidle/ 下的文件，那里直接暴露了当前支持的C-State和进入次数。比如：

# cat /sys/devices/system/cpu/cpu0/cpuidle/state0/name
WFI
# cat /sys/devices/system/cpu/cpu0/cpuidle/state0/latency
0
# cat /sys/devices/system/cpu/cpu0/cpuidle/state0/residency
0
# cat /sys/devices/system/cpu/cpu0/cpuidle/state0/usage
12345

这里 latency 是退出延迟（微秒），residency 是目标驻留时间。governor会根据这两个值判断是否值得进入该状态。

我的经验： 调试时先看 usage 和 time。如果某个深度睡眠状态的 usage 一直是0，说明governor认为不值得进——要么延迟太大，要么驻留时间门槛太高。

4.2 C-State深度解析：从浅睡到深睡

C-State是ACPI规范里定义的概念，ARM平台虽然不完全照搬ACPI，但思想是相通的。简单说：

C-State 典型行为 退出延迟 功耗节省
C0 CPU正常运行 0 无
C1 WFI（等待中断），时钟门控 极低（~1μs） 约20-30%
C2 时钟门控+部分电源门控 中等（~10μs） 约50-60%
C3 电源门控+缓存刷新 较高（~100μs） 约80-90%

你想想看，C1就是浅睡，随时能醒。C3就是深度睡眠，醒来要重新初始化缓存。选哪个，取决于CPU接下来多久会被唤醒。

我在项目中遇到过一个问题：某款IoT设备待机功耗偏高，排查发现CPU一直在C1和C0之间来回跳，根本没进过C3。后来发现是某个定时器每10ms就触发一次中断，导致governor认为不值得进深度睡眠。调整定时器周期后，C3的进入率从0%升到了85%。

4.3 ARM generic idle driver配置

ARM平台默认使用 arm_idle 驱动，或者更通用的 cpuidle-arm 驱动。配置方法很简单：

Device Drivers --->
  [*] CPU Idle
    [*] ARM CPU Idle Driver
    [*] Generic ARM idle driver

驱动注册时，会通过设备树获取支持的C-State信息。典型的设备树节点长这样：

idle-states {
    entry-method = "psci";

    cpu_sleep_0: cpu-sleep-0 {
        compatible = "arm,idle-state";
        arm,psci-suspend-param = <0x0010000>;
        entry-latency-us = <10>;
        exit-latency-us = <20>;
        min-residency-us = <100>;
    };

    cpu_sleep_1: cpu-sleep-1 {
        compatible = "arm,idle-state";
        arm,psci-suspend-param = <0x0010001>;
        entry-latency-us = <50>;
        exit-latency-us = <100>;
        min-residency-us = <500>;
    };
};

这里 arm,psci-suspend-param 是关键参数，它告诉PSCI固件要进入哪个电源状态。不同的值对应不同的睡眠深度。

注意： 设备树里的 min-residency-us 必须大于 entry-latency-us + exit-latency-us，否则governor永远不会选这个状态。我曾经见过有人把 min-residency-us 设得比退出延迟还小，结果内核直接panic了。

4.4 WFI与WFI+深度睡眠模式切换实战

WFI（Wait For Interrupt）是ARM架构最基本的空闲指令。执行WFI后，CPU暂停流水线，等待中断唤醒。这是C1状态。

但WFI+深度睡眠就不一样了。它通过PSCI（Power State Coordination Interface）调用固件，让CPU进入更深的睡眠模式。流程如下：

  1. CPU Idle框架选择深度睡眠状态
  2. 调用PSCI的 CPU_SUSPEND 接口
  3. 固件保存CPU上下文，关闭电源域
  4. 中断到来时，固件恢复上下文，CPU继续执行

实战中，我们经常需要验证WFI+深度睡眠是否正常工作。我的做法是：

# 查看当前空闲状态统计
cat /sys/devices/system/cpu/cpu0/cpuidle/state*/name
cat /sys/devices/system/cpu/cpu0/cpuidle/state*/usage

# 手动触发深度睡眠（仅调试用）
echo 1 > /sys/devices/system/cpu/cpu0/cpuidle/state3/disable
echo 0 > /sys/devices/system/cpu/cpu0/cpuidle/state3/disable

嗯，这里要注意：手动禁用浅睡眠状态可以强制CPU进入深度睡眠，但生产环境千万别这么干——万一中断响应不及时，系统就挂了。

核心要点： WFI+深度睡眠的切换代价是退出延迟。如果你的系统对中断响应有硬实时要求（比如音频播放），深度睡眠的退出延迟可能导致buffer underrun。这时候宁可让CPU在C1多待一会儿。

4.5 知识结构图：CPU空闲管理全景

下面这张图展示了CPU Idle框架的核心组件和数据流，帮你快速建立整体认知：

CPU Idle框架结构图 CPU Idle框架核心组件与数据流 调度器 (idle线程) Governor (menu / ladder) Core (cpuidle核心) Driver (arm_idle / psci) 硬件 (C-State / PSCI) 关键决策依据 • 退出延迟 (latency) • 驻留时间 (residency) • 中断频率 数据流方向 调度器 → Governor → Core → Driver → 硬件

这张图把CPU Idle框架的层次关系和数据流画清楚了。从上到下，调度器触发idle流程，governor根据延迟和驻留时间选状态，core协调，driver执行，最终硬件进入对应的C-State。

4.6 避坑指南：我踩过的三个坑

做CPU空闲优化这些年，我踩过不少坑。挑三个典型的说说：

  • 坑一：设备树参数配错导致无法深度睡眠。我曾经把 min-residency-us 设得比 exit-latency-us 还小，结果内核日志里全是 cpuidle: state X not allowed。排查了半天才发现是参数写反了。
  • 坑二：中断风暴让CPU无法进入C2/C3。某款网卡驱动每1ms触发一次中断，governor算下来觉得进深度睡眠不划算，CPU一直在C1晃悠。后来把中断合并（interrupt coalescing）打开，问题解决。
  • 坑三：PSCI固件版本不匹配。ARM平台依赖PSCI进行电源管理，如果内核和固件的PSCI版本不一致，深度睡眠可能直接挂掉。我遇到过进C3后CPU再也醒不过来的情况，最后只能硬重启。
调试小技巧： 用 trace-cmd 抓取 cpu_idle 事件，可以精确看到每个CPU在什么时间进入了哪个C-State。命令：trace-cmd record -e cpu_idle sleep 10，然后用 trace-cmd report 查看。

好了，这一章的内容就到这里。CPU空闲管理是低功耗优化的基石，理解C-State的切换逻辑和配置方法，后面做动态调频、热管理才能得心应手。

← 上一章 📖 返回目录 下一章 →