📚 课程目录第4章 CPU频率与电压调节

4. CPU频率与电压调节：cpufreq驱动框架、governor策略与DVFS调优实战

说到嵌入式Linux的功耗管理，CPU频率和电压调节绝对是核心中的核心。说白了，这就是系统最直接的"油门"和"刹车"——跑得快就费电，跑得慢就省电。怎么在性能和功耗之间找到那个平衡点？这就是我们今天要聊的DVFS（动态电压频率调整）。

我刚开始做嵌入式项目时，总觉得CPU频率调来调去太麻烦，干脆直接跑最高频算了。结果产品发热严重，电池续航惨不忍睹。后来才明白，合理的频率调节，能让系统在95%的时间里用不到最高频，功耗却能降下来一大截。

4.1 cpufreq驱动框架：谁在管CPU的频率？

Linux内核里的cpufreq子系统，就是专门干这个活的。它分三层：

底层驱动：直接操作硬件寄存器，读写PLL分频系数和电压调节器
中间核心层：提供统一的接口，管理策略切换和频率表
上层governor：决定"什么时候该升频，什么时候该降频"

我习惯把cpufreq比作一个变速箱。底层驱动是齿轮和离合器，核心层是换挡机构，而governor就是那个判断该不该换挡的司机。

关键数据结构：cpufreq_policy

每个CPU（或每组CPU）对应一个policy，里面记录了当前频率范围、governor、调节延迟等参数。调试时第一件事就是看这个结构体里的值对不对。

# 查看当前CPU的cpufreq信息
cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_available_frequencies
cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_available_governors
cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq

嗯，这里要注意：不同SoC的cpufreq驱动实现差别很大。比如高通平台用cpufreq-dt，而有些自研芯片会自己实现一套。我曾经在一个项目里遇到过驱动注册失败，查了半天发现是设备树里operating-points节点写错了频率值。

4.2 Governor策略：四种"司机"的驾驶风格

Linux内核默认提供了好几种governor，每种对应不同的调频策略。我挑最常用的四个来讲：

Governor	策略描述	适用场景	功耗表现
performance	始终跑在最高频率	性能测试、实时性要求极高的场景	功耗最高
powersave	始终跑在最低频率	后台任务、待机模式	功耗最低
ondemand	负载高时升频，空闲时降频	通用场景，兼顾性能和功耗	中等
schedutil	基于调度器负载信息调频	现代内核推荐，响应更平滑	优秀

你想想看，performance和powersave就是两个极端，一个永远地板油，一个永远怠速。而ondemand和schedutil才是真正干活的。

我的建议：新项目直接上schedutil。它利用调度器本身的负载跟踪（PELT），比ondemand的采样方式更精准，频率切换也更平滑。我在一个视频编解码项目里对比过，schedutil比ondemand省了约8%的功耗，而且卡顿感明显减少。

4.2.1 ondemand的"采样陷阱"

ondemand的工作原理是每隔一段时间（默认10ms）采样CPU负载，然后决定是否调频。这有个问题：采样间隔太短，频繁调频反而增加功耗；间隔太长，响应又跟不上。

我曾经在一个工业控制项目里，用ondemand时发现系统响应忽快忽慢。后来把sampling_rate从10ms改成5ms，问题解决了，但功耗也上去了。这就是典型的"采样陷阱"——你永远在精度和开销之间做取舍。

4.2.2 schedutil的"调度器视角"

schedutil是内核4.7之后引入的，它直接从CFS调度器获取每个任务的负载信息。说白了，调度器知道每个任务"有多重"，schedutil就根据这个重量来调频。

这样做的好处是：频率变化和任务调度是同步的，不会出现"任务已经跑完了，频率还没升上去"的尴尬情况。

# 切换到schedutil
echo schedutil > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor

# 查看schedutil的调频参数（如果有）
cat /sys/devices/system/cpu/cpu0/cpufreq/schedutil/up_rate_limit_us
cat /sys/devices/system/cpu/cpu0/cpufreq/schedutil/down_rate_limit_us

4.3 DVFS调优实战：从理论到落地

理论知识讲完了，咱们来点实际的。DVFS调优说白了就三步：摸底、调参、验证。

