判断cpu是否真在动态调节的唯一可靠方式是查看scaling_cur_freq与scaling_governor的实时组合：governor必须为ondemand、powersave或schedutil，且scaling_min_freq与scaling_max_freq不等，同时scaling_cur_freq需在二者间随负载真实跳变。
直接看 /sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq 和 scaling_governor 的实时组合，才是判断主频是否真在动态调节的唯一可靠方式。任务管理器或 lscpu 的 CPU MHz 字段全是静态估算或缓存值，不能反映调节行为。
确认调频器（governor）是否启用动态策略
调频器决定 CPU 是否响应负载变化。如果它被设为 performance，频率下限被拉高，实际就失去“动态调节”意义；只有 ondemand、powersave 或 schedutil 才会根据负载升降频。
- 运行
cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor，输出必须是ondemand、powersave或schedutil—— 若为performance，说明系统主动放弃了动态调节 - 注意：不同核心可能用不同 governor（尤其大小核架构），要检查多个核心，如
cpu0、cpu4，别只看第一个 - 若输出为空或报
No such file or directory，说明内核没加载 cpufreq 驱动（如intel_cpufreq），dmesg | grep -i "cpu.*freq"可验证
验证频率范围是否真正可变
即使 governor 是 ondemand，如果上下限被锁死，调节也形同虚设。关键看 scaling_min_freq 和 scaling_max_freq 是否不同。
- 执行
cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_min_freq和cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq - 两个值必须不等（例如 800000 vs 4700000），否则调节区间坍缩，CPU 只能跑固定频率
- 常见原因：BIOS 中禁用了 SpeedStep / Cool'n'Quiet；或 systemd 服务（如
power-profiles-daemon）强制设了窄区间；云主机常默认锁频
观察 scaling_cur_freq 是否随负载跳变
这是最终判决依据。数值必须在 min/max 范围内真实波动，而不是长期静止或仅在两个极值间切换。
- 用
watch -n 0.5 'cat /sys/devices/system/cpu/cpu*/cpufreq/scaling_cur_freq'实时看全部逻辑核 - 同时开一个轻负载（如
stress-ng -c 1 --timeout 5s），观察对应核心频率是否从 ~800 MHz 升至 ~3000+ MHz，空闲后回落 - 若所有核频率同步升降、无梯度差异（如大小核都卡在 2.4 GHz），可能是调度器未识别拓扑，或 BIOS 关闭了 core parking
- 注意：虚拟机中该路径常为空或恒定，KVM/QEMU 默认不透传频率寄存器
区分“动态调节”和“睿频生效”的混淆点
很多人误把睿频当成调节本身——其实睿频是硬件加速机制，而动态调节是 OS 层策略。两者有关联但不是一回事。
-
scaling_cur_freq接近cpuinfo_max_freq（差值 -
scaling_cur_freq恒等于cpuinfo_max_freq，但scaling_governor是performance→ 无动态调节，只是放开上限让睿频随时触发 - 想验证纯睿频行为，得用
turbostat（Intel 平台），看Core MHz是否持续高于Base_MHz，且Turbo列有数值
最易被忽略的是：多核系统里，单个核心的 scaling_cur_freq 文件可能因隔离（isolcpus）或 offline 状态而读不到，查 cat /sys/devices/system/cpu/online 才知道哪些核真在参与调节。
