一、简介
在现代 Linux 系统中，CPU 主频并非固定不变，内核会根据系统负载、功耗需求动态调整 CPU 运行频率，这套机制被称为CPU 调频（CPU Frequency Scaling），而scaling_governor（调频器）则是整个调频体系的核心决策单元。它相当于 CPU 频率的 “指挥者”，决定了内核在何种负载下升频、降频、维持基准频率，直接影响设备的性能、功耗、发热以及实时性。
从实际落地场景来看，CPU 调频机制几乎覆盖所有运行 Linux 的设备：服务器集群需要稳定高性能，一般选用激进的调频策略；嵌入式工控机、边缘网关、车载终端对功耗和实时性要求严苛，必须搭配专用调频器；个人 PC、笔记本电脑则需要在性能与续航之间做平衡；工业实时 Linux 系统（如 RT-Linux）更是对调频器有着严格选型要求，不合理的调频策略会直接导致任务调度延迟、实时任务超时，引发工业设备故障。
对于 Linux 内核开发、嵌入式开发、运维工程师、实时系统研发人员而言，吃透scaling_governor的原理、选型与切换方法是必备技能。很多线上服务器卡顿、嵌入式设备续航差、实时任务抖动等问题，根源都在于调频器配置不当。掌握这套机制，不仅能完成系统性能调优、功耗管控，还能排查底层调度引发的隐性故障，也是撰写 Linux 内核调优、实时系统、嵌入式开发相关报告、论文的重要实践依据。本文从一线运维与内核开发实战角度出发，结合命令、代码、实操案例，完整讲解主流调频器特性、sysfs 接口操作、场景适配以及踩坑解决方案。
二、核心概念
2.1 CPU 调频基础架构
Linux CPU 调频子系统依托cpufreq内核框架实现，整体分为三层：硬件驱动层、频率调节层、调频策略层。
硬件驱动层：对接 CPU 硬件，读取 CPU 支持的最大 / 最小频率、电压档位，由 CPU 厂商驱动实现。scaling_freq：记录 CPU 当前运行频率、支持的频率列表，通过 sysfs 文件对外暴露。scaling_governor：即本文核心调频器，属于策略层，是内核预设的调频算法，负责根据系统 CPU 负载、定时器事件、调度状态，决策 CPU 最终运行频率。
所有调频相关配置、状态查询，均通过 Linux 标准sysfs 虚拟文件系统完成，sysfs 挂载在/sys目录下，无需额外安装工具，原生 Linux 均支持。
2.2 四大主流调频器详解
Linux 内核默认内置四款使用最广泛的调频器，不同内核版本（3.10~6.x）均兼容，特性差异极大，也是生产环境首选方案：
2.2.1 performance（性能模式）
直译：性能调频器。强制 CPU 运行在硬件支持的最高主频，全程不主动降频。
特性：CPU 频率锁定最大值，响应速度最快，无频率切换延迟；CPU 功耗、发热最高。适用：高性能服务器、实时工业设备、算力节点、对延迟零容忍的场景。
2.2.2 powersave（节能模式）
直译：省电调频器。强制 CPU 运行在硬件支持的最低主频，全程不升频。
特性：CPU 维持最低频率运行，功耗、发热最低；运算性能大幅下降，高负载下卡顿严重。适用：低负载常驻设备、待机网关、纯后台日志采集设备。
2.2.3 ondemand（按需调频）
传统动态调频器，早期 Linux 默认策略，基于轮询采样负载实现调频。
特性：内核定时轮询 CPU 利用率，负载超过阈值则瞬间拉满主频，负载降低后逐步降频；升频快、降频慢，存在明显的轮询延迟。缺陷：频繁轮询会产生额外系统开销，在实时系统中易引发调度抖动，新内核中逐步被替代。适用：老旧 Linux 设备、传统桌面 Linux 系统。
2.2.4 schedutil（调度器感知调频）
现代 Linux 主流默认调频器，依托进程调度事件触发调频，是目前最优的通用方案。
特性：不再定时轮询，而是结合 CFS 调度器、实时调度器的运行状态动态调整频率，调频时机精准、系统开销极小，兼顾性能与功耗。优势：完美适配普通进程、实时进程，延迟远低于 ondemand，主流 CentOS 8+、Ubuntu 18.04+、嵌入式 Linux 均默认使用。适用：绝大多数云服务器、嵌入式设备、笔记本、新型工控机，也是实时 Linux 首选动态调频器。
2.3 关键 sysfs 核心文件说明
所有 CPU 调频配置文件统一存放在/sys/devices/system/cpu/cpuX/cpufreq/目录（cpuX代表 CPU 核心编号，从 0 开始），核心文件释义：
scaling_governor：当前使用的调频器，可读可写，切换调频器的核心文件。scaling_available_governors：系统当前支持的所有调频器列表，只读。cpuinfo_min_freq：CPU 硬件支持的最小频率（单位：KHz），只读。cpuinfo_max_freq：CPU 硬件支持的最大频率（单位：KHz），只读。scaling_cur_freq：CPU 当前实时运行频率（单位：KHz），只读。
三、环境准备
3.1 软硬件环境要求
本文实操兼容主流 Linux 发行版，所有命令、代码跨版本通用，推荐环境如下：
环境类型版本 / 规格说明操作系统CentOS 7/8/9、Ubuntu 18.04/20.04/22.04、Debian 10+、RT-Linux 5.4/5.15内核版本推荐 3.10 及以上，主流内核均内置 cpufreq 框架硬件x86_64 物理机 / 虚拟机、ARM 嵌入式开发板（树莓派、瑞芯微、飞腾）虚拟机需开启 CPU 调频支持，物理机无需额外配置权限root 超级管理员权限修改 sysfs 调频配置必须使用 root，普通用户仅可查询工具系统原生工具：cat、echo、watch、stress、gcc无需额外安装第三方软件，系统自带
3.2 环境检查与基础配置
3.2.1 检查内核是否支持 cpufreq 框架
几乎所有标准 Linux 都默认开启 cpufreq，执行以下命令校验：
# 查看cpu目录下是否存在cpufreq文件夹
ls /sys/devices/system/cpu/cpu0/ | grep cpufreq
作用：判断当前系统是否具备 CPU 调频能力。
输出cpufreq：环境正常，可继续实操；无输出：虚拟机未开启 CPU 调频，需在虚拟化软件中开启 “CPU 性能模式”，物理机出现此问题代表内核裁剪关闭了 cpufreq，需重新编译内核。
3.2.2 安装压力测试工具（用于后续负载测试）
stress工具用于模拟 CPU 高负载，验证调频器效果，CentOS/Ubuntu 安装命令：
# CentOS 系列安装 stress
yum install stress -y
# Ubuntu/Debian 系列安装 stress
apt install stress -y
作用：人为制造 CPU 满负载，观察调频器的升频、降频行为。
3.2.3 安装 gcc 编译器（用于 C 语言代码实操）
后续会提供 C 语言读取 sysfs 调频状态的代码，需 gcc 编译：
# CentOS
yum install gcc -y
# Ubuntu/Debian
apt install gcc -y
四、应用场景
CPU 调频器的选型直接决定系统运行状态，不同业务场景必须匹配对应scaling_governor，三者组合决定系统最终表现。
企业级服务器集群、数据库节点、大数据计算节点，核心诉求是持续高性能、低延迟，统一选用performance模式，避免动态调频带来的频率切换延迟，保障数据库查询、算力任务稳定运行。工业实时 Linux 工控设备、运动控制、数据采集终端，优先选择schedutil或performance，杜绝ondemand轮询造成的调度抖动，保证实时任务按时执行。云主机、办公服务器、嵌入式物联网网关，负载波动大，日常低负载、突发高负载，使用默认schedutil，平衡性能与功耗。笔记本、移动嵌入式设备、电池供电终端，追求续航能力，低负载场景切换为powersave，移动场景大幅降低功耗与发热。运维人员可根据业务时段自动化切换调频器，例如业务高峰期用 performance，深夜低负载切换 powersave，实现性能与功耗的动态平衡。
五、实际案例与操作步骤
本章节分为命令行实操（主流运维方式）、Shell 脚本批量配置、**C 语言代码读取 / 修改调频器（开发级实操）** 三大部分，所有代码可直接复制运行，每一步附带详细注释与使用场景。
前置说明：所有操作建议切换至 root 用户，执行 su - root 或 sudo -i 提升权限。
5.1 基础查询：查看 CPU 调频相关信息
步骤 1：查看系统支持的所有调频器
# 查看CPU0支持的调频器，所有核心支持列表一致
cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_available_governors
作用：确认当前内核内置了哪些调频器，避免选择系统不支持的策略。 示例输出：performance powersave ondemand schedutil，代表四大调频器均可用。
步骤 2：查看当前正在使用的调频器
# 查询CPU0当前调频器，单CPU设备查看此文件即可
cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
作用：日常运维排查首选命令，快速定位当前调频策略。
步骤 3：查看 CPU 频率上下限与当前实时频率
# 1. CPU最小支持频率
cat /sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_min_freq
# 2. CPU最大支持频率
cat /sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_max_freq
# 3. CPU当前运行实时频率
cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq
作用：了解 CPU 硬件频率范围，对比调频器生效后的频率变化，单位均为 KHz。
步骤 4：实时监控 CPU 频率变化
# 每1秒刷新一次，实时查看当前CPU频率
watch -n1 cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq
作用：动态观测调频器升频、降频过程，测试动态调频器效果必备命令。
5.2 单 CPU 核心：手动切换调频器（临时生效）
通过echo写入 sysfs 文件实现切换，临时生效，系统重启后恢复默认配置，适合临时调优、故障排查。
案例 1：切换为 performance 性能模式
# 将CPU0调频器设置为 performance
echo performance > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
# 验证是否切换成功
cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
使用场景：临时压测、数据库高峰、实时任务调试。
案例 2：切换为 powersave 节能模式
echo powersave > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
使用场景：设备待机、低负载挂机、电池设备省电。
案例 3：切换为 ondemand 传统动态模式
echo ondemand > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
使用场景：兼容老旧设备，测试传统调频逻辑。
案例 4：切换为 schedutil 调度感知模式
echo schedutil > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
使用场景：生产环境默认配置，通用服务器、嵌入式设备日常使用。
5.3 批量操作：所有 CPU 核心统一切换调频器
服务器、多核嵌入式设备拥有多个 CPU 核心（cpu0~cpuN），逐个切换效率极低，使用 Shell 循环批量配置。
5.3.1 脚本 1：批量查询所有核心当前调频器
#!/bin/bash
# 功能：遍历所有CPU核心，输出每个核心的调频器
for cpu in /sys/devices/system/cpu/cpu[0-9]*
do
gov=$(cat ${cpu}/cpufreq/scaling_governor)
echo "CPU核心 ${cpu##*/} 当前调频器：$gov"
done
使用方法：
复制代码保存为 check_gov.sh；赋予执行权限：chmod +x check_gov.sh；运行脚本：./check_gov.sh。 作用：快速检查多核设备调频器是否统一，排查部分核心配置不一致问题。
5.3.2 脚本 2：批量将所有 CPU 切换为指定调频器
#!/bin/bash
# 功能：批量设置所有CPU核心为指定调频器，参数传入调频器名称
# 用法：./set_all_gov.sh schedutil
TARGET_GOV=$1
# 判断是否传入参数
if [ -z $TARGET_GOV ];then
echo "用法: $0 调频器名称 (performance/powersave/ondemand/schedutil)"
exit 1
fi
# 遍历所有CPU核心进行配置
for cpu in /sys/devices/system/cpu/cpu[0-9]*
do
echo $TARGET_GOV > ${cpu}/cpufreq/scaling_governor
echo "已将 ${cpu##*/} 设置为 $TARGET_GOV"
done
# 二次校验配置结果
echo -e "\n===== 配置结果校验 ====="
for cpu in /sys/devices/system/cpu/cpu[0-9]*
do
gov=$(cat ${cpu}/cpufreq/scaling_governor)
echo "${cpu##*/} : $gov"
done
使用场景：生产环境批量调优、服务器统一配置，支持一键切换全核心策略。
5.4 负载压力测试：验证调频器工作逻辑
结合stress工具模拟 CPU 满负载，配合watch监控频率，直观区分不同调频器行为。
步骤 1：后台运行压力测试（占满所有 CPU 核心）
# 后台运行，4线程压测CPU，持续运行
stress -c 4 &
步骤 2：开启频率实时监控
watch -n1 cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq
现象说明
performance：频率始终等于cpuinfo_max_freq，全程无变化；powersave：频率始终等于cpuinfo_min_freq，高负载也不升频；ondemand/schedutil：负载升高瞬间升频至最大值，停止 stress 后逐步降频。
步骤 3：停止压力测试
# 结束所有stress进程
pkill stress
5.5 C 语言代码：读写 sysfs 调频配置（开发级实践）
内核开发、嵌入式应用开发中，常需要在程序内动态读取、切换调频器，下面提供可直接编译运行的 C 语言代码，基于 Linux sysfs 文件读写实现。
5.5.1 代码 1：读取当前 CPU 调频器与频率信息
#include
#include
#include
#define GOV_PATH "/sys/devices/system/cpu/cpu0/cpufreq/scaling_governor"
#define CUR_FREQ_PATH "/sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq"
#define BUF_LEN 64
// 读取sysfs文件内容函数
int read_sysfs_file(const char *path, char *buf, int len)
{
FILE *fp = fopen(path, "r");
if(NULL == fp)
{
perror("fopen failed");
return -1;
}
fgets(buf, len, fp);
// 去除换行符
buf[strcspn(buf, "\n")] = '\0';
fclose(fp);
return 0;
}
int main()
{
char gov_buf[BUF_LEN] = {0};
char freq_buf[BUF_LEN] = {0};
// 读取当前调频器
if(0 != read_sysfs_file(GOV_PATH, gov_buf, BUF_LEN))
{
return -1;
}
printf("当前CPU0调频器：%s\n", gov_buf);
// 读取当前运行频率
if(0 != read_sysfs_file(CUR_FREQ_PATH, freq_buf, BUF_LEN))
{
return -1;
}
printf("当前CPU0运行频率：%s KHz\n", freq_buf);
return 0;
}
编译与运行命令：
# 编译代码，生成可执行文件 cpufreq_read
gcc cpufreq_read.c -o cpufreq_read
# 运行程序
./cpufreq_read
作用：应用程序中获取 CPU 调频状态，用于业务逻辑判断、日志上报。
5.5.2 代码 2：C 语言动态切换调频器
#include
#include
#include
#define GOV_PATH "/sys/devices/system/cpu/cpu0/cpufreq/scaling_governor"
// 写入sysfs文件，切换调频器
int set_governor(const char *gov_name)
{
FILE *fp = fopen(GOV_PATH, "w");
if(NULL == fp)
{
perror("fopen failed");
return -1;
}
fputs(gov_name, fp);
fclose(fp);
printf("成功切换调频器为：%s\n", gov_name);
return 0;
}
int main(int argc, char *argv[])
{
// 校验入参
if(argc != 2)
{
printf("用法：%s 调频器名称\n", argv[0]);
printf("可选：performance / powersave / ondemand / schedutil\n");
return -1;
}
if(0 != set_governor(argv[1]))
{
return -1;
}
return 0;
}
编译与运行命令：
# 编译
gcc cpufreq_set.c -o cpufreq_set
# 切换为performance模式
./cpufreq_set performance
使用场景：嵌入式程序、后台服务根据业务负载自动切换 CPU 调频策略。
六、常见问题与解答
结合多年一线运维、嵌入式调优经验，整理实操中最高频的问题，全部对应上文操作步骤。
问题 1：普通用户执行 echo 切换调频器提示权限拒绝
现象：Permission denied 原因：sysfs 下 cpufreq 目录属于内核管控文件，仅 root 用户拥有读写权限。 解决方案：使用sudo或切换至 root 用户执行命令、脚本、程序。
问题 2：写入不存在的调频器，命令无报错但配置不生效
现象：执行echo test > scaling_governor无报错，查询后调频器未变化。 原因：内核会自动过滤不支持的调频器名称，非法写入直接丢弃。 解决方案：先执行cat scaling_available_governors查看系统支持列表，仅使用列表内的名称。
问题 3：切换为 powersave 后，CPU 高负载依然卡顿严重
原因：powersave 强制锁定最低频率，硬件性能被限制。 解决方案：高负载业务禁止使用 powersave，切换为schedutil或performance。
问题 4：虚拟机中 scaling_cur_freq 数值固定，切换调频器无变化
原因：虚拟化软件默认屏蔽 CPU 调频功能，虚拟机无法控制物理 CPU 频率。 解决方案：VMware/KVM 开启 “允许 CPU 频率调节”，物理机环境无此问题。
问题 5：多核 CPU 部分核心调频器不一致，业务出现性能抖动
原因：手动逐个切换时遗漏部分 CPU 核心。 解决方案：使用上文批量 Shell 脚本一键配置所有核心，保证全核心策略统一。
问题 6：C 语言程序运行提示 fopen failed
原因：程序未以 root 权限运行，无法读写 sysfs 文件。 解决方案：执行 sudo ./cpufreq_set 运行可执行文件。
七、实践建议与最佳实践
结合服务器、嵌入式、实时 Linux 三大场景，总结工程化落地的最佳实践、调试技巧与优化方案，适合生产环境长期使用。
7.1 调频器选型最佳实践
实时 Linux / 工业工控设备：优先 performance，其次 schedutil。坚决禁用ondemand，轮询机制会引入调度延迟，破坏实时性。数据库、Redis、消息队列等核心中间件：固定为performance，消除频率切换延迟，保证 IO 与运算稳定。通用云服务器、Web 服务器：使用系统默认schedutil，兼顾性能与功耗，无需额外修改。电池供电嵌入式终端、物联网低功耗设备：闲时使用powersave，业务触发时通过脚本 / 程序自动切换为schedutil。老旧 Linux 系统（内核 3.10 及以下）：无schedutil，使用ondemand作为动态调频方案。
7.2 持久化配置（重启不失效）
上文echo方式为临时配置，系统重启恢复默认，生产环境需要永久配置：
CentOS/RHEL 系列：安装cpufrequtils工具，编辑配置文件设置默认调频器。Ubuntu/Debian 系列：修改/etc/default/cpufrequtils配置GOVERNOR参数。嵌入式 Linux / 定制内核：将调频切换脚本加入开机自启（rc.local、systemd 服务）。
7.3 调试与排障技巧
排查性能抖动问题时，第一步优先检查scaling_governor，很多隐性延迟由动态调频引发。功耗异常升高时，检查是否误设为performance，低负载设备切换为schedutil或powersave。压力测试必须配合watch监控频率，验证调频器是否按预期工作。编写自动化运维脚本时，优先使用 Shell 批量操作，简单高效；业务程序动态控制优先使用 C 语言读写 sysfs。
7.4 性能优化细节
全 CPU 核心必须保持调频器一致，混合策略会导致多核调度失衡。高并发场景关闭动态调频，锁定最高频率，微小的频率切换延迟会被并发放大。边缘计算设备可做定时策略：白天业务高峰用 performance，夜间低负载切换 powersave。
八、总结与场景复盘
本文从 Linux 内核 cpufreq 框架出发，完整讲解了scaling_governor四大主流调频器performance、powersave、ondemand、schedutil的核心特性、区别与适配逻辑，同时落地了命令行操作、Shell 批量脚本、C 语言开发调用三类实战方案，覆盖运维调优、嵌入式开发、内核调试全场景。
CPU 调频器看似是底层小配置，却深刻影响整个 Linux 系统的性能、功耗、实时性与稳定性。在传统 Linux 服务器、云原生集群、ARM 嵌入式设备、工业实时 Linux 系统中，调频器选型都是系统调优的基础环节。很多运维人员、开发人员容易忽略该模块，最终引发卡顿、延迟、续航差等问题。
从工程落地角度来说，临时调试使用echo命令快速切换；批量运维依赖 Shell 脚本统一配置；业务程序动态控制则基于 sysfs 文件读写开发代码。结合业务负载选择匹配的调频策略，是每一位 Linux 工程师必备的基础能力。
建议读者结合自身设备反复复现本文案例，观察不同调频器在空载、满载、波动负载下的表现，将理论知识转化为实战经验。在后续 Linux 性能调优、实时系统开发、嵌入式项目开发、技术报告与论文撰写中，可基于本文的实操流程、现象、数据进行分析与论证，真正做到学以致用。