一、简介

1.1 背景与技术演进

现代处理器普遍支持 动态调频调压（DVFS） 技术，也就是常说的 CPU 频率缩放。CPU 运行在更高频率时，运算能力更强，但功耗、发热也会同步上升；降低频率则能有效省电、控温，代价是计算性能下降。在服务器、嵌入式设备、工控实时系统、移动端设备中，性能与功耗的平衡一直是系统调优的核心目标。

Linux 内核通过 CPUFreq 子系统统一管理 CPU 调频逻辑，而调频器（Governor） 是 CPUFreq 的核心算法模块，负责采集系统负载、决策目标频率。在 Linux 4.7 版本之前，业界主流使用 ondemand、performance、powersave 等传统调频器，其中 ondemand 应用最广。

ondemand 的设计逻辑较为简单：周期性采样 CPU 整体空闲率，当负载超过预设阈值时直接拉满主频，负载回落则逐步降频。这种全局采样的方式存在明显短板：无法区分短时突发负载和持续业务负载，对实时任务、延迟敏感型业务极不友好，频繁的频率跳变还会引入调度抖动、增大延迟。

为解决传统调频器的缺陷，Linux 内核推出了 Schedutil 调频器。它彻底改变了负载采集方式，直接复用 Linux 调度器原生的 util 负载统计数据，让调频逻辑与任务调度深度联动，做到 “调度感知调频”。相比 ondemand，Schedutil 负载判定更细粒度、频率切换更平滑、对实时任务更友好，目前已是桌面、服务器、嵌入式实时 Linux 系统的默认调频方案。

1.2 应用场景与学习价值

Schedutil 并非单纯的 “省电工具”，它深度绑定调度子系统，应用场景覆盖全领域 Linux 设备：

1. 工业工控 / 实时 Linux：运动控制、数据采集、工业网关等低延迟场景，需要频率随任务负载精准变化，避免调频抖动干扰实时性；
2. 嵌入式 Linux 设备：车载终端、物联网网关、边缘计算节点，兼顾续航与业务性能；
3. 云服务器 / 容器集群：大量短时突发容器任务，平滑调频可降低整机功耗、减少散热压力；
4. 桌面 / 笔记本系统：日常办公、影音、轻度开发场景，平衡体验与电池续航。

对于开发者、运维人员、内核研究者而言，掌握 Schedutil 有多重价值：首先能理解 Linux 调度子系统与 CPUFreq 子系统的跨模块协作逻辑，打通内核两大核心模块；其次可以完成工控、实时系统、嵌入式设备的功耗 + 性能调优；同时该模块代码精简、逻辑清晰，是学习内核回调、工作队列、调度统计、sysfs 接口的经典案例，可直接用于技术报告、毕业论文、内核源码研读。

本文从原理、环境、实操、源码、排错、最佳实践全维度讲解，全程配套可复现命令与内核代码片段，兼顾新手入门与深度调研需求。

---

二、核心概念与基础术语

本节梳理 Schedutil 依赖的内核基础概念、CPUFreq 架构、负载统计规则，是后续实操与源码分析的前置知识。

2.1 CPUFreq 子系统整体架构

Linux CPU 调频体系分为三层，自顶向下依次为：

1. 用户层接口：基于 sysfs 文件系统，位于 /sys/devices/system/cpu/cpufreq/，用户可通过读写文件修改调频策略、查看频率信息；
2. CPUFreq 核心层：提供通用数据结构、策略管理、回调注册、硬件接口封装，定义 struct cpufreq_policy 调频策略对象；
3. 调频器（Governor）+ 底层驱动：
   • 调频器：实现负载计算、频率决策算法（本文主角 Schedutil、传统 ondemand 都属于这一层）；
   • 硬件驱动：对接 CPU 平台（x86/ARM）、BIOS/ACPI，真正执行硬件频率切换，如 acpi-cpufreq、intel_pstate。

核心对象：cpufreq_policy 内核中每一组共享调频硬件的 CPU 核心，对应一个 cpufreq_policy 策略实例，多个逻辑 CPU 可以绑定同一个 policy。所有频率上下限、可用频点、当前调频器、关联 CPU 列表，都由该对象统一管理。

