爬一手好线杆聊CPU的电源管理，绕不开CPUFreq。很多人第一次听说这个词，以为只是“给CPU降个频省点电”这么简单，实际等你真去翻内核代码或者看手机功耗曲线，就会发现它是一个贯穿操作系统调度器、硬件电压调节器和整个功耗控制策略的关键子系统。CPUFreq也是电源管理入门系列里最值得花时间啃的一块：它决定了一颗CPU在任意时刻应该跑在哪个工作点上，直接决定了应用卡不卡、手机热不热、服务器电费高不高。
先从最现实的场景看。手机是最典型的例子：屏幕亮着刷信息流，负载忽高忽低，如果CPU一直满频跑，SoC功耗轻松上到4到5瓦，电池会肉眼可见地往下掉，机身也会烫手；但如果一直低频率运行，滑页面就会卡顿掉帧。笔记本也类似，散热鳍片的尺寸和风扇噪音，很大程度取决于CPU功耗被压得多狠。服务器那边更直接，机柜的供电和散热容量是成本大头，同样的计算任务，功耗优化做得好不好，直接影响运营成本。
所以“CPU越快越好”这句话放到功耗受限的嵌入式系统和数据中心里都是不成立的。真正需要的是一个能在运行中动态决策“现在跑多快最划算”的机制，这个机制就是CPUFreq，全称是CPU Frequency Scaling，属于Linux电源管理框架里的核心成员。它通过动态调整CPU核心的工作频率和对应的供电电压，在性能与功耗之间做实时博弈。它和后面会讲到的CPUIdle一起，构成了处理器功耗控制的一对轮子：一个管“运行的时候跑多快”，一个管“空闲下来睡多深”。
这篇主要面向三类人：一是做嵌入式、驱动和BSP开发的工程师，需要知道CPUFreq从框架到硬件如何协作；二是做系统性能优化的人，经常要跟各种governor和调频参数打交道；三是纯粹想搞明白“为什么手机能平衡续航和流畅度”的开发者。读完你至少能回答几个常见问题：schedutil为什么取代了ondemand？P-state和C-state区别在哪？CPU让电源管理芯片调压时，中间发生了什么？下面一个个拆开讲。
1. CPU频率调节到底在解决什么问题：从手机到服务器的共同痛点
先说个反直觉的结论：在功耗受限的系统里，CPU有一颗“跑得更快”的心，但它不该总是如愿。假设手机SoC满频能跑3GHz，单大核瞬时功耗轻松冲到3瓦以上；而刷短视频这种场景，大部分操作其实只需要1.5GHz左右就能流畅完成。如果一直满频，多出来的性能用户感知不到，多出来的热量和耗电却是实打实的。反过来，如果频率给得不够，列表滑动就可能掉帧，游戏画面就可能波动。所以问题的本质不是“能不能快”，而是“该不该快、快到什么程度刚好”。
服务器的情况更极端。一台双路服务器几十个核，每颗核多跑一点频率，整机功耗就多几十瓦；数据中心里成千上万台服务器，功耗差一个百分点，散热和电费的差距都相当可观。很多云计算厂商在卖CPU算力时按核数和主频收费，如何在满足SLA的前提下尽可能把CPU频率压到“够用”，是平台工程师每天都在琢磨的事。这也是为什么云服务器上经常能看到performance和schedutil两种governor被反复测试对比——省电和性能之间的平衡点，不同业务差异很大。
笔记本和一体机则是另一类典型场景。机器满载时CPU发热，风扇转速跟着拉高，噪音就上来了；而日常轻度办公时，如果CPU能在几毫秒内把频率降到足够低的水平，机身就能保持安静和低温。整个体验的核心，就是CPUFreq对负载变化的响应速