Linux启用HWP：intel_pstate驱动与EPP调优实战

做内核调优和服务器性能这块的人应该都绕不开intel_pstate驱动的争议。早年 Linux 发行版对 Intel 新一代处理器的支持总是慢半拍SSD 都快成标配了CPU 频率管理还停留在OS 说了算的老思路上。直到 HWPHardware Pstate硬件P状态控制被 Linux 内核正式支持频率调谐的大权才真正交还给了 CPU 自己。今天这篇就专门讲讲 14.4.2 节里提到的 Enabling HWP也就是怎么在你的 Linux 机器上把 HWP 这个硬件特性真正用起来。这个内容适合谁一类是跑数据库、科学计算这类对延迟和吞吐都极为敏感的服务端开发者HWP 能带来更敏捷的频率响应和更低的功耗开销另一类是搞嵌入式、边缘计算、笔记本功耗调优的工程师想榨干手上那台低功耗 CPU 的最后一滴性能。如果你只是想给自己的桌面 Linux 折腾一下那这篇文章同样适用。我会把原理、检查方法、启用步骤、调优参数以及我在多台机器上踩过的坑一次性讲透。1. 内容整体设计与思路拆解1.1 HWP 到底是什么先厘清两个概念要聊启用 HWP必须先搞清楚两个容易混淆的概念P-StatePerformance State和 HWP。P-State传统上指 CPU 运行时的电压频率组合点。比如一颗 3.0GHz 的 CPU可能有 2.5GHz、2.0GHz、1.5GHz 等多个 P-State。操作系统通过往 CPU 写 MSRModel Specific Register模型特定寄存器来请求某个 P-State这就是经典的 DVFSDynamic Voltage and Frequency Scaling动态电压频率调整。HWP全称 Hardware P-State硬件P状态Intel 从第 6 代酷睿Skylake开始引入的技术在代号为 Speed Shift 的功能中作为核心机制。启用 HWP 之后CPU 内部有一个硬件控制逻辑可以基于实时负载、温度、功耗余量自己决定跑在哪个 P-State不需要操作系统逐个发指令去切。一句话概括区别传统模式是OS 写 MSR 请求频率HWP 模式是OS 设定频率范围硬件在范围内自主决策。这个区别关乎启用方式也直接决定了后面你看到的 sysfs 属性为什么会和旧内核不一样。1.2 为什么要启用 HWP它和旧机制比到底强在哪你可能觉得传统 DVFS 不是也能工作吗Linux 内核的schedutil、ondemand等调频器不是也挺成熟我也理解这种想法但实际跑过之后会发现HWP 的优势确实体现在几个硬指标上响应更快传统调频是负载变化 → 内核计算 → 写 MSR → 硬件切频这个完整链路的延迟大概在几毫秒到几十毫秒级别。HWP 的硬件控制器采样负载的周期可以达到微秒级尤其适合突发型负载。比如 Web 服务短连接高并发场景HWP 能让 CPU 瞬间冲上高频率而不是等内核调度器反应过来才慢慢拉频。能效更优HWP 硬件逻辑能看到更细粒度的指令流信息和热功耗传感器数据它在决定升频/降频时可以实时参考当前的散热余量和功耗预算这比 OS 端只知道负载这一个维度的调频算法要聪明得多。大幅减少内核开销启用 HWP 后Ondemand、Conservative 这类传统调频器直接被绕过内核的频率管理代码路径变得非常短。在高频中断的机器上能省下不少 CPU 周期网络转发类的应用感受最明显。说白了启用 HWP 不是换个参数看个新鲜而是真正把频率控制从软件轮询猜升级成硬件实时算。这也是 Intel 多年来一直在推进的架构方向。1.3 前提条件你的 CPU 和 BIOS 支持吗HWP 不是装个新版内核就能直接用的必须满足三层条件CPU 层Intel 6 代酷睿Skylake及更新的处理器基本都支持 HWP。桌面端、移动端、至强 Scalable 系列都带。AMD 那边对应的是 CPPC2Collaborative Power and Performance Control机制不同不在本文讨论范围。可以通过grep -E hwp|HWP /proc/cpuinfo来查看 CPU flags如果看到hwp字样说明 CPU 硬件层支持。BIOS/UEFI 层有些机器需要在 BIOS 里开启 Intel Speed Shift Technology 选项注意它和 Intel SpeedStepEIST是两回事。SpeedStep 是老的频率调节技术Speed Shift 才是 HWP 对应的硬件自主调频。出厂默认不一定开启尤其是一些服务器主板。进不去系统检查不了 BIOS 选项的话可以先看/sys/devices/system/cpu/cpufreq/下面是否有可用的 HWP 相关属性。内核驱动层Linux 内核里由intel_pstate驱动负责 HWP 的初始化和 sysfs 接口暴露。intel_pstate在大部分发行版中默认启用但可能工作在不同的模式后面马上讲。此外BIOS 和内核 ACPI 表的交互会有一些坑后面问题排查小节里我会专门说。这三层缺一不可。我经常看到有人买了支持 HWP 的 CPU结果 BIOS 里默认关着 Speed Shift 功能或者内核用的是老的acpi-cpufreq驱动导致 HWP 一直没被激活——这个时候启用就没有任何效果必须逐层排查。2. 检查现状你的 HWP 到底开没开2.1 快速判断当前状态别再瞎猜不少老手会直接说我加了intel_pstateenable内核参数但 HWP 的启用与否并不是一个参数能完整决定的。我建议到家先看这几个文件# 查看当前使用的 cpufreq 驱动 cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_driver # 查看驱动支持的模式以及当前状态 cat /sys/devices/system/cpu/cpufreq/policy0/status # 查看当前频率范围 cat /sys/devices/system/cpu/cpufreq/policy0/scaling_governor cat /sys/devices/system/cpu/cpufreq/policy0/scaling_max_freq其中关键输出scaling_driver应该是intel_pstate而不是acpi-cpufreq。status这个文件比较特殊只有较新的内核在 HWP 模式下才存在。如果看到status内容为off说明驱动虽然是 intel_pstate但没有处于 HWP 模式如果是active恭喜已经启用。如果scaling_driver显示acpi-cpufreq那基本可以确定 HWP 未参与调频工作内核在用经典 ACPI 方式管理 P-State。2.2 进一步用系统日志和你手里的真实数据进行确认看 sysfs 还不够我建议同时用以下几种方式交叉验证# 查看内核启动日志中 intel_pstate 驱动的初始化信息 dmesg | grep -i intel_pstate # 查看 CPU 报告的最高频率和当前频率 lscpu | grep -E Model name|CPU max MHz|CPU min MHz|CPU MHz在启动日志里HWP 启用状态会有一句关键提示例如intel_pstate: Intel P-state driver initializing intel_pstate: HWP enabled如果你看到的是intel_pstate: HWP not supported或者intel_pstate: HWP disabled就需要怀疑是 BIOS 层没开启 Speed Shift或者 CPU 太老、型号太偏。还有一种更硬核的验证办法直接读 MSR需要 root 权限。HWP 的开关标志位在IA32_PM_ENABLEMSR地址 0x770的第 0 位置 1 表示 HWP 已开启# 前提装了 msr-tools sudo modprobe msr sudo rdmsr 0x770输出如果是1那就是板上钉钉的已启用。这种验证方法我一般只在对 HWP 状态存疑、且 sysfs 输出不太直观的情况下才用。2.3 HWP 的两种模式Passive 和 Active到底怎么理解intel_pstate 驱动还有两种工作模式这一点经常把人绕晕Active 模式主动模式驱动直接把调频决策权完全交给硬件内核不干预。HWP 开启时scaling_governor会被设定为非标准的powersave或performance但内核实际的调频操作只是设置一个频率范围真正的频率切换由 CPU 硬件自主完成。我们说的启用 HWP指的就是让驱动进入 active 模式。Passive 模式被动模式即便 HWP 可用内核也可以退回到类似acpi-cpufreq的方式由操作系统请求具体频率硬件仅执行。这通常出现在为兼容某些老工具链或安全策略而主动绕开 HWP 的配置里。此时scaling_driver仍显示 intel_pstate但status为off。所以简单记住HWP 启用 intel_pstate 驱动 hardware_mode/active 状态而不是只靠新增一个内核参数。3. 实操过程与核心环节实现3.1 实操路径总览BIOS、内核参数、sysfs 这样配合现实中启用 HWP 的完整路径是这么一条线开启 BIOS/UEFI 里的 Intel Speed Shift Technology 选项。确认内核将 intel_pstate 设为 active 模式一般默认但有的发行版会被设置成 passive。确认内核版本和工具链足够新推荐 5.7越新越好。重启系统验证 sysfs 状态。按需调整 EPPEnergy Performance Preference能耗性能偏好参数让 HWP 更偏性能或更偏节能。别小看第一条。很多品牌机 BIOS 默认关闭 Speed Shift尤其是主打静音和低功耗的办公机型会默认把 HWP 作为隐藏开关藏在高级电源管理下名字还不一定带 Intel。如果第一层就没打开后面怎么折腾内核参数都是白搭。3.2 在 BIOS/UEFI 层面开启 Speed Shift步骤要看清具体路径因主板厂商和 BIOS 版本而异我给一个比较通用的查找思路进入 BIOS 设置开机时按 Del 或 F2部分品牌机是 F12 或 Esc。找到Advanced / CPU Configuration / Power Performance之类的菜单。寻找带有Speed Shift或HWP字样的选项例如 Intel Speed Shift Technology部分新 BIOS 也叫 Hardware P-State。设为Enabled。保存重启。有些笔记本 BIOS 默认锁定该选项不让你改。这种时候可以试试更新 BIOS 版本后是否开放解锁或者用 Windows 下的 Intel XTU 工具开启后重启进入 Linux。这算是一个不算优雅但实测可行的变通方案。3.3 通过内核参数强制启用 HWPBIOS 开好之后Linux 侧需要确认或者强制启用。比较稳定的做法是在 GRUB 内核参数里加一行sudo vim /etc/default/grub在GRUB_CMDLINE_LINUX_DEFAULT中追加intel_pstateactive有的内核老一点也支持intel_pstateenable但 newer 内核逐步统一为active。改完后更新 GRUBDebian/Ubuntusudo update-grubRHEL/CentOS/Fedora/Rockysudo grub2-mkconfig -o /boot/grub2/grub.cfg然后重启进入系统后cat /sys/devices/system/cpu/cpufreq/policy0/status如果显示active恭喜 HWP 已经被激活。3.4 相关内核参数对比别再被网上老教程误导这里我把内核侧常见的参数挨个分析一下参数语义效果intel_pstateactive强制以 active 模式运行驱动开启 HWP 控制路径intel_pstatepassive强制以 passive 模式运行不使用 HWP退化为传统请求式调频intel_pstatedisable禁用 intel_pstate 驱动回退到 acpi-cpufreq一般没必要intel_pstateno_hwp单独禁止 HWP但保留主动调频在早期内核中用于关闭让内核自主调频的功能新版内核此参数可能已不再支持processor.max_cstate1限制 CPU 进入深度睡眠状态影响功耗/延迟不影响 HWP 是否启用特别注意网上不少文章把intel_pstateenable当作启用 HWP的万能钥匙其实在某些内核版本里这个参数只是启用驱动HWP 的 final 判定还是取决于 CPU support 和 BIOS 开关。还有更老的文章会建议你关闭 HWP 来避免性能波动那是因为早期内核 HWP 调优接口不完善EPP 默认值偏省电和现代内核的情况完全不一样别照搬。3.5 验证已启用别只看一个文件启用后最直观的表现除了status为active还有scaling_driver是intel_pstatescaling_governor通常是powersave或performance/sys/devices/system/cpu/cpufreq/policy*/energy_performance_preference文件存在dmesg | grep -i hwp能看到 HWP enabled 信息我自己的测试机上启用后/sys/devices/system/cpu/cpufreq/policy0/energy_performance_preference默认值是balance_performance这意味着 CPU 会倾向在不牺牲太多性能的前提下省电。验证阶段最好用一个单线程负载来看实际频率冲高速度# 单核打满 taskset -c 0 yes /dev/null # 观察核心0频率 cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq实测 HWP 模式下这个值会非常快地接近最高频率而传统模式可能会有阶梯式的延迟感。3.6 HWP 模式下的调频器相互作用启用 HWP 后scaling_governor的角色变得非常弱它只是规定了频率上下限的语义powersave允许硬件自主选择最优频率倾向于在满足负载下尽量低功率但它不等于锁低频在负载上来时同样会拉满频率。performance将频率下限也提到最高值附近让硬件只能在很高频率附近做小范围波动。这种设置会导致功耗偏高适合对延迟极其敏感、且散热充足的场景。这里是个容易踩的坑很多人看到 HWP 开启后 governor 为 powersave就以为 CPU 被锁频了或者被省电策略限制住其实完全不是。HWP 开启后powersave 和性能模式的差别可以理解为 硬件在多大范围内自主浮动而不是传统意义上的中低频运行。4. HWP 的调优实践EPP 才是关键4.1 EPP 和 EBF 是什么怎么选择HWP 开启后最值得调的一个参数就是EPPEnergy Performance Preference能耗性能偏好。它是一个 8 位的值用来告诉 CPU 硬件0x00即 0极致性能0x40即 64期望性能0x80即 128性能与能效平衡0xBF即 191偏向能效0xFF即 255极致节能Linux 内核把它映射成了字符串形式在 sysfs 中读出来往往是performance balance_performance balance_power power查看和设置命令# 查看 cat /sys/devices/system/cpu/cpufreq/policy*/energy_performance_preference # 设置以 balance_performance 为例 sudo sh -c echo balance_performance /sys/devices/system/cpu/cpufreq/policy0/energy_performance_preference如果你想一次性应用到所有 CPU用循环for p in /sys/devices/system/cpu/cpufreq/policy*; do echo performance | sudo tee $p/energy_performance_preference done我个人的经验是数据库、高频交易类应用设performance云主机、桌面日常、移动端设balance_performance。balance_power只适合 tasks 很稀疏且对响应延迟不敏感的设备比如远程传感器网关或电池供电的边缘盒子。太偏节能会让交互式应用的开机加载、点击响应出现肉眼可见的迟滞。4.2 是否要调整energy_performance_biasenergy_performance_biasEPB是另一个老接口在部分系统里也会出现容易和 EPP 搞混。简单说EPB 是 HWP 出现之前通过 MSR 影响硬件决策的接口。EPP 是 HWP 时代的接口。在支持 HWP 的 CPU 上调整energy_performance_preference更直接有效。有些内核里二者会联动但如果你发现改 EPB 对频率响应没有明显影响不要惊讶这正是 HWP 生效的表现之一说明实际决策权已经移交硬件。4.3 与tuned、TLP这类工具怎么共存很多服务器发行版会默认装tuned笔记本用户会装TLP。这些工具会主动修改 CPU 调频参数包括 EPP如果不了解它们的优先级你手动写入的 EPP 可能在一分钟之内就被覆盖掉。检查tuned当前配置tuned-adm active tuned-adm recommend如果你用tuned且希望自定义 EPP最好在/etc/tuned/下新建一个 profile加入energy_performance_preferenceperformance然后tuned-adm profile custom。如果你用 TLP注意配置文件里的CPU_ENERGY_PERF_POLICY_ON_BAT和CPU_ENERGY_PERF_POLICY_ON_AC这两行把它改成你想要的策略或者改成0让系统默认。这里常见的一个操作误区是配置了 tuned但忘了重载手动 echo 的值又会被 tuned 定时任务覆盖出现明明设了 performance一看又变回 balance_performance的怪问题。先跑一下tuned-adm active看看有没有活动 profile很多玄学性能问题都是这个原因。4.4 如何衡量 HWP 的实际收益启用 HWP 之后怎么科学地验证值不值我最常用的方法是用perf stat或者time对比跑同一段负载测试脚本示例纯计算型#!/bin/bash # 计算1到5千万的和模拟负载 for i in $(seq 1 50000000); do sum$((sum i)) done echo $sum在启用 HWP 前后各跑一次观察 elapsed time 和数据中心里的 CPU 总体功耗。如果机器支持 turbostat也可以用sudo turbostat --quiet --show Core,CPU,Busy%,Bzy_MHz,PkgWatt,RAMWatt bench.sh我某台 8 核虚拟机宿主上启用 HWP 后同样的编译任务耗时降低了约 6%整机功耗反而降了 5% 左右。类似的效果在短视频转码、GCC 编译这类多线程突发负载上比较容易复现。注意如果你的负载一直是满负荷跑HWP 优势不会太明显因为 CPU 本来就在最高频附近HWP 的优势场景是负载有波动、有空闲的情况。5. 常见问题与排查技巧实录5.1 HWP 明明开了但scaling_governor没有变化这种情况我在不少新装机用户里见过。检查完status为active但scaling_governor还是schedutil或其他传统调频器。原因部分发行版在intel_pstate进入 active 模式后不强制接管 governor 名称或者 systemd 服务的cpupower又在启动时手动设置了别的 governor。解决先看当前 HWP 是否真的 activecat /sys/devices/system/cpu/cpufreq/policy0/status cat /sys/devices/system/cpu/cpufreq/policy0/scaling_governor如果是 schedutil 字样直接用 cpupower 设置sudo cpupower frequency-set -g powersave或者写入持久化配置/etc/default/cpupower设置governorpowersave。实际遇到的问题HWP 开启后如果 governor 显示为 schedutil可能意味着内核并未完全切换到 active 模式某些软硬件组合下 intel_pstate 对 governor 的接管并不彻底。此时建议直接使用cpupower把它切走。5.2 开机后 HWP 是关的BIOS 也已开启但还是不行如果dmesg | grep intel_pstate显示intel_pstate: HWP not supported但 CPU 型号明明支持优先级最高的怀疑对象是CPU 微码microcode太旧。某些早期 Skylake / Kaby Lake 处理器需要更新微码才能正确暴露 HWP 功能。尤其在老主板上用新 CPU这是很常见的坑。解决路径安装intel-microcodeDebian/Ubuntu或linux-firmware/microcode_ctlRHEL 系更新后重启如果发行版仓库里的微码版本还不够新去 Intel 官方下载最新的微码更新配合 initramfs 加载。另一个冷门但实际存在的原因是BIOS 启动模式是 CSM 而不是 UEFI。在这种状态下的 ACPI 表传递经常有问题导致 intel_pstate 接收不到完整的 HWP 能力枚举。切换为 UEFI 引导并禁用 CSM 兼容模式后HWP 往往就正常了。5.3 HWP 和 CPU 热插拔、云宿主的兼容问题在有 CPU hotplug热插拔场景的机器上HWP 的恢复有点不稳。比如在离线某颗 CPU 后再上线HWP 状态有时候不会自动重新初始化导致该 CPU 频率控制异常。如果工作负载会做 CPU hotplug建议保留一个 policy 专门给动态上线的 CPU 重新设置 EPP。云主机、虚拟机环境下更特殊如果宿主机把 HWP 透传给了虚拟机虚机里可能能看到 HWP 的 sysfs 接口但实际频率调节受宿主机限制很大调了也未必生效。所以不要在云服务器上折腾 HWP省点时间。5.4 快速排查问题速查表现象可能原因解决方案scaling_driver为 acpi-cpufreqBIOS 未开启 Speed Shift、内核参数禁用开启 BIOS 选项添加intel_pstateactivestatus为 off当前是 passive 模式添加内核参数intel_pstateactivedmesg报 HWP not supported微码过旧、CPU 太老、CSM 兼容模式更新微码切换到 UEFIEPP 文件不存在内核太老或 BIOS 未开启 Speed Shift内核升级至 4.10开启 BIOS设置了 EPP但很快被还原tuned/TLP 在覆盖检查并调整 tuned/TLP 配置云主机里看不见 HWP active虚拟化透传限制不要在VM里折腾宿主上控制启用 HWP 后性能反而下降默认 EPP 偏省电将 EPP 设为 balance_performance 或 performance5.5 一个特殊的重启后恢复问题系统重启后手动设置的 EPP 会恢复默认。这一点和 BIOS 设置不同Linux sysfs 中的配置默认不持久化。如果你希望固定 EPP 为performance建议写一个 systemd service或者把配置放进/etc/tuned/中自定义 profile一个简单的 systemd unit 示例保存为/etc/systemd/system/hwp-epp.service[Unit] DescriptionSet HWP EPP to performance Aftermulti-user.target [Service] Typeoneshot ExecStart/bin/sh -c for p in /sys/devices/system/cpu/cpufreq/policy*; do echo performance $p/energy_performance_preference; done [Install] WantedBymulti-user.target然后启用sudo systemctl daemon-reload sudo systemctl enable --now hwp-epp.service如果你是用 TLP 的其实直接在配置里改CPU_ENERGY_PERF_POLICY_ON_ACperformance就能达到同样效果更省事。我自己的服务器因为不装 TLP所以直接走 systemd service 这条路干净、没有多余依赖、随时可以手动停用。第一次手动在 sysfs 里 echo performance 到所有 policy 时我犯了个小错误直接用通配符echo performance /sys/devices/system/cpu/cpufreq/policy*/energy_performance_preferencebash 会把通配符展开成多个路径但echo的重定向只能指向一个文件导致报错。正确写法是用 for 循环或者tee。这也是新手最容易碰到的一个 shell 问题写进 service 和手动测试的时候都要留意。5.6 与其它调频工具的联动很多发行版现在默认启用了power-profiles-daemon它提供Power Saver / Balanced / Performance三个电源档位。这个 daemon 实际上会操作energy_performance_preference。如果你在用 GNOME 之类的桌面环境改了performance之后切一下电源模式可能就被重置。如果你希望自己的自定义配置始终生效最好把 power-profiles-daemon 停掉或屏蔽sudo systemctl stop power-profiles-daemon sudo systemctl disable power-profiles-daemon当然这会让笔记本在电池/插电模式之间的自动切换失效我的个人建议是台式机和服务器直接关笔记本可以留着但记得随时手动调 EPP。这种调优工作的本质就是权衡搞清楚谁在背后改你参数、谁的优先级更高比你每次手动敲命令要有用得多。6. 补充结合 14.4.2 章节的上下文HWP 在多核场景下的行为6.1 每个 CPU 核心的 policy 独立性Linux 处理 HWP 时不是把整颗 CPU 当作一个整体而是每个 CPU 核心更准确地说是每个 scheduling domain都会有一个独立的policy*目录。这意味着你可以对不同核心设置不同的 EPP 值。不过实践中大多数场景没必要做这种细粒度区分。只有在混合负载的机器上比如某些核心专门跑低延迟网络中断处理、另一些核心跑批处理任务才值得考虑给不同核心设置不同的性能偏好。我做过类似的事情。当时那台机器同时跑着 DPDK 转发线程和 Spark 任务网络转发核心延迟一直抖动严重后来把前四个核心的 EPP 设为performance剩下的核保持balance_performance抖动直接降了下来。值得注意的是DPDK 轮询本身几乎不触发传统调频器的调度但 HWP 的硬件决策依然生效所以这个 set 才会这么有效。6.2 多路处理器双 CPU下的注意事项双路至强平台上HWP 的启用路径基本一致。要注意的是不同 CPU 型号混合的机器比如先用一颗老至强、后来又插了一颗不同步进的 CPUHWP 的能力枚举可能不一致内核可能直接全部关闭 HWP 来保持一致性。这种时候只能保证 BIOS 里把两路 CPU 的 Speed Shift 全部开启并且在没钱换同规格 CPU 的情况下别对 HWP 抱太大期待。6.3 如何验证多核心频率是否真的各自独立可以用turbostat直接观察每一颗核心的实时频率sudo turbostat --quiet --show Core,CPU,Busy%,Bzy_MHz,PkgWatt sleep 10如果 HWP 生效你会发现某个核心在跑单线程负载时能单独冲到最高频率其他核心则保持较低频率这正是硬件调频细粒度的体现。7. 写在最后的实操经验总结我的经验是启用 HWP 之后千万别急于下结论性能一定变好。适度调整 EPP 通常比追某一段性能数字更有价值。你要先明确自己的场景到底需要什么如果是交互式终端、开发者本机偏向性能如果是大型分布式集群中的 worker追求吞吐和功耗比balance_performance会是个不错的起点如果是完全空闲占多数的服务balance_power能帮你省点电费但代价是冷启动响应变慢。另外调试 HWP 一定不要光看 sysfs 里的一个文件。把status、scaling_driver、dmesg、turbostat四个维度的输出结合起来看才不会被某个中间层的旧配置误导。遇到频率异常上不去的情况首先要检查的是有没有热功耗限制thermal throttle这个锅经常会甩到 HWP 头上但本质上和 HWP 关系不大。我在多台机器上调过 HWP从笔记本到双路服务器都试过。坦率地讲如果你只是日常用HWP 带来的差异不会特别夸张但它省掉的内核调频开销、以及突发负载下的响应速度提升是非常实在的。希望这篇把原理和实操剥开揉碎之后你能少走一些弯路。还有一个小技巧调完 EPP 之后用watch -n0.5 cat /sys/devices/system/cpu/cpufreq/policy*/scaling_cur_freq看着频率动态变化你会对 HWP 的行为特点有更直观的感觉。