2.2 调度器 util 负载统计

这是 Schedutil 和传统调频器最本质的区别：

• ondemand：通过定时器周期性读取 /proc/stat 全局 CPU 空闲时间，属于事后全局采样；
• Schedutil：直接读取调度器维护的 cpu_util 利用率数值，属于调度事件触发的细粒度统计。

Linux CFS 调度器会为每个 CPU 维护 util 负载值，统计当前 CPU 上可运行任务的加权负载，任务入队、出队、调度切换时都会实时更新。该数值范围为 0 ~ SCHED_CAPACITY_SCALE（内核默认 1024）：

• util = 0：CPU 完全空闲；
• util = 1024：CPU 满载运行。

Schedutil 不再额外做负载采样，直接使用调度器输出的 util 值计算目标频率，天然和任务调度同步，延迟远低于传统方案。

2.3 Schedutil 核心工作机制

1. 触发时机：调度器每次更新 cpu_util 时，触发 Schedutil 注册的回调函数；
2. 频率计算：根据 util / 1024 的比例，线性计算目标频率，负载低则降频、负载上升则平滑升频；
3. 执行方式：区分立即执行和延迟执行，高频切换场景使用工作队列异步执行，避免占用调度上下文；
4. 平滑策略：内置升频、降频延迟阈值，防止短时脉冲负载导致频率反复跳变（抖频）。

2.4 关键术语汇总

术语	说明
DVFS	动态调频调压，CPU 动态切换运行频率与电压
Governor	调频器，CPUFreq 的频率决策算法模块
cpufreq_policy	调频策略，管理一组 CPU 的频率范围、调频器、硬件信息
cpu_util	调度器维护的 CPU 负载值，取值 0~1024
sysfs	内核导出的虚拟文件系统，用户空间控制 CPUFreq 的主要接口
抖频	CPU 频率在高低频之间频繁切换，会增加延迟、功耗

---

三、环境准备

3.1 软硬件环境要求

本文所有命令、代码、源码分析基于主流 Linux 发行版，推荐两套环境，读者任选其一即可：

环境 1：x86_64 服务器 / 虚拟机（推荐调试、源码阅读）

• 操作系统：Ubuntu 18.04 / 20.04 / 22.04、CentOS 7 / 8 / 9
• 内核版本：Linux 4.7 及以上（Schedutil 正式合入主线内核版本），建议 5.4 / 5.10 / 5.15 长期支持版
• 硬件：支持 DVFS 的 x86 CPU（Intel / AMD 主流处理器均可）
• 工具依赖：gcc、make、linux-headers、cpufrequtils、stress、trace-cmd、git、内核源码包

环境 2：ARM 嵌入式 Linux（嵌入式场景复现）

• 系统：树莓派官方系统、OpenWrt、Yocto 定制系统
• 内核版本：4.9+ 嵌入式 Linux 内核（主流嵌入式平台均已适配 Schedutil）
• 硬件：树莓派、瑞芯微、全志等主流 ARM 开发板

3.2 环境安装与配置步骤

3.2.1 检查内核版本与默认调频器

执行以下基础命令，确认环境基础状态，所有命令可直接复制运行：

# 1. 查看 Linux 内核版本，确认 >=4.7
uname -r

# 2. 查看当前系统支持的所有调频器
cat /sys/devices/system/cpu/cpufreq/policy0/scaling_available_governors

# 3. 查看当前正在使用的调频器
cat /sys/devices/system/cpu/cpufreq/policy0/scaling_governor

# 4. 查看 CPU 支持的最高/最低频率（单位：KHz）
cat /sys/devices/system/cpu/cpufreq/policy0/cpuinfo_min_freq
cat /sys/devices/system/cpu/cpufreq/policy0/cpuinfo_max_freq

# 5. 查看当前 CPU 实际运行频率
cat /sys/devices/system/cpu/cpufreq/policy0/scaling_cur_freq

