Linux Schedutil 的 sugov_policy：调频策略的 per-CPU 管理

一、简介

在现代 Linux 系统中，CPU 频率调频（CPUFreq）是衔接进程调度子系统与硬件电源管理的核心模块，直接决定系统的性能、功耗、发热三者的平衡。传统ondemand、performance等调频策略依赖独立定时器轮询 CPU 负载，调度延迟高、响应滞后，在实时嵌入式、边缘计算、高性能服务器、车载操作系统等场景下弊端明显。

Schedutil是 Linux 内核主推的调度器感知型调频策略，它深度耦合进程调度逻辑，不再使用独立定时器，而是由调度器在任务入队、出队、调度节拍等时机主动触发负载统计与频率调整，做到负载变化即调频，响应速度远优于传统策略。

而struct sugov_policy作为 Schedutil 的核心数据结构，承担着单 CPU/CPU 组调频状态全生命周期管理的职责，为每个逻辑 CPU 维护独立的调频上下文、历史频率、更新时间、限流状态等关键信息，是实现精细化、低延迟 per-CPU 调频的基础。

对于一线 Linux 工程师而言，吃透sugov_policy不仅能理解 CPU 调频的底层运行逻辑，还能解决嵌入式设备卡顿、服务器功耗过高、实时任务抖动、调频震荡等线上问题；同时也是内核裁剪、实时内核（PREEMPT-RT）移植、车载 / 工控系统性能调优、内核论文与技术报告撰写的必备知识点。本文从实战角度出发，结合源码、命令、实操步骤、问题排查，完整拆解sugov_policy的设计、运行与落地使用。

二、核心概念与术语解析

本节梳理本文涉及的内核基础概念、数据结构、模块关联关系，新手也可快速建立知识框架。

2.1 CPUFreq 子系统整体架构

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

1. 用户层：通过sysfs文件系统提供控制接口，位于/sys/devices/system/cpu/，可读写调频策略、最大 / 最小频率、当前频率；
2. 调频 Governor（策略层）：核心决策层，负责根据 CPU 负载计算目标频率，本文主角schedutil属于该层；
3. 平台驱动层：对接 CPU 硬件 P-State、电压调节器，执行最终的频率切换，如acpi-cpufreq、arm-bL等驱动。

2.2 Schedutil 调频策略特性

• 调度器联动：依托 CFS / 实时调度器的调度事件触发调频，无额外轮询定时器，降低系统开销；
• Per-CPU 独立管理：每个逻辑 CPU 拥有独立的sugov_policy实例，支持单核单独调频，区别于传统全局策略；
• 负载驱动调频：以调度器统计的CPU 利用率为依据，动态拉升 / 降低主频；
• 限流防抖：通过last_freq_update_time做时间节流，避免负载小幅波动引发频率频繁跳变（调频震荡）。

2.3 核心结构体：struct sugov_policy

sugov_policy是 Schedutil 为每个 CPU 维护的私有调频状态结构体，定义在kernel/sched/cpufreq_schedutil.c中，所有频率决策、状态记录、限流控制都依赖该结构体成员。下面逐字段解释核心成员（内核 5.4/5.10/5.15 通用版本）：

