CPU频率与电压调节：cpufreq框架与governor策略
说到CPU功耗调优，频率和电压调节是绕不开的核心话题。我刚开始接触Linux功耗优化时，第一反应就是：CPU跑慢点不就行了？后来发现，事情远没那么简单。频率调低确实省电，但响应变慢；频率拉高性能上去了，功耗又飙升。这中间的平衡，全靠cpufreq框架和它的governor策略来把控。
cpufreq框架：CPU频率调度的中枢
cpufreq是Linux内核里负责CPU频率和电压调节的核心框架。说白了，它就是个调度器——根据系统负载，动态调整CPU的运行频率和电压。为什么要把频率和电压放在一起说？因为这两者物理上就是绑定的。频率越高，需要的电压也越高，功耗呈平方关系增长。反过来，降频的同时降压，省电效果才明显。
cpufreq框架的架构分三层：
- 核心层：提供统一的接口，管理所有CPU的调频策略
- 驱动层：跟硬件打交道，实际执行频率和电压的切换
- governor层：决定「什么时候调、调到多少」的决策者
我在项目中遇到过一个问题：某款ARM开发板，跑着跑着CPU频率就锁死在最低档，性能惨不忍睹。查了半天，发现是cpufreq驱动没正确注册，governor根本没生效。嗯，这种坑，排查起来真的很费时间。
governor策略：五种调频模式详解
governor是cpufreq的灵魂。它决定了CPU在什么负载下升频、什么情况下降频。Linux内核目前支持五种主流governor，我一个个说。
1. performance：性能至上
这个策略最简单粗暴——CPU永远跑在最高频率。功耗？不考虑。适合那些对延迟极度敏感的场景，比如实时音频处理、高频交易。我个人习惯在跑基准测试时用这个，省得频率波动影响结果。
2. powersave：省电到底
跟performance相反，CPU永远跑在最低频率。适合后台任务、待机场景。但说实话，我很少直接用这个——因为响应太慢了，用户体验很差。你想想看，点个按钮等两秒才反应，省那点电值吗？
3. ondemand：按需调频
这是最经典的策略。CPU空闲时降频，负载上来立刻升频。它有个采样周期，每隔几十毫秒检查一次CPU使用率，超过阈值就升频。优点是响应快，缺点是频繁调频会带来额外的功耗开销。
核心参数：
sampling_rate：采样间隔，默认通常10msup_threshold：升频阈值，默认95%ignore_nice_load：是否忽略nice进程的负载
4. conservative：保守调频
跟ondemand思路类似，但调频更「温柔」。它不会一下子跳到最高频，而是逐步升频。适合那些负载波动不大的场景，比如Web服务器。我曾在某款低功耗服务器上测试过，conservative比ondemand省电约8%，但响应慢了15%左右。怎么选？看业务需求。
5. schedutil：调度器驱动的调频
这是目前最先进的策略。它直接跟CFS调度器（完全公平调度器）集成，利用调度器本身的负载信息来做调频决策。说白了，调度器知道每个任务需要多少CPU时间，schedutil就根据这个信息来调频，比ondemand那种「看使用率」的方式更精准。
为什么schedutil更好？我举个例子。假设一个任务每10ms运行1ms，使用率只有10%。ondemand看到使用率低，会降频。但schedutil知道这个任务需要「短时间爆发」，所以会保持高频。这种细节，只有调度器自己最清楚。
我的建议：新内核（4.7+）优先用schedutil。老内核或者特殊场景，ondemand是稳妥的选择。powersave和performance只在特定测试场景下用。
用户态调频工具：cpupower与cpufrequtils
内核里的governor配置好了，但日常调试和监控，还得靠用户态工具。这里介绍两个最常用的。
cpupower：现代Linux的标配
cpupower是内核自带的工具，功能很全。查看当前频率、设置governor、调整参数，一条命令搞定。
# 查看所有CPU的频率信息
cpupower frequency-info
# 设置所有CPU使用schedutil策略
cpupower frequency-set -g schedutil
# 查看CPU0的当前频率
cpupower monitor -c 0我个人习惯用cpupower monitor来实时观察频率变化。它有个交互模式，能持续刷新数据，调试时特别好用。
cpufrequtils：老牌工具集
这个工具集包含cpufreq-info、cpufreq-set等命令。功能跟cpupower类似，但更轻量。有些嵌入式系统里，cpufrequtils是唯一的选择。
# 查看支持的频率和governor
cpufreq-info
# 设置CPU0为ondemand策略
cpufreq-set -c 0 -g ondemand
# 设置CPU0的最低频率为1.2GHz
cpufreq-set -c 0 -d 1.2GHz我曾经踩过的坑：在某个嵌入式项目里，我用cpufreq-set设置了最低频率，结果系统直接卡死。后来发现，那个SoC的电压调节有硬件限制，频率低于某个值后电压跟不上，导致CPU不稳定。所以，调频之前，一定要确认硬件支持的频率范围。
实战：如何选择governor策略
说了这么多，到底怎么选？我总结了一个简单的决策表：
| 场景 | 推荐策略 | 理由 |
|---|---|---|
| 实时系统、低延迟要求 | performance | 避免频率切换带来的延迟抖动 |
| 笔记本、移动设备 | schedutil | 兼顾性能和续航，调度器感知更精准 |
| 服务器、后台任务 | conservative | 逐步调频，减少功耗波动 |
| 嵌入式、电池供电 | ondemand | 成熟稳定，参数可调范围大 |
| 基准测试、性能验证 | performance | 排除频率干扰，结果可复现 |
你可能会问：能不能动态切换？当然可以。我经常在调试时先设成performance跑一轮，再切到schedutil跑一轮，对比功耗和性能的差异。这种「AB测试」的方法，能帮你找到最适合当前负载的策略。
最后说一句：调频不是万能的。如果CPU本身设计就有问题，比如漏电流太大，那再怎么调频也省不了多少电。但话说回来，在现有硬件上，选对governor、配好参数，省个10%-20%的功耗是完全可能的。这，就是cpufreq框架的价值所在。