输出说明：如果 scaling_available_governors 中包含 schedutil，说明内核已开启该模块；若不存在，需要重新编译内核开启对应配置项。

3.2.2 安装调试与压测工具

以 Ubuntu/Debian 系列为例，安装压测、查看、调试工具：

# 更新软件源
sudo apt update

# 安装 cpufreq 工具集、压力测试工具、内核调试工具
sudo apt install -y cpufrequtils stress trace-cmd linux-tools-common linux-tools-$(uname -r)

CentOS/RHEL 系列安装命令：

sudo yum install -y cpufrequtils stress trace-cmd

3.2.3 内核配置检查（源码编译场景）

若自定义内核，必须开启以下核心配置（make menuconfig 配置界面），这是 Schedutil 正常工作的前提：

# 开启 CPU 频率缩放核心子系统
CONFIG_CPU_FREQ=y

# 开启 Schedutil 调频器（必选）
CONFIG_CPU_FREQ_GOV_SCHEDUTIL=y

# 可选：传统 ondemand 调频器（用于对比测试）
CONFIG_CPU_FREQ_GOV_ONDEMAND=y

# 开启调度器负载统计（Schedutil 依赖的核心功能）
CONFIG_SCHED_CPUUTIL=y

# 开启 sysfs 接口（用户层控制必备）
CONFIG_SYSFS=y

说明：主流发行版默认已开启以上配置，仅定制嵌入式内核、裁剪内核时需要手动检查。

3.2.4 临时关闭节能防护（测试专用）

部分桌面系统、服务器会自带功耗守护进程，干扰调频测试，临时关闭：

# Ubuntu 桌面版关闭电源管理守护（测试用，重启失效）
sudo systemctl stop powerd
sudo systemctl stop thermald

---

四、典型应用场景（300 字）

Schedutil 最核心的落地场景为低延迟实时工控系统与高密度云容器集群。在工业工控领域，PLC 数据采集、伺服电机控制等实时任务对调度延迟要求严苛，传统 ondemand 基于全局定时采样，突发任务易触发频率骤升，带来调度抖动；而 Schedutil 依托调度器实时 util 数据，任务入队瞬间即可平滑调整频率，保证实时任务延迟稳定。在云服务器场景，大量容器、微服务存在短时突发负载，Schedutil 细粒度负载统计可避免全量 CPU 拉满主频，在不影响业务响应速度的前提下降低整机功耗与机房散热压力。此外，车载嵌入式终端、物联网边缘网关等设备，需要兼顾续航与业务实时性，Schedutil 平滑调频的特性也成为这类设备的首选调频方案。

---

五、实际案例与完整操作步骤（含代码 + 注释）

本章分为用户空间实操、内核态源码解析、自定义测试程序三大部分，从上层使用到底层原理逐层拆解，所有代码、命令均可直接复制运行。

5.1 案例一：调频器切换与基础频率观测（用户层实操）

本案例目标：在 ondemand 和 schedutil 之间切换，对比两种调频器在压力负载下的频率变化差异。

步骤 1：查看所有 CPU 对应的 cpufreq policy

# 遍历所有 cpu，查看绑定的 policy
ls /sys/devices/system/cpu/cpu*/cpufreq/

输出可以看到，多核 CPU 通常多个 cpuX 指向同一个 policy0，即共享一套调频策略。

步骤 2：切换调频器为 ondemand（对照组）

# 将 policy0 切换为 ondemand 调频器（所有关联 CPU 同步生效）
sudo sh -c "echo ondemand > /sys/devices/system/cpu/cpufreq/policy0/scaling_governor"

# 验证切换结果
cat /sys/devices/system/cpu/cpufreq/policy0/scaling_governor

作用：切换为传统调频器，作为后续对比基准。

步骤 3：使用 stress 工具压测 CPU，观测频率变化

# 后台运行 4 线程 CPU 压力测试（根据你的 CPU 核心数调整线程数）
stress -c 4 &

# 循环打印当前 CPU 频率，每 0.5 秒刷新一次，持续观测
while true; do cat /sys/devices/system/cpu/cpufreq/policy0/scaling_cur_freq; sleep 0.5; done