/* 精简版内核原生结构体，保留实战核心字段 */ struct sugov_policy { struct cpufreq_policy *policy; // 指向CPUFreq核心策略结构体，关联硬件频点范围 struct sugov_cpu *sugov_cpu; // 指向per-CPU负载统计结构体，存放CPU利用率 unsigned int next_freq; // 【核心】下一次准备切换的目标频率（单位：kHz） unsigned int last_freq; // 【核心】上一次成功切换的运行频率（单位：kHz） ktime_t last_freq_update_time; // 【核心】上一次频率更新的时间戳，用于调频限流 struct work_struct work; // 工作队列，异步执行频率切换，避免抢占调度上下文 bool need_freq_update; // 标记：是否需要执行频率更新动作 };

关键字段解读：

1. next_freq：Schedutil 计算得出的目标频率，调度器更新负载后会改写该字段；
2. last_freq：CPU 当前实际运行频率，作为新旧频率对比依据；
3. last_freq_update_time：时间戳，用来实现调频防抖，内核通过该字段限制最小调频间隔，防止硬件频繁切换频率导致功耗上升、硬件损耗；
4. work：内核工作队列。调度上下文属于临界区，不适合直接操作硬件，因此将频率切换动作抛到工作队列异步执行。

2.4 配套工具与术语

• sysfs：Linux 虚拟文件系统，CPUFreq 所有调试、配置接口均基于 sysfs；
• cpufreq-info：用户态调频信息查看工具；
• PREEMPT-RT：Linux 实时补丁，工控、车载场景常用，Schedutil 是 RT 内核首选调频策略；
• 调频震荡：CPU 负载小幅波动时，频率在高低频之间反复切换的异常现象。

三、环境准备

本文所有实操基于主流 Linux 发行版与内核版本，提供完整环境搭建、工具安装、内核配置指引，保证读者复现效果一致。

3.1 软硬件环境要求

3.2 工具安装

执行以下命令安装调频调试、内核查看、编译工具，所有命令可直接复制执行：

# 更新软件源 apt update -y # 安装CPUFreq调试工具、内核工具、编译依赖 apt install cpufrequtils linux-tools-common linux-tools-$(uname -r) build-essential libncurses-dev -y # 安装内核源码（可选，用于阅读sugov_policy源码） apt install linux-source -y

3.3 内核配置校验（关键）

Schedutil 策略依赖内核编译选项，需确认内核已开启对应配置。

1. 查看当前内核已开启的 CPUFreq 配置：

# 查看内核编译配置 zcat /proc/config.gz | grep -i cpufreq

1. 必须保证以下配置项为y或m（内置 / 模块）：

CONFIG_CPU_FREQ=y CONFIG_CPU_FREQ_GOV_SCHEDUTIL=y CONFIG_CPU_FREQ_DEFAULT_GOV_SCHEDUTIL=y

• 若CONFIG_CPU_FREQ_GOV_SCHEDUTIL为n：说明内核未编译 Schedutil，需要重新编译内核开启该选项；
• 嵌入式 / 定制内核务必开启以上配置，否则无法使用本文所有功能。

3.4 前置环境验证

切换默认调频策略为schedutil，并验证环境可用性：

# 1. 查看当前所有CPU使用的调频策略 cpufreq-info | grep "governor" # 2. 临时将所有CPU切换为schedutil（重启失效） for cpu in /sys/devices/system/cpu/cpu[0-9]*;do echo schedutil > $cpu/cpufreq/scaling_governor done # 3. 再次验证，确认策略切换成功 cpufreq-info | grep "current governor"

执行后输出current governor: "schedutil"即为环境准备完成。

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

sugov_policy支撑的 Schedutil 调频策略，主要应用在对延迟、功耗、实时性有双重要求的场景。第一类是工业工控与车载实时系统，这类设备搭载 PREEMPT-RT 实时内核，要求任务调度无明显抖动，Schedutil 依托调度器触发调频，配合sugov_policy的 per-CPU 独立状态管理，可单独对实时核心做频率锁定，兼顾实时性与低功耗。第二类是边缘计算与物联网网关，设备 CPU 负载波动大，白天高负载运算、夜间低负载待机，last_freq_update_time限流机制可避免调频震荡，延长硬件寿命。第三类是云服务器与容器集群，多租户场景下不同 CPU 核心负载差异极大，per-CPU 精细化调频能精准控制单核心功耗，降低整机散热与电力成本。以上场景均离不开sugov_policy对每个 CPU 调频状态的独立维护。

五、实际案例与分步实操（含源码 + 命令 + 注释）

本章分为用户态实操观测、内核源码逻辑分析、自定义负载触发调频三大部分，每一步附带代码、命令、作用说明，全部可直接复现。

5.1 案例一：通过 sysfs 观测 CPU 调频状态（用户层实战）

步骤 1：查看 CPUFreq Policy 分组

现代 CPU 会将多个逻辑核心划为一个cpufreq_policy组，同组 CPU 共享硬件频点，而sugov_policy会在此基础上做 per-CPU 状态拓展。

# 查看所有CPU对应的cpufreq策略组 ls /sys/devices/system/cpu/cpufreq/

作用：列出policy0、policy1等目录，每个目录对应一组共享调频硬件的 CPU。

步骤 2：查看单 CPU 频点与运行状态

以cpu0为例，查看当前频率、最大 / 最小频点、运行状态：

# 1. 查看CPU0当前运行频率（硬件真实频率，单位kHz） cat /sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_cur_freq # 2. 查看CPU支持的最低/最高频率 cat /sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_min_freq cat /sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_max_freq # 3. 查看当前生效的调频策略 cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor

作用：确认 CPU 硬件频域范围，验证schedutil正常加载，为后续负载测试做准备。

步骤 3：手动修改频率限制，观测 sugov_policy 行为

通过修改最大频率，观察 Schedutil 如何更新next_freq与last_freq：

# 临时限制cpu0最大频率为1.2GHz（1200000 kHz） echo 1200000 > /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq # 恢复为硬件默认最大频率（后续执行） cat /sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_max_freq > /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq

原理：当上层修改频率限制后，sugov_policy->policy感知到频域变化，Schedutil 会重新计算next_freq，并通过工作队列更新last_freq。

5.2 案例二：内核源码解析 ——sugov_policy 初始化流程

本案例分析sugov_policy结构体的创建、初始化、绑定 CPU 的内核源码逻辑，代码取自 Linux 5.10 原生cpufreq_schedutil.c，附带详细注释。

步骤 1：sugov_policy 分配与初始化函数

Schedutil 策略加载时，会为每个cpufreq_policy创建sugov_policy实例：

// 源码路径：kernel/sched/cpufreq_schedutil.c static int sugov_init(struct cpufreq_policy *policy) { struct sugov_policy *sg_policy; int ret; // 1. 为sugov_policy分配内核内存 sg_policy = kzalloc(sizeof(*sg_policy), GFP_KERNEL); if (!sg_policy) return -ENOMEM; // 2. 绑定上层cpufreq_policy，建立关联 sg_policy->policy = policy; // 初始化工作队列，用于异步执行频率切换 INIT_WORK(&sg_policy->work, sugov_work); // 初始化标记：暂时无需更新频率 sg_policy->need_freq_update = false; // 初始化时间戳，记录首次更新时间 sg_policy->last_freq_update_time = ktime_get(); // 3. 初始化初始频率：设置last_freq为CPU当前运行频率 sg_policy->last_freq = cpufreq_get(policy); sg_policy->next_freq = sg_policy->last_freq; // 4. 将sugov_policy挂载到cpufreq_policy私有数据域 policy->governor_data = sg_policy; // 5. 为组内每个CPU初始化per-CPU负载结构体sugov_cpu ret = sugov_alloc_sugov_cpus(sg_policy, policy); if (ret) { kfree(sg_policy); return ret; } return 0; }

代码作用说明：

1. kzalloc：清零分配sugov_policy内存，保证初始状态合法；
2. INIT_WORK：初始化工作队列，内核规定调度上下文不能直接操作硬件，频率切换必须异步执行；
3. last_freq_update_time = ktime_get()：记录初始化时间，作为调频限流的时间基准；
4. 初始化完成后，每个 CPU 组都拥有独立的sugov_policy实例。

步骤 2：负载更新 → 修改 next_freq 核心逻辑

调度器检测到 CPU 负载变化时，调用sugov_update_single更新目标频率，修改sugov_policy->next_freq：

static void sugov_update_single(struct sugov_cpu *sg_cpu, u64 now) { struct sugov_policy *sg_policy = sg_cpu->sg_policy; unsigned int util, freq; // 1. 获取调度器统计的CPU利用率（0~1023） util = sugov_get_util(sg_cpu); // 2. 根据利用率计算目标频率，映射到硬件频点范围 freq = map_util_to_freq(sg_policy->policy, util); // 3. 更新下一次要切换的目标频率 next_freq sg_policy->next_freq = freq; // 4. 标记需要执行频率更新 sg_policy->need_freq_update = true; // 5. 触发工作队列，异步执行调频 queue_work(system_wq, &sg_policy->work); }

代码作用说明：

• 调度器每一次任务切换、节拍中断都会触发该函数；
• next_freq是待生效频率，不会立刻写入硬件；
• 调用queue_work唤醒工作队列，由sugov_work完成最终频率切换。

步骤 3：工作队列回调 —— 执行频率切换 & 更新 last_freq

工作队列函数是最终操作硬件、更新last_freq和时间戳的入口：

static void sugov_work(struct work_struct *work) { struct sugov_policy *sg_policy = container_of(work, struct sugov_policy, work); struct cpufreq_policy *policy = sg_policy->policy; unsigned int target_freq; ktime_t now; s64 delta; // 1. 获取当前系统时间，计算与上一次调频的时间差 now = ktime_get(); delta = ktime_to_ns(ktime_sub(now, sg_policy->last_freq_update_time)); // 2. 调频限流判断：小于最小间隔则直接退出，防止调频震荡 if (delta < policy->min_transition_latency) return; // 3. 读取目标频率，清除更新标记 target_freq = sg_policy->next_freq; sg_policy->need_freq_update = false; // 4. 调用CPUFreq驱动，切换硬件频率 __cpufreq_driver_target(policy, target_freq, CPUFREQ_RELATION_L); // 5. 更新核心状态：last_freq、最后更新时间戳 sg_policy->last_freq = target_freq; sg_policy->last_freq_update_time = now; }

核心逻辑总结：

1. 利用last_freq_update_time做时间节流，控制最小调频间隔；
2. 硬件调频成功后，将next_freq赋值给last_freq，代表当前生效频率；
3. 整套流程实现：负载变化 → 计算目标频点 → 限流判断 → 异步调频 → 更新状态。

5.3 案例三：压测 CPU，观测 sugov_policy 调频全过程

通过压力工具制造 CPU 负载波动，直观验证 Schedutil 与sugov_policy的工作流程。

步骤 1：安装 CPU 压力测试工具

apt install stress -y

步骤 2：后台压测 CPU0，制造高负载

# 仅压测cpu0，持续占用CPU核心 taskset -c 0 stress -c 1 -t 30 &

参数说明：taskset -c 0绑定进程到 cpu0，-t 30压测 30 秒。

步骤 3：实时观测 CPU 频率变化

新开终端，持续打印 cpu0 频率：

# 循环查看当前频率，每秒刷新一次 while true;do cat /sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_cur_freq sleep 1 done

现象：压测开始后，频率逐步拉升至最大值；压测结束后，频率缓慢下降至低频，对应sugov_policy中next_freq、last_freq的动态变更。

步骤 4：停止压测任务

# 终止所有stress进程 pkill stress

六、常见问题与解答（结合实操与源码）

Q1：切换为 schedutil 后，CPU 频率一直固定不变，不随负载调整？

原因：

1. 内核未开启CONFIG_CPU_FREQ_GOV_SCHEDUTIL，策略未真正加载；
2. cpufreq_policy被 BIOS / 主板锁定最大 / 最小频点；
3. 实时内核关闭了动态调频功能。解决方法：

# 1. 校验策略是否真正生效 cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor # 2. 查看频点是否被锁定 cat /sys/devices/system/cpu/cpu0/cpufreq/bios_limit # 3. 重置频点范围 cat /sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_min_freq > /sys/devices/system/cpu/cpu0/cpufreq/scaling_min_freq cat /sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_max_freq > /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq

Q2：CPU 负载轻微波动，频率反复跳变（调频震荡）？

原因：sugov_policy->last_freq_update_time设置的最小调频间隔过小，防抖失效。解决方法：修改 CPU 切换延迟，增大限流时间，内核层需调整min_transition_latency，用户层可临时加大负载滤波。

Q3：部分 CPU 核心使用 schedutil，部分核心无调频动作？

原因：多 CPU 共享同一个cpufreq_policy，硬件层面无法单独调频，sugov_policy是按 policy 组管理，而非严格单 CPU。解决方法：进入 BIOS 关闭 CPU 频率同步功能，让每个核心拥有独立硬件调频接口。

Q4：执行调频命令提示Permission denied权限不足？

原因：普通用户无 sysfs 写入权限。解决方法：全程使用root用户操作，或添加 sudo：

sudo echo schedutil > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor

Q5：内核日志出现workqueue lockup，和 sugov_policy 相关？

原因：sugov_work工作队列执行耗时过长，阻塞系统工作队列。解决方法：检查 CPU 底层调频驱动是否异常，更换稳定版 cpufreq 驱动，避免在工作队列中执行耗时操作。

七、实践建议与最佳实践

结合多年内核调优、嵌入式落地经验，总结schedutil + sugov_policy的生产环境最佳实践，分为性能优化、稳定性、调试排错三大方向。

7.1 性能优化最佳实践

1. 实时工控 / PREEMPT-RT 场景实时任务要求低抖动，建议将实时核心的scaling_min_freq设置为最高频率，固定主频。原理：sugov_policy不再频繁变更频率，消除调频延迟对实时任务的影响。

   # 固定cpu0为最高频（实时核心） cat /sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_max_freq > /sys/devices/system/cpu/cpu0/cpufreq/scaling_min_freq

2. 服务器 / 低功耗场景保留 Schedutil 默认限流策略，依靠last_freq_update_time防抖，兼顾功耗与响应速度，不要盲目调小调频间隔。

7.2 稳定性最佳实践

1. 生产环境优先使用 Linux 5.4/5.10 LTS 内核，这两个版本sugov_policy逻辑最稳定，BUG 最少；
2. 禁止频繁在schedutil/ondemand/performance之间切换策略，频繁切换会导致sugov_policy反复创建销毁，引发内存碎片；
3. 嵌入式设备不要关闭调频限流，硬件频繁切换频点会加速芯片老化。

7.3 调试与排错技巧

1. 追踪 sugov_policy 状态开启内核ftrace跟踪sugov_work、sugov_update_single函数，定位调频不生效问题，适合深度内核调试。
2. 日志排查调频异常时优先查看内核日志：dmesg | grep cpufreq，查看驱动加载、策略初始化报错。
3. 源码阅读技巧阅读sugov_policy源码时，优先梳理初始化→负载更新→调频执行三条主线，逐个跟踪next_freq、last_freq、last_freq_update_time三个核心字段的变化。

7.4 内核裁剪建议（嵌入式专用）

嵌入式设备裁剪内核时，若使用 Schedutil，必须保留：

• CONFIG_CPU_FREQ、CONFIG_CPU_FREQ_GOV_SCHEDUTIL
• 工作队列依赖CONFIG_WORKQUEUE不要单独裁剪 CPUFreq 子系统，否则sugov_policy结构体直接失效。

八、总结与拓展应用场景

8.1 全文要点回顾

本文从实战角度完整拆解了schedutil调频策略的核心载体struct sugov_policy，核心要点总结：

1. sugov_policy是 Schedutil 实现 per-CPU 精细化调频的核心数据结构，为每个 CPU/CPU 组独立维护调频状态；
2. next_freq代表待切换目标频率，last_freq代表当前生效频率，last_freq_update_time实现调频防抖与限流；
3. 整体运行链路：调度器负载统计 → 更新 next_freq → 工作队列异步调频 → 更新 last_freq 与时间戳；
4. Schedutil 深度耦合 Linux 调度子系统，相比传统调频策略拥有更低延迟、更高响应速度。

8.2 拓展应用场景

sugov_policy与 Schedutil 并非仅用于通用 Linux 系统，在工业领域落地场景十分广泛：

1. 车载操作系统：车规级 Linux+PREEMPT-RT，利用 per-CPU 调频区分娱乐核心与自动驾驶实时核心；
2. 工业机器人 / PLC：严格控制调频延迟，保证运动控制任务时序精准；
3. 5G 边缘网关：负载潮汐特征明显，动态调频降低整机功耗；
4. 云计算容器集群：按容器负载动态调整 CPU 频率，提升整机资源利用率。

8.3 学习建议

对于从事内核开发、性能调优、嵌入式开发的工程师，建议基于本文环境进一步做深度实验：修改内核中sugov_policy的限流时间、改写频率映射函数，观察系统行为变化；同时结合 CFS 调度器源码，理解调度负载统计与调频的联动逻辑。掌握sugov_policy的设计与运行机制，不仅能解决线上各类调频问题，也是深入研究 Linux 调度与电源管理子系统的重要基石。