2. CPU空闲管理：cpuidle框架、idle governor策略、cpuidle驱动注册与实现
好，咱们接着聊CPU空闲管理。说实话，这一块在电源管理里属于「看起来简单，做起来全是坑」的典型。你想想看，CPU没事干的时候，总不能让它一直空转吧？那功耗不就白烧了？所以内核搞了一套cpuidle框架，专门管这事。
2.1 cpuidle框架：CPU空闲时的「管家」
cpuidle框架，说白了就是一套让CPU在空闲时「睡个好觉」的机制。它负责三件事：
- 检测空闲时机：当CPU的idle线程运行时，说明当前没有任务可调度
- 选择睡眠深度：根据系统负载和历史数据，决定睡多深
- 执行睡眠操作：调用底层硬件接口，让CPU进入对应的低功耗状态
我个人习惯把cpuidle框架比作酒店前台。你（CPU）累了想休息，前台（cpuidle）会问你：「先生，您想睡多久？我们有大堂沙发（浅睡眠）、标准间（中等深度）、总统套房（深度睡眠）。」你选好之后，前台带你去房间，然后你躺下，门一关——CPU就进入空闲状态了。
核心数据结构：struct cpuidle_device 和 struct cpuidle_driver
每个CPU都有一个cpuidle_device，记录它自己的空闲状态。而cpuidle_driver则定义了该CPU支持哪些空闲状态（C-states）。
2.2 idle governor策略：谁来决定睡多深？
governor，就是那个「前台接待员」。它根据当前系统的「困意程度」来决定推荐哪个C-state。内核里主要有两个governor：
| Governor | 策略 | 适用场景 |
|---|---|---|
| menu | 基于预测的贪心策略 | 大多数通用场景（默认） |
| ladder | 逐级递增的保守策略 | 实时性要求高的场景 |
menu governor：我项目中用得最多的就是它。它会根据历史空闲时长来预测下一次空闲会持续多久。如果预测到空闲时间很长，就直接推荐深度睡眠（比如C3）。如果预测很短，就只进C1。说白了就是「赌一把」，赌对了省电，赌错了醒来会有点延迟。
ladder governor：这个就保守多了。它不会直接跳到深度睡眠，而是一级一级往下走。先C1，再C2，再C3。每次醒来后如果发现空闲时间还够，就再往下走一级。我曾经在一个实时控制项目里用过它——因为menu的预测偶尔会出错，导致唤醒延迟超标，ladder虽然省电少一点，但胜在稳定。
避坑指南：我曾经在一个ARM平台上遇到过menu governor频繁进入C3导致中断响应变慢的问题。后来发现是timer tick的预测不准。解决办法是调整cpuidle.governor= ladder，或者修改menu governor的预测参数。
2.3 cpuidle驱动注册与实现：让硬件「听懂」指令
governor只是做决策，真正让CPU「睡过去」的，是底层的cpuidle驱动。每个CPU架构（ARM、x86、RISC-V等）都需要实现自己的cpuidle驱动。
驱动的注册流程大概是这样的：
// 1. 定义cpuidle_state数组
static struct cpuidle_state arm_idle_states[] = {
{
.enter = arm_enter_idle_state,
.exit_latency = 10, // 退出延迟，单位us
.target_residency = 20, // 目标驻留时间，单位us
.flags = CPUIDLE_FLAG_TIMER_STOP,
.name = "C1",
.desc = "ARM WFI",
},
{
.enter = arm_enter_idle_state,
.exit_latency = 100,
.target_residency = 500,
.flags = CPUIDLE_FLAG_TIMER_STOP,
.name = "C2",
.desc = "ARM power down",
},
};
// 2. 定义cpuidle_driver
static struct cpuidle_driver arm_idle_driver = {
.name = "arm_idle",
.owner = THIS_MODULE,
.states = arm_idle_states,
.state_count = ARRAY_SIZE(arm_idle_states),
};
// 3. 注册驱动
static int __init arm_idle_init(void)
{
int ret;
ret = cpuidle_register_driver(&arm_idle_driver);
if (ret)
return ret;
// 为每个CPU注册设备
for_each_possible_cpu(cpu) {
struct cpuidle_device *dev = &per_cpu(arm_idle_dev, cpu);
dev->cpu = cpu;
ret = cpuidle_register_device(dev);
if (ret) {
pr_err("Failed to register cpuidle device for CPU%d\n", cpu);
return ret;
}
}
return 0;
}
嗯，这里要注意几个关键参数：
- exit_latency：从睡眠状态唤醒需要多长时间。这个值越小越好，但深度睡眠通常延迟更大。
- target_residency：至少要睡多久才划算。如果空闲时间比这个短，那还不如不睡，因为唤醒的代价比省的电还大。
- CPUIDLE_FLAG_TIMER_STOP：这个标志表示进入该状态后，CPU的本地定时器会停止。governor看到这个标志就会知道：嗯，得用broadcast timer来唤醒我。
特别注意：我在调试一个嵌入式设备时，发现CPU进入C2后网络中断响应慢了300us。查了半天，原来是C2状态把L2 cache给flush掉了，导致中断处理程序需要重新加载代码。后来我们在C2的enter函数里加了条件判断：如果当前有网络中断pending，就降级到C1。
2.4 实际项目中的调优经验
说实话，cpuidle这块最头疼的不是框架本身，而是调参。我总结了几条经验：
- 别盲目追求深度睡眠：省电和省性能是矛盾的。我曾经在一个视频播放设备上，为了省电把C3设成了首选，结果画面卡顿得一塌糊涂。后来把target_residency从500us调到了2ms，问题就解决了。
- 关注中断唤醒源：有些外设（比如GPIO按键、UART）的中断频率很高，会导致CPU频繁进出空闲状态。这种情况下，深度睡眠反而更耗电——因为每次进出都有开销。我建议用powertop工具跑一下，看看哪些中断在频繁唤醒CPU。
- 多核系统的坑：在SMP系统里，一个CPU进入深度睡眠可能会影响其他CPU的cache一致性。ARM的big.LITTLE架构尤其要注意——大核和小核的空闲策略应该分开配置。
最后说一句，cpuidle框架虽然看起来简单，但真正用好它，需要对硬件行为、中断延迟、调度器都有深入理解。我刚开始做电源管理时，总觉得「让CPU睡觉还不简单？」结果被现实狠狠教育了几次。嗯，希望你能少走这些弯路。