现象记录：ondemand 模式下，负载一旦超过阈值，频率会瞬间拉满；压力停止后，频率缓慢下降。

步骤 4：停止压测，切换为 schedutil（实验组）

# 终止 stress 压力进程
pkill stress

# 切换为 schedutil 调频器
sudo sh -c "echo schedutil > /sys/devices/system/cpu/cpufreq/policy0/scaling_governor"

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

步骤 5：再次压测，对比频率变化

重复步骤 3 的压测与观测命令：

stress -c 4 &
while true; do cat /sys/devices/system/cpu/cpufreq/policy0/scaling_cur_freq; sleep 0.5; done

核心差异：Schedutil 模式下，CPU 频率线性逐步上升，而非跳变；停止压测后，频率平滑回落，无剧烈抖动。

步骤 6：清理测试进程

pkill stress

5.2 案例二：读写 Schedutil 专属调优参数（sysfs 接口）

Schedutil 在 sysfs 中暴露了专属调优文件，用于控制升频、降频延迟，解决抖频问题。文件路径：/sys/devices/system/cpu/cpufreq/policy0/

5.2.1 查看原生参数

# 查看 schedutil 升频延迟（单位：us）
cat /sys/devices/system/cpu/cpufreq/policy0/schedutil/rate_limit_us

# 部分内核版本区分升频/降频延迟，分别查看
ls /sys/devices/system/cpu/cpufreq/policy0/schedutil/

• rate_limit_us：两次频率切换的最小间隔，数值越大，频率切换越保守，越不容易抖频，但响应变慢。

5.2.2 修改参数（实时系统调优）

实时场景需要降低延迟，缩小间隔；低功耗场景增大间隔：

# 示例1：实时场景，缩短切换间隔（提升响应速度）
sudo sh -c "echo 1000 > /sys/devices/system/cpu/cpufreq/policy0/schedutil/rate_limit_us"

# 示例2：低功耗场景，加大间隔（减少调频次数，省电）
sudo sh -c "echo 10000 > /sys/devices/system/cpu/cpufreq/policy0/schedutil/rate_limit_us"

注意：该修改为临时生效，系统重启后恢复默认值。

5.3 案例三：内核源码解析（Schedutil 核心逻辑，附代码片段）

基于 Linux 5.10 长期支持内核，解析 Schedutil 核心源码文件 drivers/cpufreq/cpufreq_schedutil.c，本节代码为内核原生代码，附带详细注释，可用于论文、报告源码分析部分。

5.3.1 核心数据结构：sugov_policy

每个 cpufreq_policy 对应一个 sugov_policy 结构体，存储 Schedutil 运行状态：

// 摘自 linux 5.10 drivers/cpufreq/cpufreq_schedutil.c
struct sugov_policy {
    struct cpufreq_policy *policy;      // 绑定的调频策略对象
    struct kthread_work work;           // 工作队列，异步执行频率切换
    unsigned int next_freq;             // 计算得出的下一个目标频率
    u64 last_freq_time;                // 上一次调频时间，用于限流
    bool need_update;                   // 是否需要更新频率
};

作用：保存调频状态、工作队列、时间戳，实现异步调频与频率切换限流。

5.3.2 核心回调函数：sugov_util_update

调度器更新 cpu_util 负载后，会调用该回调函数，是 Schedutil 的入口：

// 调度器 util 数据更新时触发的回调函数
static void sugov_util_update(struct sugov_policy *sg_policy)
{
    unsigned int util;
    unsigned int max_cap = sg_policy->policy->max;

    // 1. 获取调度器统计的 CPU 负载 util (0 ~ 1024)
    util = sched_cpu_util(sg_policy->policy->cpu);

    // 2. 根据负载比例线性计算目标频率
    sg_policy->next_freq = DIV_ROUND_UP(util * max_cap, SCHED_CAPACITY_SCALE);

    // 3. 标记需要更新频率，唤醒工作队列执行硬件调频
    if (!sg_policy->need_update) {
        sg_policy->need_update = true;
        kthread_queue_work(&sg_policy->work);
    }
}

