4、CPUIdle框架：CPUIdle子系统设计、C-State（C0/C1/C2/C3...）、Ladder Governor与Menu Governor、CPUIdle驱动开发
好，我们进入电源管理里最贴近CPU核心的一个模块——CPUIdle框架。
说实话，我早年刚接触Linux电源管理时，觉得CPUIdle不就是让CPU歇着吗？有什么好讲的？后来在做一个嵌入式项目，发现设备待机功耗死活降不下来，一查才发现CPU压根没进深睡眠，一直在C1状态晃悠。嗯，从那以后，我再也不敢小看这个框架了。
4.1 CPUIdle子系统设计
CPUIdle子系统，说白了就是管理CPU空闲时该干什么。你想想看，CPU没事干的时候，总不能一直全速运转吧？那电费谁扛得住？
它的核心目标就一个：在CPU空闲时，尽可能降低功耗，同时保证在需要时能快速恢复。
整个子系统分三层：
- Governor层：决策层。根据系统负载、预测空闲时长，决定选哪个C-State。
- Core层：调度层。把Governor的决策翻译成具体操作，调用驱动接口。
- Driver层：执行层。真正操作硬件寄存器，让CPU进入指定状态。
我个人的习惯是，把Governor想象成项目经理，Core是技术主管，Driver是一线码农。项目经理说“我们要省电”，技术主管说“那进C3吧”，码农就去写寄存器了。
核心数据结构：struct cpuidle_device 和 struct cpuidle_driver。
每个CPU核心都有一个 cpuidle_device，记录当前状态、上次退出时间等。而 cpuidle_driver 则描述硬件支持哪些C-State、每个状态的进入/退出函数。
4.2 C-State：从C0到C3...
C-State是ACPI规范定义的一组CPU电源状态。数字越大，睡得越沉，功耗越低，但唤醒延迟也越大。
| 状态 | 描述 | 功耗 | 唤醒延迟 | 我踩过的坑 |
|---|---|---|---|---|
| C0 | CPU正在干活，全速运行 | 最高 | 0 | —— |
| C1 | 暂停执行（HLT指令），但保持所有状态 | 较高 | 极短（~1us） | 很多驱动在C1下还能响应中断，但功耗降得有限 |
| C2 | 时钟门控，部分缓存可能关闭 | 中等 | 较短（~10us） | 我遇到过某个网卡驱动在C2下丢包，后来发现是DMA超时了 |
| C3 | 深度睡眠，关闭PLL、缓存可能掉电 | 很低 | 较长（~100us+） | 曾经有个项目，进C3后USB控制器直接挂了，查了两天才发现是电源域没处理好 |
这里有个关键点：C-State不是越多越好。你想想看，如果系统频繁在C0和C3之间切换，光状态切换的开销就够喝一壶的了。我见过一个极端案例，某设备因为C-State切换太频繁，功耗反而比一直待在C1还高。
注意：不是所有硬件都支持所有C-State。ARM架构下通常叫WFI（Wait For Interrupt）和WFE（Wait For Event），对应x86的C1和C2。具体支持哪些，得看芯片手册。
4.3 Ladder Governor：老派的阶梯式决策
Ladder Governor，名字很形象——像爬梯子一样，一级一级往下走。
它的逻辑很简单：
- CPU空闲时，先尝试进入当前允许的最浅睡眠状态。
- 如果空闲时间足够长，就尝试更深一级的状态。
- 一旦有中断来了，就回到C0，下次再从最浅的开始。
说白了，就是“先试试水，不行再深潜”。
我在早期的一个MIPS架构项目上用过Ladder Governor。那时候系统负载很稳定，基本就是跑一个采集任务，空闲时间很规律。Ladder表现得还不错，功耗比一直用C1低了大概15%。
但它的缺点也很明显：反应慢。如果系统负载忽高忽低，Ladder还在那慢悠悠地爬梯子，根本来不及响应。所以现在新内核默认都不用Ladder了。
适用场景：嵌入式设备，负载模式固定，对延迟不敏感。比如智能电表、传感器节点这类。
4.4 Menu Governor：现代内核的默认选择
Menu Governor，名字听着像菜单，其实它的核心是预测。
它不傻乎乎地一级一级试，而是根据历史数据预测下一次空闲会持续多久，然后直接选最合适的C-State。
怎么预测的？我简单说下：
- 记录每次空闲的时长，维护一个指数加权移动平均。
- 考虑下一个定时器（tick）还有多久到期。
- 结合系统负载、中断频率等因素，算出一个“预测空闲时间”。
- 然后从所有C-State里选一个“唤醒延迟 < 预测空闲时间”且功耗最低的。
你可能会问：“预测准吗？”说实话，不准的时候挺多的。但Menu Governor有个聪明的地方——它引入了“奖励机制”。如果上次预测对了（空闲时间足够长），下次就更大胆地选深睡眠。如果预测错了（刚进C3就被唤醒），下次就保守一点。
核心代码片段（简化版）：
// 预测空闲时长
predicted_us = get_typical_interval(dev);
// 考虑下一个tick
next_timer_us = get_next_timer_event();
// 取最小值作为最终预测
target_residency = min(predicted_us, next_timer_us);
// 遍历C-State，选最合适的
for (i = 0; i < drv->state_count; i++) {
if (drv->states[i].target_residency <= target_residency)
best = i;
}我个人在x86服务器上做过对比测试：同样负载下，Menu Governor比Ladder平均省电8%-12%。而且响应速度更快，系统不会因为频繁切换C-State而卡顿。
注意：Menu Governor依赖高精度定时器（hrtimer）。如果你的硬件没有高精度定时器，或者内核没开CONFIG_HIGH_RES_TIMERS，那Menu Governor的表现会大打折扣。
4.5 CPUIdle驱动开发实战
好，到了动手环节。写一个CPUIdle驱动，其实没那么玄乎。我以ARM平台为例，给你拆解一下。
第一步：定义C-State
static struct cpuidle_state arm_idle_states[] = {
{
.name = "WFI",
.desc = "Wait for Interrupt",
.flags = CPUIDLE_FLAG_TIMER_STOP,
.exit_latency = 1, // 1us唤醒延迟
.target_residency = 10, // 至少空闲10us才值得进
.enter = &arm_enter_wfi,
},
{
.name = "C2",
.desc = "Clock gating",
.flags = CPUIDLE_FLAG_TIMER_STOP,
.exit_latency = 50,
.target_residency = 200,
.enter = &arm_enter_c2,
},
};第二步：实现进入函数
static int arm_enter_wfi(struct cpuidle_device *dev,
struct cpuidle_driver *drv, int index)
{
// 保存上下文
// 执行WFI指令
asm volatile("wfi");
// 唤醒后恢复
return index;
}第三步：注册驱动
static struct cpuidle_driver arm_idle_driver = {
.name = "arm_idle",
.owner = THIS_MODULE,
.states = arm_idle_states,
.state_count = ARRAY_SIZE(arm_idle_states),
};
static int __init arm_idle_init(void)
{
return cpuidle_register_driver(&arm_idle_driver);
}
module_init(arm_idle_init);避坑指南：
- 我曾经在注册驱动时忘了设置
target_residency，结果Governor死活不选深睡眠。后来发现默认值是0，相当于“随便进”，但Menu Governor会认为这个状态不值得进。 - 还有一次，我在
enter函数里忘了关中断，结果进WFI后直接被同一个中断唤醒，形成了死循环。嗯，那感觉就像你刚躺下就被闹钟吵醒，然后发现闹钟是你自己设的。
最后说一句：CPUIdle驱动开发，难点不在代码，而在调试。你很难直观地看到CPU到底进了哪个C-State。我一般用 cpuidle_info 这个tracepoint，或者直接读硬件寄存器来确认。如果你手头有JTAG，那是最理想的。
好了，这一章就到这里。下一章我们聊聊CPU热插拔和动态调频，那又是另一番天地了。