直接查看cpupower frequency-info输出中的governor字段，若为powersave或ondemand即确认启用节能策略；需结合watch命令批量验证所有核心策略是否统一，并排查BIOS中EIST、C-states、Turbo Boost等固件级限制及turbostat中的THERM/PROCHOT状态。
怎么确认当前CPU调频策略是不是powersave
直接看cpupower frequency-info输出里的governor字段。如果显示powersave或ondemand，基本可以锁定是电源管理策略在主动压频。别只信lscpu里那个CPU MHz值——它只是瞬时读数，可能刚被拉高又掉下去了。
更稳的验证方式是用watch -n 0.5 'cat /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor 2>/dev/null | sort -u'，一次性检查所有CPU核心是否统一策略。有些系统会因NUMA或热插拔导致部分core仍卡在powersave。
为什么设成performance后频率还是上不去
OS层策略只是其中一环，BIOS/UEFI固件里的节能开关可能覆盖它。常见干扰项包括：
-
EIST（Intel SpeedStep）或AMD Cool'n'Quiet在BIOS中被启用，且未设为Disabled或Performance -
C-states深度睡眠被强制开启（尤其是C6及以上），导致唤醒延迟触发频率回退 -
Intel Turbo Boost被禁用，即使设为performance，最高也只能跑到基础频率 - 某些国产平台固件默认启用
Energy Efficient模式，Linux无法绕过该限制
进BIOS确认这些选项，比在OS里反复调cpupower更有效。
如何排查温控和供电导致的隐性降频
即使governor是performance，turbostat --debug里若持续看到THERM或PROCHOT置位，说明硬件层正在强制限频。这时sensors看到的温度可能还没到阈值，但主板VRM供电温度、SoC封装温度或PCH芯片温度已触发保护。
关键动作：
- 运行
turbostat --debug -I 1观察每秒的THERM/PROCHOT状态 - 查
/sys/class/hwmon/下所有temp*_input文件，不只看CPU核心，也看Package和PCH相关温度 - 某些服务器平台需加载
coretemp或it87模块才能读取完整传感器
ASPM和PCIe链路电源管理也会拖慢CPU表现
看起来是CPU频率问题，但根源可能是PCIe设备被ASPM（Active State Power Management）拉进L0s/L1状态，导致CPU频繁等待IO响应，调度器误判为“空闲”，进而触发降频。这种情况在NVMe SSD直通、GPU虚拟化或高速网卡场景下特别隐蔽。
检查方法：
-
lspci -vv -s $(lspci | grep NVMe | head -1 | awk '{print $1}') | grep ASPM，确认是否显示ASPM L1或ASPM Disabled - 临时关闭：
echo "pcie_aspm=off" >> /etc/default/grub，然后update-grub && reboot - 注意：部分ARM平台或国产固件不支持该内核参数，需改用
pci=noacpi或BIOS中禁用ASPM
真正棘手的不是策略开关本身，而是多个电源管理层级（固件→内核→驱动→设备）之间存在冲突或未同步。比如BIOS开了C6，内核启用了ASPM，而NVMe驱动又在做runtime PM，三者叠加会让CPU在performance模式下依然“假性空闲”。这种时候单看cpupower输出毫无意义，必须逐层验证。