4.3.1 第一步：摸底——搞清楚你的CPU频率表

先看看SoC支持哪些频率和电压组合。这些信息通常在设备树的operating-points节点里：

// 设备树中的OPP表示例
cpu_opp_table: opp-table {
    compatible = "operating-points-v2";
    opp-shared;

    opp-200000000 {
        opp-hz = /bits/ 64 <200000000>;
        opp-microvolt = <950000>;
    };
    opp-400000000 {
        opp-hz = /bits/ 64 <400000000>;
        opp-microvolt = <1000000>;
    };
    opp-800000000 {
        opp-hz = /bits/ 64 <800000000>;
        opp-microvolt = <1100000>;
    };
    opp-1200000000 {
        opp-hz = /bits/ 64 <1200000000>;
        opp-microvolt = <1250000>;
    };
};

警告：千万不要随意修改OPP表中的电压值！电压过低会导致CPU计算错误，甚至死机。我见过一个团队为了省电把电压降了100mV，结果设备在高温环境下频繁重启。芯片的电压-频率曲线是经过验证的，降电压一定要做充分的稳定性测试。

4.3.2 第二步：调参——找到你的"甜区"

调参的核心是找到性能-功耗的平衡点。我一般会做这么几件事：

确定工作负载特征：是突发性高负载（如触控响应），还是持续中负载（如视频播放）？
调整调频阈值：比如ondemand的up_threshold，默认是95%，你可以试试80%或70%
调整调节延迟：sampling_rate和rate_limit_us，让频率变化更激进或更保守
绑定CPU亲和性：把关键任务绑到某个核上，避免跨核迁移导致的频率波动

# 调整ondemand的升频阈值（从95%降到80%）
echo 80 > /sys/devices/system/cpu/cpu0/cpufreq/ondemand/up_threshold

# 调整采样间隔（从10ms改成5ms）
echo 5000 > /sys/devices/system/cpu/cpu0/cpufreq/ondemand/sampling_rate

4.3.3 第三步：验证——用数据说话

调完参数，得用工具验证效果。我常用的组合是：

perf stat：统计CPU周期、指令数、缓存命中率
powertop：查看每个进程的功耗估算
trace-cmd：跟踪cpufreq的频率切换事件
外部功率计：最准确的方法，直接测整板功耗

# 用trace-cmd跟踪频率切换
trace-cmd record -e cpufreq_interactive_target -e cpu_frequency sleep 10
trace-cmd report

我记得有一次调优，用trace-cmd发现某个驱动在中断处理里频繁触发频率切换，每秒切换了上千次。后来加了rate_limit，频率切换次数降到了几十次，功耗直接降了15%。

4.4 DVFS调优的"避坑指南"

做DVFS调优这些年，我踩过的坑不少。挑几个典型的说说：

坑1：多核异构的调频策略

大小核架构（如ARM big.LITTLE）里，大核和小核的调频策略应该分开。我曾经图省事给所有核用了同一个governor，结果小核频繁升频，大核反而在摸鱼。正确的做法是：大核用schedutil保证响应，小核用ondemand或powersave省电。

坑2：调频延迟和中断延迟的冲突

有些实时任务对中断响应时间有严格要求。如果调频太频繁，调频本身会关中断，导致中断延迟抖动。我建议对实时核固定频率，或者用userspace governor手动控制。

坑3：温度对频率的影响

芯片温度升高时，通常需要降频来保护硬件。这就是thermal throttle。如果你的DVFS策略和thermal策略冲突，系统会反复升频-降频-升频，形成震荡。我一般会留出5-10℃的温度余量，让thermal介入前DVFS先主动降频。

4.5 本章小结

cpufreq和DVFS是嵌入式Linux功耗管理的基石。记住几个关键点：

框架：cpufreq分三层，底层驱动、核心层、governor
策略：新项目优先用schedutil，老项目用ondemand调参
调优：摸底→调参→验证，三步走，用数据说话
避坑：注意多核异构、中断延迟、温度影响

下一节我们会聊到CPU Idle状态管理，也就是CPU没事干的时候怎么省电。那个话题更有意思，因为很多系统70%的时间CPU都在"摸鱼"——怎么让摸鱼摸得更省电，才是真正的学问。