代码解读：

1. sched_cpu_util()：读取调度器维护的负载值，这是和 ondemand 最核心的区别；
2. 线性公式计算频率：目标频率 = (util / 1024) * 最大频率，保证平滑升降；
3. 通过内核工作队列异步执行调频，避免在调度上下文执行耗时硬件操作。

5.3.3 频率限流逻辑（防抖频核心）

// 工作队列处理函数，真正执行频率切换
static void sugov_work(struct kthread_work *work)
{
    struct sugov_policy *sg_policy = container_of(work, struct sugov_policy, work);
    u64 now = ktime_get_ns();
    u64 delta;

    // 计算距离上一次调频的时间差
    delta = now - sg_policy->last_freq_time;

    // 限流判断：小于 rate_limit_us 则跳过本次调频，防止频繁切换
    if (delta < sg_policy->rate_limit_us * NSEC_PER_USEC)
        goto out;

    // 调用 CPUFreq 核心接口，设置硬件频率
    __cpufreq_driver_target(sg_policy->policy, sg_policy->next_freq, CPUFREQ_RELATION_L);

    // 更新最后调频时间戳
    sg_policy->last_freq_time = now;
out:
    sg_policy->need_update = false;
}

该段代码实现了 rate_limit_us 参数的限流逻辑，也是 Schedutil 抗抖频的关键。

5.4 案例四：用户态 C 程序观测 CPU 负载与频率联动

编写一个简单的 CPU 密集型测试程序，配合命令观测 util 负载与频率变化，代码可直接编译运行。

5.4.1 测试代码 cpu_load.c

#include <stdio.h>
#include <unistd.h>

// 简单 CPU 密集型循环，模拟业务负载
void cpu_busy_loop(void)
{
    unsigned long i;
    while(1) {
        for(i = 0; i < 100000000; i++) {
            // 空循环，占用 CPU 算力
        }
    }
}

int main(void)
{
    printf("CPU 压力程序开始运行...\n");
    cpu_busy_loop();
    return 0;
}

5.4.2 编译与运行

# 编译代码
gcc cpu_load.c -o cpu_load

# 后台运行程序
./cpu_load &

# 并行观测频率变化
while true; do cat /sys/devices/system/cpu/cpufreq/policy0/scaling_cur_freq; sleep 0.5; done

5.4.3 结束测试

pkill cpu_load

---

六、常见问题与解答

结合实操过程中高频报错、异常现象，逐一解答，全部对应上文操作步骤。

Q1：修改 scaling_governor 时报错 Permission denied

现象：echo schedutil > xxx 提示权限不足。 原因：sysfs 下 cpufreq 接口属于内核高权限文件，普通用户无写入权限。 解决：必须使用 sudo sh -c "echo xxx > 文件路径" 格式，不能单独使用 sudo echo。

Q2：scaling_available_governors 中没有 schedutil

现象：无法切换到 schedutil，内核未识别该调频器。 原因：内核未开启 CONFIG_CPU_FREQ_GOV_SCHEDUTIL 配置项，或内核版本低于 4.7。 解决：升级内核至 4.7+，重新编译内核并开启对应配置。

Q3：切换为 schedutil 后，频率始终固定在最低频，无法升频

原因 1：压测工具未真正占用对应 CPU 核心； 原因 2：BIOS / 主板开启了省电强制限制（bios_limit 字段限制最高频率）； 解决：1. 调整 stress 线程数匹配 CPU 核心；2. 进入 BIOS 关闭 EIST 节能强制限制。

Q4：修改 rate_limit_us 后文件不存在

现象：找不到 /sys/devices/system/cpu/cpufreq/policy0/schedutil/ 目录。 原因：内核版本过低，早期 schedutil 未暴露独立调优接口。 解决：升级内核至 5.0 以上版本。

Q5：压力停止后，CPU 频率长时间不下降

原因：rate_limit_us 设置过大，调频限流间隔太长。 解决：临时调小 rate_limit_us，平衡响应速度与抖频风险。

