一、简介1.1 技术背景在 Linux CPUFreq 日常运维中运维人员经常会运行时动态修改scaling_max_freq最大主频、scaling_min_freq最小主频无需重启内核、不用重启进程在线收缩或放宽 CPU 算力上限。 但这里存在一个内核逻辑矛盾 Schedutil 依靠cached_raw_freq缓存上一轮map_util_freq计算出的未裁剪原始频率用于跳过重复数学计算而scaling_min/max_freq属于 policy 层外部约束不会自动刷新缓存内容。 如果修改频率限制后不主动触发一次重算会出现两类典型异常上限调低后频率无法下降原始缓存 raw 频率高于新 max 限制但缓存未刷新冷却窗口内继续沿用旧值钳位CPU 依旧跑在超限频率上限拉高后频率无法拉升缓存 raw 频率被旧 max 截断新上限放开后内核不会主动重新映射更高目标频率负载拉满主频依旧上不去。为解决策略边界动态变更后调频状态不同步问题Schedutil 在struct sugov_policy中内置布尔标记位limits_changed。 当用户通过 sysfs 修改scaling_max_freq/scaling_min_freqCPUFreq 内核层会感知 policy 限制变动将对应 CPU 的sugov_policy-limits_changed置为true。 在下一次负载上报、调度事件触发调频流程时内核检测该标记标记为 true强制清空cached_raw_freq缓存无视复用逻辑强制重新执行map_util_freq映射计算使用全新的 min/max 区间裁剪出新的next_freq计算完成后将limits_changed重置为 false后续正常走缓存优化流程。简单直白概括核心作用limits_changed 策略限制已修改标志用来打断旧缓存、强制重算频率让新的最大 / 最小频率限制立刻生效。该机制是动态在线调参能够即时生效的底层保障绝大多数 “改了最大频率但 CPU 频率纹丝不动” 的线上问题根源就是不理解该标记的刷新逻辑与执行时机。1.2 典型落地应用场景IDC 服务器动态功耗限流业务流量突增临时放开 CPU 最大频率夜间低峰直接缩窄上限降功耗limits_changed 自动触发重算无需重启任何服务瞬时生效算力约束。ARM 嵌入式设备场景切换车载设备导航场景拉高频率上限保证流畅停车休眠场景降低峰值频率控温省电修改 sysfs 后依靠该标志自动适配调频区间。云原生容器资源熔断宿主机检测到 Pod 进程异常疯狂占用 CPU在线下调对应核心 scaling_max_freqlimits_changed 触发重算快速压制算力占用防止单租户雪崩影响整机。工业 PREEMPT_RT 实时系统动态组态生产流程切换工序时远程修改 CPU 频率锁频区间标记置位后调度器自动适配新主频不中断实时控制任务运行。老旧 CPU 硬件过热保护温度监控脚本检测 CPU 温度超标自动下调最大频率依靠 limits_changed 刷新调频策略避免 CPU 过热死机实现无间断硬件防护。1.3 学习本章核心价值打通 Schedutil 完整闭环明白外部 sysfs 改参数 → 内核标记置位 → 下次调度强制清缓存重算 → 新限制生效整条链路彻底解决运维高频疑难问题修改 scaling_max/min 后频率不变化、延迟很久才生效的根因区分cached_raw_freq缓存优化与limits_changed强制刷新两种互斥逻辑理解内核容错设计可使用 perf 探针捕获标记置位事件量化参数修改后的内核行为用于性能故障定位补齐 sugov_policy 结构体全部核心字段含义完成 Schedutil per-CPU 状态管理模块全部知识点学习。二、核心概念与底层执行原理2.1 关键名词释义表格字段 / 机制归属结构体核心含义触发条件limits_changedsugov_policy频率限制已变更标记布尔值 true/falsesysfs 写入 scaling_max_freq /scaling_min_freqcached_raw_freqsugov_policy上一轮未经过 policy 裁剪的映射频率缓存正常负载计算后写入用于跳过重复计算map_util_freq函数根据 util 负载计算原生目标频率limits_changed 为 true 或 缓存不匹配时执行next_freqsugov_policy经过 min/max 钳位后的待下发硬件频率每次重算都会更新cpufreq_policy上层策略结构存放用户配置的 scaling_min、scaling_max用户 sysfs 直接修改该结构成员2.2 limits_changed 完整标准执行流程用户执行echo X scaling_max_freq写入 sysfs 节点CPUFreq 内核函数修改cpufreq_policy-max成员随即调用调速器通知回调Schedutil 收到 policy 变更通知将对应 CPU 的sugov_policy-limits_changed true此时缓存cached_raw_freq依旧是修改限制前的旧值不会主动刷新下一次进程唤醒 / 上下文切换触发cpufreq_update_util负载上报进入sugov_update_single_freq主逻辑优先判断limits_changed若为 true直接丢弃 cached_raw_freq强制调用 map_util_freq 全新计算原始频率使用最新的 policy.min、policy.max对新 raw 频率做边界截断赋值 next_freq把 limits_changed 重置为 false本轮强制刷新流程结束后续若无参数修改继续使用 cached_raw_freq 缓存机制优化计算开销。2.3 两种典型场景行为对比场景 A未修改频率限制常规负载波动util 小幅变化 → 对比 cached_raw_freq → 命中缓存直接复用无 map_util_freq 调用limits_changed 始终 false。场景 B修改 scaling_max_freq 后第一次负载上报limits_changed true → 无视缓存 → 强制重算 raw 频率 → 用新上限钳位 → 清除标记。2.4 两个极易混淆的关键点关键点 1修改参数不会立刻刷新频率必须等待下一次调度事件limits_changed 只是打标记不会主动发起变频必须等待任务切换、进程唤醒这类调度触发点才会执行重算。 如果修改完上限后 CPU 始终满载无调度切换可能需要数秒才会触发刷新想要立即生效可以手动制造一次进程切换。关键点 2修改 min 和 max 任意一个都会置位 limits_changed无论修改最小频率还是最大频率只要 cpufreq_policy 区间发生变动标记都会置位统一触发强制重算内核不会区分上下限。2.5 嵌入 Schedutil 全链路位置负载聚合更新 util 值判断 limits_changed 标记 ✅ 标记开启 → 废弃缓存强制重算 ❌ 标记关闭 → 尝试缓存匹配复用冷却防抖间隔校验freq_update_delay_ns边界裁剪生成 next_freq满足冷却条件下发硬件变频更新时间戳。三、环境准备3.1 软硬件硬性环境要求操作系统Ubuntu 20.04/22.04、Debian 11、CentOS Stream 8/9、嵌入式 Buildroot Linux内核版本Linux 5.4 及以上完整实现该标记逻辑推荐 5.15 / 6.1 LTS 主线内核硬件具备 DVFS 调频能力的物理 x86/ARM 设备虚拟机 CPUFreq 驱动缺失无法复现完整逻辑权限sysfs 写入、perf 内核探针操作必须使用 root 管理员账号。3.2 依赖工具一键安装Ubuntu / Debian 系列bash运行apt update -y apt install cpufrequtils stress-ng perf watch -yCentOS / RHEL / Stream 系列bash运行yum makecache fast yum install cpufrequtils stress-ng perf watch -y3.3 工具用途说明cpufrequtils一键全局切换 Schedutil 调频器确认调速器挂载正常stress-ng制造持续 CPU 负载与进程切换用来触发调度事件唤醒 limits_changed 刷新逻辑perf挂载内核 kprobe 探针捕获 limits_changed 分支执行直观验证标记生效watch实时监控 CPU 硬件运行频率肉眼观察参数修改前后频率变化。3.4 前置环境校验逐条执行bash运行# 整机所有CPU切换至Schedutil该机制仅在此调速器内生效 cpufreq-set -r -g schedutil # 查看CPU0原生硬件最大频率 cat /sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_max_freq # 查看当前正在使用的策略最大频率 cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq无报错即代表 CPUFreq 与 Schedutil 加载正常可开展后续实验。四、分步实战可复现案例实验一常规满载压测记录基准频率步骤 1设置初始最大频率为硬件原厂上限bash运行HW_MAX$(cat /sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_max_freq) echo $HW_MAX /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq步骤 2开启终端实时监控 CPU0 当前主频bash运行watch -n 1 cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq步骤 3后台持续满载压测bash运行stress-ng --cpu 1 --cpu-affinity 0 --timeout 120 此时 CPU 满载频率稳定运行在硬件最大值cached_raw_freq缓存为对应满负载原始频率。实验二在线下调最大频率限制观察频率不会立刻下降步骤 1修改 scaling_max_freq缩窄上限为原值 70%bash运行NEW_MAX$((HW_MAX * 7 / 10)) echo $NEW_MAX /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq echo 新设定上限$NEW_MAX步骤 2现象观测此时监控窗口频率不会立即变化依旧维持原有高频。 原因仅将sugov_policy-limits_changed置为 true但没有新的调度事件触发调频主函数缓存未刷新、未执行重算。实验三制造一次调度切换触发 limits_changed 强制重算新开终端执行一条短暂占用 CPU 的命令人为产生进程上下文切换bash运行sleep 0.1执行完毕后观察监控面板CPU 频率立即下降至新设定的 NEW_MAX 上限。原理验证sleep 指令触发任务切换进入 Schedutil 更新逻辑检测到 limits_changed 为 true丢弃旧缓存重新计算频率使用新 max 值裁剪最终变频生效。实验四使用 perf 探针捕捉 limits_changed 分支执行bash运行# 探针捕获标记为true时强制重算的代码分支 perf probe sugov_update_single_freq%if policy-limits_changed 1force_recalc # 再次重复修改频率上限sleep触发调度 echo $((HW_MAX * 6 / 10)) /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq sleep 0.2 # 采集事件 perf record -g sleep 3 perf report报告中可捕获force_recalc探针命中事件证明 limits_changed 分支被内核执行。实验五修改最小频率下限验证同机制生效bash运行# 拉高最小运行频率 echo 1200000 /sys/devices/system/cpu/cpu0/cpufreq/scaling_min_freq # 手动触发调度刷新 sleep 0.1空载状态下 CPU 不会回落至原低频被新的 min 下限约束同样依靠 limits_changed 标记触发重算适配新区间。实验六同 policy 多核心共享策略修改任意一核全组标记置位Intel 超线程 CPU cpu0 与 cpu1 共用一个 cpufreq_policybash运行# 修改cpu1的max上限 echo $((HW_MAX * 5 / 10)) /sys/devices/system/cpu/cpu1/cpufreq/scaling_max_freq # 分别给两个核心制造调度事件 sleep 0.1cpu0、cpu1 两颗 CPU 的 limits_changed 都会被置位两颗核心同步刷新频率限制符合 policy 共享设计。实验收尾还原系统默认配置bash运行# 杀掉压测进程 pkill stress-ng # 还原最大频率为硬件默认值 cat /sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_max_freq /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq # 还原最小频率为硬件默认值 cat /sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_min_freq /sys/devices/system/cpu/cpu0/cpufreq/scaling_min_freq # 删除perf内核探针 perf probe -d sugov_update_single_freq五、常见问题与精准答疑Q1修改 scaling_max_freq 之后频率迟迟不生效是什么原因根本原因limits_changed 仅做标记必须等待下一次 CFS 调度事件进程唤醒、切换、中断退出才会执行重算解决方式执行一次短暂 sleep、启停一个后台进程人为触发调度即可立刻刷新若长期完全无调度事件单核 100% 死循环无切换内核不会进入调频更新逻辑需要短暂中断负载。Q2为什么 ARM 设备 CPU 离线再上线后改参数标记好像不生效ARM 单核独占 cpufreq_policyCPU offline 会直接销毁整个 sugov_policy 结构体limits_changed 标记随内存释放消失重新 online 新建 policy标记初始为 false属于正常生命周期行为重新修改参数即可正常置位。Q3切换 governor 调速器后 limits_changed 会被重置吗会。切换调频器会销毁旧 sugov_policy 并重新实例化所有标记、缓存、时间戳全部初始化相当于重置整个调频状态。Q4能不能直接手动读写 limits_changed 这个字段该成员属于sugov_policy内核私有变量没有导出 sysfs 用户态接口只能由 CPUFreq 内核回调函数自动赋值应用层无法直接读写修改只能通过修改 min/max 间接触发。Q5批量循环修改多 CPU 频率上限部分核心频率刷新滞后批量写入 sysfs 会批量置位标记但每颗 CPU 需要各自的调度事件触发刷新可在循环末尾统一执行一次sleep 0.5批量触发所有核心重算消除滞后差异。Q6limits_changed 置位后一定会丢弃 cached_raw_freq 吗内核源码逻辑是无条件忽略缓存分支强制调用 map_util_freq 重新计算旧缓存值直接被新计算结果覆盖不存在复用旧缓存的可能。六、实践建议与生产环境最佳规范6.1 分场景参数修改运维规范1互联网线上业务服务器批量修改频率上下限脚本末尾增加sleep 0.5统一触发调度刷新避免分批生效导致多核心频率不一致业务低峰时段执行缩限操作减少调度抖动对在线请求的影响不频繁反复推拉 max 上限避免高频置位 limits_changed频繁强制计算拉高内核开销。2ARM 嵌入式车载 / 手持设备息屏降频脚本执行参数修改后主动创建短暂进程触发刷新确保立刻进入省电频率区间不要依赖被动调度事件。3PREEMPT_RT 硬实时控制系统尽量少动态修改频率限制如需调整建议直接预先锁频min 与 max 相等此时修改参数不会频繁触发重算与变频降低调度抖动。4温度联动降频防护脚本温度超标下调 max 频率后可向对应 CPU 写入一次短暂负载强制 limits_changed 逻辑立即生效防止 CPU 持续高温运行。6.2 调优避坑核心准则理解分层逻辑policy 层改配置 → 标记打勾 → 调度时机重算不要误以为写 sysfs 就会立刻变频缓存 cached_raw_freq 是性能优化limits_changed 是容错刷新二者设计互补而非冲突同 policy 策略组内不要单独修改单核心频率参数会全组同步标记建议整组统一配置内核不建议关闭该机制一旦移除 limits_changed 逻辑动态修改频率限制将永久无法生效。6.3 故障排查标准步骤改限后频率不动 → 确认 limits_changed 是否被置位 → 手动触发调度事件部分核心生效部分不生效 → 核查 policy 分组确认是否属于同一策略掩码多次修改后调频逻辑异常 → 重启调速器或重新 online/offline 对应 CPU重置 sugov_policy 结构体。6.4 自动化脚本优化写法批量修改频率并主动触发刷新模板bash运行#!/bin/bash MAX_FREQ1800000 for cpu in /sys/devices/system/cpu/cpu[0-9]*;do echo $MAX_FREQ $cpu/cpufreq/scaling_max_freq done # 统一触发调度让所有limits_changed标记批量生效 sleep 0.3七、总结与工程落地延伸7.1 全文核心知识点复盘limits_changed 本质Schedutil per-CPU 私有布尔标记在 scaling_max_freq /scaling_min_freq 被用户修改时由 CPUFreq 内核回调置 1用于标记频率约束条件已发生变更执行机制标记置位不会主动变频必须等待下一次 CFS 调度触发调频主流程随即强制废弃cached_raw_freq缓存调用 map_util_freq 基于全新 policy 区间重算目标频率之后自动清空标记共享策略特性多 CPU 共用 cpufreq_policy 时修改任意核心参数组内所有 CPU 标记全部置位ARM 单核单 policy 架构仅当前核心生效生命周期CPU 离线销毁 policy、切换调速器、内核热插拔重建 policy 时标记会随结构体初始化恢复默认 false核心工程意义打通用户态动态配置与内核调频决策之间的同步机制是在线运维、弹性功耗管控、设备防护功能不可或缺的底层支撑。7.2 多场景实战落地价值服务器集群能耗弹性管控无需重启服务即可动态约束 CPU 算力峰值适配业务潮汐流量降低机房供电与散热成本嵌入式设备电源策略动态切换应用层脚本可按需切换性能 / 省电档位内核依靠该机制无间断适配调频规则工业设备安全容错依托温度联动 limits_changed 热更频率上限实现硬件过热主动降频保护提升控制系统稳定性云原生租户资源隔离宿主机可在线限制异常 Pod 占用 CPU 主频实现轻量级资源熔断防止单业务影响宿主机整体稳定性。7.3 全系列 Schedutil CPUFreq 知识闭环本文作为 Schedutil 内核状态管理最后一个核心机制串联全部前文模块形成完整 DVFS 动态调频全链路scaling_min_freq/scaling_max_freq用户策略边界配置limits_changed策略变更标记与强制缓存刷新scaling_governor调频器策略选型绑定sugov_policyper-CPU 独立状态容器util多源负载聚合统计map_util_freq负载到频率线性映射换算cached_raw_freq重复计算缓存优化freq_update_delay_ns防抖节流冷却间隔last_freq_update_time上次变频时间戳判定CPU 热插拔 策略生命周期创建与销毁EAS 能效调度 上层调度协同决策cpufreq 驱动层 硬件寄存器变频下发至此整套 Linux CPU 动态电压频率调节从用户配置、内核决策、性能优化、异常刷新、资源生命周期、调度联动、硬件执行全流程原理与实操全部覆盖完毕可直接用于服务器性能基线制定、嵌入式固件电源管理开发、内核模块二次开发、线上疑难性能故障根因定位等工程场景。