第2章 CPU调优

CPU调优：频率、调度与大小核的实战艺术

好，咱们接着聊CPU调优。说实话，平板电脑的CPU调优，跟服务器或者台式机完全是两码事。服务器追求的是“跑得快”，而平板追求的是“跑得巧”——既要快，又要省电，还不能烫手。这中间的平衡，全靠我们调优工程师来拿捏。

我个人习惯把CPU调优分成三个层面：频率怎么跑、任务怎么分、电压怎么控。咱们一个一个来拆解。

CPU频率与调度策略：别让CPU“傻跑”

先说说频率。CPU频率不是越高越好，这道理大家都懂。但真正落地的时候，很多新手容易犯一个错：把最高频率设得很高，结果一跑应用就撞温度墙，然后瞬间降频，体验反而更差。

核心思路：频率要“按需分配”。

我一般会先看几个关键指标：

负载类型：是持续计算（比如游戏），还是突发任务（比如打开App）？
温度余量：当前芯片温度是多少？离85℃还有多远？
功耗预算：整机功耗不能超过某个值，比如平板通常限制在8W-15W之间。

举个例子，我在调一款骁龙8系的平板时，发现它的CPU在跑《原神》时，大核动不动就冲到3.0GHz。结果呢？3分钟后温度飙到90℃，然后强制降到1.2GHz，游戏直接卡成PPT。这其实就是典型的“傻跑”策略。

我当时的做法是：把最高频率限制在2.6GHz，同时把降频阈值从85℃调整到80℃。你猜怎么着？虽然峰值性能降了一点，但全程稳定在2.4GHz左右，帧率反而更平滑了。

调优口诀：频率不是跑得快，而是跑得稳。稳不住的频率，就是废频率。

调度策略方面，Linux内核的CFS（完全公平调度器）是默认选择。但平板场景下，我建议打开 energy_aware 调度模式。这个模式会让调度器优先考虑能效，而不是单纯追求“公平”。

# 查看当前调度策略
cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor

# 设置为性能模式（调试用，不建议长期开启）
echo "performance" > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor

# 设置为节能模式（日常使用推荐）
echo "powersave" > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor

# 更推荐：使用schedutil（动态调频）
echo "schedutil" > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor

我个人更倾向于 schedutil 策略。它直接跟调度器挂钩，能根据任务的实时需求动态调整频率，反应速度比传统的 ondemand 快得多。

大小核架构优化：别让“小核”闲着，“大核”累死

现在的平板CPU基本都是ARM的big.LITTLE架构，或者类似的三丛集架构（比如1+3+4）。说白了，就是有性能核（大核）和效率核（小核）。

调优的关键在于：什么任务该跑在大核上，什么任务该跑在小核上？

我见过最糟糕的配置是：所有任务都往大核上塞。结果小核闲得发慌，大核热得冒烟。这就像让一个举重运动员去干绣花的活，浪费资源。

我的分配原则：

小核（Cortex-A55/A510）：处理后台任务、系统服务、轻量级应用（如时钟、通知）。
中核（Cortex-A78/A710）：处理日常应用（如微信、浏览器、视频播放）。
大核（Cortex-X1/X2/X3）：处理突发高负载（如游戏加载、应用启动、图像渲染）。

嗯，这里要注意：不要试图让大核一直跑。大核的功耗是小核的3-5倍，长时间运行会迅速耗尽电池并引发过热。

我曾经在调一款联发科天玑9000的平板时，发现它的CPU affinity（CPU亲和性）设置有问题。系统把所有的UI渲染任务都绑在了大核上，导致滑动列表时大核频繁启动，功耗飙升。后来我通过修改 cpuset 配置，把UI渲染任务限制在中核和小核上，功耗直接降了15%。

实战技巧：使用 taskset 命令可以手动绑定任务到指定核心。比如：

# 将PID为1234的进程绑定到CPU0和CPU1（小核）
taskset -p 0x03 1234

但注意，这只是调试手段。正式产品中，建议通过内核的 cgroup 和 cpuset 机制来统一管理。

动态调频调压（DVFS）：电压和频率的“双人舞”

DVFS，说白了就是根据负载动态调整CPU的电压和频率。频率越高，需要的电压也越高。但电压高了，功耗是呈平方增长的（P ∝ V²f）。所以，DVFS的核心就是：在满足性能的前提下，尽可能降低电压。

这里有个概念叫“硅片体质”。同一批芯片，有的体质好，能在低电压下跑高频；有的体质差，需要高电压才能稳定。所以，DVFS调优不能一刀切，得针对具体芯片做校准。

DVFS调优的步骤：

确定频率表：列出CPU支持的所有频率点（比如1.2GHz、1.5GHz、1.8GHz...）。
确定电压表：为每个频率点找到最低稳定电压。这需要通过压力测试来验证。
设置调频策略：选择 schedutil 或 interactive 等调频器。
验证稳定性：跑满负载，检查是否有死机、重启或计算错误。

我记得有一次，我在调一款平板时，为了追求极致的能效，把电压压得太低了。结果在跑安兔兔时，CPU频繁报错，系统日志里全是 Undefined Instruction 错误。后来我把电压往上调了20mV，问题就解决了。你看，DVFS调优就是在这种“临界点”上跳舞。

警告：电压调得太低，会导致CPU计算错误，甚至损坏文件系统。调优时一定要做好备份，并且逐步调整，每次只改5-10mV。

下面是一个典型的DVFS配置示例（基于Linux内核的 cpufreq 框架）：

# 查看当前频率和电压
cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq
cat /sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_cur_freq

# 查看可用频率
cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_available_frequencies

# 手动设置频率（调试用）
echo 1800000 > /sys/devices/system/cpu/cpu0/cpufreq/scaling_setspeed

# 查看电压表（不同平台路径不同，这里以MTK为例）
cat /proc/cpufreq/MT_CPU_DVFS/cur_volt

在实际产品中，DVFS通常由硬件PMIC（电源管理芯片）和内核驱动协同完成。我们工程师要做的，就是找到那个“甜蜜点”——性能够用、功耗最低、温度可控。

总结一下

CPU调优不是一蹴而就的事。你得先理解硬件特性，再结合软件策略，最后通过大量测试来验证。我个人习惯是：先跑一遍基准测试，拿到原始数据；然后逐步调整频率、调度和电压；每改一次，就跑一遍压力测试，确保稳定性。

说白了，调优就是一场“平衡游戏”。你追求性能，就得牺牲功耗；你追求续航，就得降低频率。而我们的价值，就是在这个平衡点上，找到最优解。