最准的每核实时频率是直接读/sys/devices/system/cpu/cpu*/cpufreq/scaling_cur_freq，单位kHz，不缓存、不依赖工具；cpupower frequency-info --freq仅返回单核采样值，非全核快照；验证睿频需比对scaling_cur_freq与cpuinfo_max_freq，差值小于20MHz且有负载方可确认。
直接读 /sys/devices/system/cpu/cpu*/cpufreq/scaling_cur_freq 是最准的每核实时值
这个路径下每个 cpu0、cpu1 … 对应一个逻辑核心，scaling_cur_freq 文件内容就是它此刻的真实运行频率（单位 kHz）。它不走内核缓存，不依赖用户态工具，也不需要额外安装包。
实操建议：
- 先确认路径存在：
ls /sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq，若报No such file，说明 cpufreq 驱动未加载（查dmesg | grep -i "cpu.*freq"）或该核被隔离/离线（看cat /sys/devices/system/cpu/online） - 一次性查看全部核心：
cat /sys/devices/system/cpu/cpu*/cpufreq/scaling_cur_freq 2>/dev/null - 实时刷新监控：
watch -n 0.5 'cat /sys/devices/system/cpu/cpu*/cpufreq/scaling_cur_freq 2>/dev/null'，注意加2>/dev/null屏蔽错误输出 - 数值换算：比如输出
3400000就是 3.4 GHz；空值或0通常表示该核当前不可用或未启用调频
cpupower frequency-info --freq 返回的是单核“采样值”，不是全核快照
它确实比 /proc/cpuinfo 的 cpu MHz 更准——因为绕过缓存，直读硬件寄存器。但它只返回一个数值，且默认是当前调度策略下“主核”或“采样核”的频率，不代表所有核状态一致。
常见误判场景：
- 多核负载不均时（比如只有 cpu3 在跑编译），
cpupower frequency-info --freq可能显示 4.2 GHz，但其他核仍是 800 MHz，你却误以为整颗 CPU 都在满频 - 执行时没加
sudo，会报Permission denied；提示No such file则是驱动缺失 - 输出里带
(asserted by call to hardware)才可信；若只有数值没括号，可能是 fallback 到了缓存值
别信 /proc/cpuinfo 的 cpu MHz 字段做实时判断
它由内核周期性更新，有明显滞后。空载时可能还卡在上次高负载的值上，或者多个核心的值被合并成一个平均数（尤其在某些虚拟化环境里）。
linux-sysadmin
下载
Linux系统管理专家，覆盖12大模块：用户权限、SSH、存储、网络、systemd、防火墙、日志监控、备份恢复、TLS证书、Ansible、容器、IaC。提供配置、验证、加固、监控、备份、自动化、故障排查、回滚闭环。关键词：useradd、sudo、sshd_config、chmod、SEL...
正确用法仅限轻量粗略参考：
- 提取全部值：
awk '/^cpu MHz/ {print $4}' /proc/cpuinfo，再人工比对最大/最小值，能看出频率是否在浮动 - 绝对不要只取第一行：
grep "cpu MHz" /proc/cpuinfo | head -n 1，这会漏掉其他核的真实状态 - 它和
model name里的标称频率无关——后者是静态字符串，前者是动态瞬时值
想验证睿频是否真触发？比 scaling_cur_freq 和 cpuinfo_max_freq
睿频不是开关，是动态能力。关键看当前频率是否逼近硬件上限，而不是单纯看数字是否“够高”。
操作步骤：
- 查上限：
cat /sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_max_freq（比如4700000表示 4.7 GHz） - 查当前：
cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq（比如4680000） - 差值小于 20 MHz 且伴随负载（如
stress-ng --cpu 1 --timeout 5s），基本可确认睿频激活 - 若长期卡在
cpuinfo_max_freq以下，可能是温度墙（turbostat查Pkg_W和Temp_C）、功耗限制（RAPL），或 BIOS 关了 Turbo Boost
真正难的是多插槽系统里各 CPU 的 cpuinfo_max_freq 可能不同，而 cpupower monitor 这类工具又常受限于权限和内核配置——所以别只盯一个命令输出，交叉验证才是常态。