Q6：ARM 嵌入式设备上 schedutil 完全不生效

原因：底层硬件驱动（cpufreq-dt）未正常加载，DVFS 驱动适配异常。 解决：检查 dts 设备树中 CPU 频点配置，确认 cpufreq-dt 驱动加载成功。

---

七、实践建议与最佳实践

结合服务端、嵌入式、实时系统三大场景，给出调优、调试、排错的最佳实践。

7.1 调频器选型最佳实践

1. 工业实时 Linux / 低延迟场景：强制使用 schedutil，禁用 ondemand。调度感知的平滑调频能最大程度降低调度延迟，是实时系统标配。
2. 传统服务器、批量运算任务：默认 schedutil 即可，无需修改；大批量离线计算可临时切换为 performance 锁最高频。
3. 嵌入式低功耗设备：使用 schedutil + 调大 rate_limit_us，减少调频次数，优先保证续航。
4. 老旧内核（<4.7）：只能使用 ondemand，建议内核升级后迁移至 schedutil。

7.2 Schedutil 参数调优技巧

• 实时场景：rate_limit_us 设置为 500~2000 us，提升频率响应速度；
• 低功耗 / IoT 场景：rate_limit_us 设置为 5000~15000 us，减少硬件调频动作；
• 桌面系统：保持内核默认参数，兼顾体验与功耗。

7.3 调试与排错技巧

1. 频率异常追踪：使用 trace-cmd 抓取内核调度与 cpufreq 事件，定位调频触发时机：

   sudo trace-cmd record -e sched -e cpufreq
   sudo trace-cmd report
   

2. 确认 util 负载有效性：结合 top、htop 查看 CPU 使用率，对比调度器 util 值是否正常。
3. 永久修改默认调频器：临时修改重启失效，如需永久生效，可修改内核启动参数 intel_pstate=disable cpufreq.default_governor=schedutil。

7.4 避坑建议

1. 不要在实时任务运行过程中频繁修改 rate_limit_us，会引入突发延迟；
2. 虚拟化环境中（KVM/VMware），部分虚拟机不支持完整 DVFS，调频功能会被宿主机接管，虚拟机内调整无效；
3. 不要同时启用多个功耗管理服务（thermald、powerd），会和 schedutil 抢占调频控制权。

---

八、总结与落地应用

8.1 全文要点回顾

本文从原理、环境、实操、源码、排错五个维度完整讲解了 Linux Schedutil 调频器：

1. 梳理了 CPUFreq 子系统架构，明确 Schedutil 与传统 ondemand 的本质差异：基于调度器 util 负载统计，而非全局定时采样；
2. 完成了环境搭建、调频器切换、参数调优、压力对比等全流程实操，配套大量可直接复用的命令；
3. 解析了 Schedutil 核心内核源码，讲解了回调触发、频率计算、工作队列、限流防抖频四大核心逻辑；
4. 针对实操中高频问题给出解决方案，并结合不同业务场景输出选型与调优最佳实践。

Schedutil 不是简单的 “升级版调频器”，它是 Linux 内核调度子系统与功耗子系统深度融合的典型设计，体现了内核 “模块协同” 的设计思想。相比传统方案，它在延迟、平滑性、精准度上全面领先，也是当前 Linux 内核主推的默认调频方案。

8.2 落地应用与学习延伸

在工程落地中，Schedutil 已经全面渗透到各类 Linux 设备：工业实时控制系统依靠它保障任务低延迟，云服务器依靠它降功耗，嵌入式物联网设备依靠它平衡性能与续航。

对于技术调研、论文撰写的读者，可基于本文源码与实操内容做进一步延伸：对比不同内核版本 schedutil 代码差异、测试不同 rate_limit_us 参数下的延迟 / 功耗数据、结合 RT 实时补丁测试调度延迟表现。建议读者将本文的实操步骤在个人测试机、开发板上完整复现，从 “会用” 逐步深入到 “懂原理、能调优、能排错”，真正掌握 Linux 调度与功耗联动的核心技术。