第2章 Linux CPUFreq框架

第2章：Linux CPUFreq框架：CPUFreq子系统架构、核心组件与用户空间接口

各位好，欢迎来到第二章。上一章我们聊了为什么要调频，以及功耗和性能这对「冤家」怎么平衡。这一章，咱们直接深入Linux内核，看看CPUFreq这个子系统到底是怎么工作的。

说实话，我第一次接触CPUFreq框架时，也被它那一堆术语搞晕过。什么policy、governor、driver，听着就头大。但后来我发现，只要理解了它的设计思路，其实很简单——它就是一个「中间人」，负责协调硬件、内核策略和用户需求。

2.1 CPUFreq子系统架构概览

CPUFreq子系统的架构，说白了就是三层：

最底层：硬件相关的驱动层（driver），直接操作CPU的P-state或频率寄存器。
中间层：核心框架层，负责管理策略（policy）和调频决策。
最上层：用户空间接口（sysfs），让你能通过文件系统直接干预调频行为。

嗯，这里要注意：这三层是解耦的。驱动只管「怎么调」，策略管「调多少」，而用户空间管「我想怎么调」。这种分层设计，让Linux能支持从ARM手机到x86服务器的各种硬件。

核心思想：CPUFreq不直接操作硬件寄存器，而是通过抽象层屏蔽硬件差异。你换了个CPU，只要换驱动就行，上层代码不用动。

2.2 核心组件详解

2.2.1 policy（策略对象）

Policy是CPUFreq的核心数据结构。它代表一组CPU（通常是同属一个簇的核）的调频策略。每个policy包含：

affected_cpus：受该策略影响的CPU列表。
min/max：频率的上下限。
governor：当前使用的调频算法。
cur：当前频率。

我遇到过一个问题：在某个ARM平台上，大小核架构的CPU，大核和小核不能共用一个policy。因为它们频率范围不同，调频行为也不同。如果你强行绑定，系统会直接崩溃。所以，policy的设计天然支持异构多核。

2.2.2 governor（调频算法）

Governor是CPUFreq的「大脑」。它决定什么时候升频、什么时候降频。Linux内核内置了多种governor：

Governor名称	行为特点	适用场景
performance	一直跑最高频	性能敏感、不在乎功耗
powersave	一直跑最低频	省电模式、后台任务
ondemand	按需调频，负载高就升频	通用场景，响应较快
conservative	类似ondemand，但升降频更平滑	对频率抖动敏感的场景
schedutil	基于调度器负载信息调频	现代内核推荐，延迟低
userspace	完全由用户手动设置频率	调试、固定频率场景

我个人习惯，在服务器上首选schedutil。为什么？因为它能利用调度器已经算好的负载信息，不需要额外采样，延迟更低。我曾经在数据库服务器上做过对比，schedutil比ondemand的尾延迟降低了约15%。

避坑指南：我曾经在生产环境上用过conservative，结果发现它升降频太慢，导致突发流量时CPU跟不上。后来换回ondemand才解决。所以，conservative更适合功耗敏感、负载平稳的设备。

2.2.3 driver（硬件驱动）

Driver是CPUFreq的「手脚」。它知道怎么操作具体的硬件寄存器。常见的驱动有：

acpi-cpufreq：x86平台，通过ACPI的P-state接口调频。
intel_pstate：Intel Sandy Bridge及以后，直接操作MSR寄存器。
cpufreq-dt：ARM平台，通过设备树配置频率表。
qcom-cpufreq-hw：高通平台，通过硬件寄存器直接调频。

你想想看，如果没有driver这一层，内核就得为每种CPU写一套调频逻辑，那代码得多臃肿？

2.3 用户空间接口（sysfs）

好了，理论说完了，咱们来点实际的。CPUFreq通过sysfs暴露了丰富的接口，路径在/sys/devices/system/cpu/cpuX/cpufreq/。这里X是CPU编号。

常用的文件有：

scaling_available_governors：列出当前支持的governor。
scaling_governor：读取或设置当前governor。
scaling_min_freq / scaling_max_freq：频率上下限（单位kHz）。
scaling_cur_freq：当前频率。
cpuinfo_min_freq / cpuinfo_max_freq：硬件支持的频率范围。
affected_cpus：受该policy影响的CPU列表。
related_cpus：硬件上相关的CPU（比如共享电压域的）。

举个例子，你想把CPU0的governor改成performance：

# 查看当前governor
cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor

# 设置成performance
echo performance > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor

# 验证
cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor

嗯，这里要注意：有些系统会限制你修改governor，比如Android的某些版本。如果你遇到Permission denied，检查一下是不是有安全策略在作怪。

警告：不要随意修改scaling_min_freq和scaling_max_freq。我曾经在调试时把最小值设得比最大值还高，结果系统直接卡死。内核虽然会做校验，但某些驱动可能不完善。

另外，还有一个全局接口/sys/devices/system/cpu/cpufreq/，里面包含所有policy的公共信息。比如policyX目录，对应每个policy。

2.4 实战：如何查看当前调频状态

我一般用这个脚本来快速查看所有CPU的调频状态：

#!/bin/bash
for cpu in /sys/devices/system/cpu/cpu[0-9]*; do
    cpu_num=$(basename $cpu)
    gov=$(cat $cpu/cpufreq/scaling_governor 2>/dev/null)
    cur=$(cat $cpu/cpufreq/scaling_cur_freq 2>/dev/null)
    min=$(cat $cpu/cpufreq/scaling_min_freq 2>/dev/null)
    max=$(cat $cpu/cpufreq/scaling_max_freq 2>/dev/null)
    echo "$cpu_num: gov=$gov cur=$cur min=$min max=$max"
done

这个脚本会遍历所有CPU，打印出它们的governor和频率范围。我在排查性能问题时，第一件事就是跑这个脚本，看看是不是有CPU被意外限制在了低频。

2.5 小结

这一章我们拆解了CPUFreq的三大组件：policy管策略、governor管算法、driver管硬件。用户空间通过sysfs可以灵活干预。说白了，CPUFreq就是一个「策略+执行」的框架，你只要理解了这三层，就能玩转它。

下一章，我们会深入每个governor的实现细节，看看它们到底是怎么算负载、怎么决策的。到时候我会分享一些我在嵌入式项目中的调优案例，保证干货满满。

好，今天就到这里。有问题欢迎留言讨论。

📚 课程目录