云主机cpu是否具有睿频能力？可通过比较scaling_cur_freq与cpuinfo_max_freq判断：若前者接近或等于后者且系统有负载，即确认睿频已激活；turbostat可进一步验证核心实际频率是否超硬件标称上限。
怎么看当前 CPU 主频是不是睿频状态
直接看 scaling_cur_freq 和 cpuinfo_max_freq 的关系最可靠。前者是实时频率（单位 kHz），后者是硬件支持的最高频率（也单位 kHz），如果前者接近甚至等于后者，且系统有负载，大概率就是睿频生效了。
常见错误是只看 lscpu 输出里的 CPU MHz 字段——它可能来自某个核心的瞬时采样，也可能被内核缓存，不反映真实波动；而 cpupower frequency-info 里显示的 “current frequency” 更准，但仍是策略级平均值。
-
cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq：读取 cpu0 当前频率（如3200000表示 3.2 GHz） -
cat /sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_max_freq：读取 cpu0 硬件上限（如4700000表示 4.7 GHz） - 差值小于 100 MHz 且
watch -n 0.5 'cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq'持续跳变，基本可确认睿频活跃
用 turbostat 看清睿频是否真启用
turbostat 是唯一能区分“标称最大频率”和“实际睿频倍频”的工具，尤其对 Intel CPU。它会显示每个核心的 GHz、Turbo 标志、Busy% 和 Pkg% C0，比所有其他命令都底层。
容易踩的坑：没加 sudo 时部分字段为空；非 Intel 平台（如 AMD）输出意义有限；虚拟机里通常禁用 MSR 访问，turbostat 会报错 no permission to read MSR。
- 安装：
sudo apt install linux-tools-generic（Ubuntu/Debian）或sudo yum install kernel-tools（RHEL/CentOS） - 运行：
sudo turbostat --interval 1，重点关注Core MHz列是否超过cpuinfo_max_freq / 1000（比如 max 是 4700 MHz，但 Core MHz 显示 4900，说明睿频超出了基频上限） - 若
Turbo列全为-，检查 BIOS 是否关闭了 Turbo Boost，或内核启动参数含intel_idle.max_cstate=1类限制
performance 模式不等于满频，但能放开睿频门限
Linux 的 performance 调频策略不会让 CPU 一直跑在最高频，而是把频率下限拉到 cpuinfo_max_freq，允许调度器在负载来时立刻升频，不等待阈值判断——这正是触发睿频的关键前提。
对比 ondemand：后者需要 CPU 使用率连续几秒 >95% 才升频，期间可能错过短突发负载；而 performance 下，哪怕一个 10ms 的 syscall 都可能触发睿频响应。
- 临时切换：
sudo cpupower frequency-set -g performance - 验证是否生效：
cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor应返回performance - 注意：该设置不跨重启；若用 systemd，需写
/etc/systemd/system/cpupower.service持久化，否则重启后回落为默认的ondemand或powersave
/sys/devices/system/cpu/ 下三个关键文件的区别
很多人混淆 cpuinfo_max_freq、scaling_max_freq 和 scaling_cur_freq，结果误判睿频能力。它们根本不在同一维度：
-
cpuinfo_max_freq：只读，硬件固件写死的上限（如 4700000），不可改，代表 CPU 芯片能力 -
scaling_max_freq：可写，软件层设置的策略上限（默认同cpuinfo_max_freq），echo 3500000 | sudo tee /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq会硬性封顶，即使睿频可达 4700 MHz 也上不去 -
scaling_cur_freq：只读，当前真实运行频率，唯一能反映睿频是否起效的动态指标
真正影响睿频发挥的，其实是 scaling_max_freq 是否被人为压低，以及 governor 是否允许快速响应——这两点比查型号参数更关键。
