直接读取cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor可获当前生效的调频器（如performance），最可靠；若需验证全核一致性，用cat /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor 2>/dev/null | sort -u。
怎么查当前生效的 scaling_governor
直接读取 sysfs 接口最可靠，不依赖任何额外工具。每个 CPU 核心都有独立的 scaling_governor 文件，但通常所有核心保持一致，查 cpu0 就够了：
-
cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor—— 输出如ondemand或performance，就是当前实际生效的调节器 - 如果报错
No such file or directory，说明 cpufreq 驱动没加载（常见于虚拟机、某些精简内核或 BIOS 禁用了 SpeedStep/C1E） - 别信
cpupower frequency-info的输出——它可能缓存旧状态，或在多核不一致时只显示第一个核，不如直接读 sysfs 真实
怎么确认所有核心用的是同一个 governor
有些场景（比如手动绑核调优或故障排查）需要验证是否真的一致，不能只看 cpu0：
Zynq Linux Hardware Debug
下载
Zynq‑7000 / Zynq UltraScale+ 硬件调试技能。适用于 Xilinx Zynq（Cortex‑A9/A53 + FPGA）Linux 环境，调试 I2C、I2S、UART、GPIO 等外设。包括设备树配置、内核驱动、用户空间调试工具、交叉编译和常见问题排查，支持 PetaLinux 开发。
-
cat /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor 2>/dev/null | sort -u—— 正常应只输出一行；若出现多行，说明部分核心被单独设过（比如通过echo powersave > /sys/.../cpu3/cpufreq/scaling_governor） - 注意：
cpu*通配符会包含离线核心（如热插拔后未启用的），加2>/dev/null屏蔽报错更干净 - 如果某核心路径不存在（比如
cpu4），说明该核心当前离线，scaling_governor不可读，不是配置问题
为什么 cat scaling_governor 返回 performance 却感觉卡顿
performance 只代表“锁最高频”，不代表频率真跑到了标称最大值——硬件限制、温度墙、电源策略都可能压频：
- 先看真实运行频率：
cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq，对比scaling_max_freq是否接近 - 检查 BIOS 设置：若启用了 “Intel SpeedStep Disable” 或 “AMD Cool’n’Quiet Disable”，会导致 cpufreq 子系统失效，
scaling_governor仍可读但无实际调控能力 - 排查干扰服务：systemd 的
power-profiles-daemon或thermald可能覆盖内核默认策略，临时停掉再试：sudo systemctl stop power-profiles-daemon thermald
scaling_available_governors 里没有 schedutil 怎么办
schedutil 是较新内核（≥4.8）才默认启用的调频器，老内核或某些发行版裁剪后可能缺失：
- 查内核版本：
uname -r，低于 4.8 基本不用指望schedutil - 确认是否编译进内核：
zcat /proc/config.gz | grep CONFIG_CPU_FREQ_GOV_SCHEDUTIL（若提示 no such file，说明 config 不可用，改查/boot/config-$(uname -r)） - 输出
y表示编译为模块，需加载：sudo modprobe cpufreq_schedutil；输出m表示编译为模块但未加载；n则彻底不支持 - 即使支持，某些 CPU 微架构（如早期 Atom）也不兼容
schedutil，强行写入会失败并报错Invalid argument
scaling_governor 读起来正常，但频率根本不会变——必须三步验证（governor + min/max 可变性 + cur_freq 实时跳变）才算真正启用缩放。 
