状态栏点了性能模式，CPU 却没什么感觉
状态栏图标好用，点一下就能在省电 / 均衡 / 性能之间切换，power-profiles-daemon 也正常响应。但主观体感上，”性能模式”跑起来跟没切一样——负载稍微重一点，风扇没怎么转起来，机器也不怎么发热，任务完成速度也没有想象中利索。
通常是这几个：
- EPP（能量性能偏好）没拉满，驱动偷懒用了保守策略
- 功耗墙（PL1/PL2）被厂商锁得太死
- 温度墙触发得太早
- 内核调度器不给力
于是排查就是照着这几个一个个去查、去排除的过程。
第一轮：查静态配置，全部正常
先上 turbostat 把 CPU 的寄存器全部倒出来看：
cpu0: MSR_HWP_REQUEST: 0x00002404 (min 4 max 36 des 0 epp 0x0 window 0x0 pkg 0x0)epp 0x0 就是 performance，已经是拉满状态，不是它的锅。
intel-rapl:0: package-0 28.0s:30W,max:15W 2.4ms:50W
PKG Limit #1: 30.000 Watts, 28s, clamp ENabled
PKG Limit #2: 50.000 Watts, 0.002441s
MSR_IA32_TEMPERATURE_TARGET: 93 C功耗墙：长期 30W（标称 15W 芯片的两倍），短时冲到 50W，温度墙 93°C。数字看起来没有被锁死，理论上应该能跑得很暴力才对。
继续查 cpufreq、governor、ACPI 平台档位、有没有 TLP 之类的电源管理软件互相打架：
bash
cat /sys/devices/system/cpu/intel_pstate/max_perf_pct # 100
cat /sys/devices/system/cpu/intel_pstate/no_turbo # 0
cat /sys/firmware/acpi/platform_profile # performance清一色全部”全开”状态。dmesg 里搜 thermal|throttl|prochot 也没有任何降频记录。
到这一步，操作系统能暴露出来的每一层开关都查了个遍，全部正常。 这其实是排查里最容易卡住的阶段——所有你能想到、能查到的地方都没问题，但症状确实存在。
第二轮：不看静态配置，直接上真实满载测试
静态寄存器只是”承诺值”，不代表运行时真实生效的值。于是不再看 dump，直接拿 stress-ng 打满 8 线程，用 turbostat 逐秒记录：
bash
sudo stress-ng --cpu 8 --timeout 30 &
sudo turbostat --interval 1 --show PkgWatt,Bzy_MHz,PkgTmp > /tmp/turbo_log.txt &
wait结果是全次排查里最关键的一份数据：
| 时间 | 频率 | 功耗 | 温度 |
|---|---|---|---|
| 0-7秒 | 3300MHz | 30-34W | 74-85°C |
| ~8秒 | 跳水 | 跳水 | — |
| 9-30秒 | 死死钉在 2000-2100MHz | 14-16W | 稳定 64-66°C |
CPU 前 7 秒确实全力冲刺，睿频拉满、功耗摸到 30W+，证明硬件本身完全没问题。但 8 秒左右，毫无征兆地直接腰斩到 2.1GHz，此后 20 多秒像焊死了一样纹丝不动。
这里有两个反常的地方，直接排除了”正常触顶”的可能：
- 温度还有大把余量——腰斩后温度降到 64°C，离 93°C 的墙还差 29 度，不是热到降频；
- 功耗远低于承诺的 30W——腰斩后功耗只有 15W 左右，而这个数字恰好精确等于芯片的出厂标称 TDP，不是 MSR 里写的 30W。
正常的功耗墙触发，应该是频率和功耗围绕着上限反复试探、有起伏波动；而这里是一条从满血直接切到低速的硬边界，切下去之后完全不带任何试探——这不是驱动在”算”出来的降频，更像是有个东西直接、粗暴地把上限从外部重新写了一遍。
定位：EC 固件绕过标准寄存器
dmesg 里有一行之前一直被忽略的信息：
PCI: Lenovo *IIL* product version detected这就是关键线索。Lenovo 笔记本的 EC（嵌入式控制器）固件有个业内皆知的行为：它不走操作系统能看到的标准 RAPL MSR 通道，而是通过独立的私有接口，周期性地重新把功耗上限压回自己认定的保守值，完全不理会 BIOS 在 MSR 里写的那个更宽松的数字。这也正是为什么 Windows 下这颗芯片能跑得很猛——Lenovo Vantage 会一直在后台跟 EC “谈判”、反复喂给它更高的功耗请求；而 Linux 下没有对应的用户态程序去做这件事，EC 就会在几秒钟的空窗期后按自己默认的保守逻辑接管，把功耗砍回标称 TDP。
顺带一提，这也是为什么早年那个专门对付这个问题的开源工具，叫 lenovo_fix——它不是什么”额外的性能解锁”，从名字就能看出来，它的定位就是去对抗这个隐藏的限制，而不是常规意义上的超频工具。
解决方法：用更快的轮询节奏抢在 EC 前面
思路很直接：既然 EC 是周期性重写寄存器，那就用一个用户态服务，以比它更高的频率反过来重写回去，抢在它介入之前把想要的值摁住。
bash
sudo pacman -S throttled
sudo systemctl enable --now throttled.service配置基于实测数据来定，而不是抄网上现成的桌面级数字（这颗芯片是 15W 标称的轻薄本 U 系列，套用桌面级的 65W/90W 配置只会导致过流保护甚至硬件损伤）：
ini
[GENERAL]
Enabled: True
Poll_Interval: 3000
[BATTERY]
Update_Rate_s: 30
PL1_Tdp_W: 15
PL1_Duration_s: 28
PL2_Tdp_W: 25
PL2_Duration_s: 0.002
Trip_Temp_C: 85
[AC]
Update_Rate_s: 3
PL1_Tdp_W: 28
PL1_Duration_s: 28
PL2_Tdp_W: 45
PL2_Duration_s: 0.01
Trip_Temp_C: 88Poll_Interval: 3000（3秒轮询）是关键——比之前实测到的 EC 大约 7-8 秒才介入一次的节奏更快，理论上能在 EC 出手之前反复把功耗值重新钉住。
效果验证
装完之后重新跑了一次同样时长的满载测试，结果对比：
| 装 throttled 之前 | 装 throttled 之后 | |
|---|---|---|
| 8秒后频率 | 跳水到 2100MHz | 全程稳定 3300MHz |
| 功耗 | 跳水到 15W | 稳定 30-36W |
| 30秒内跳水次数 | 持续被压制 | 零次 |
| 温度 | 卡在 64°C | 自然爬升到 88°C 触及设定墙 |
风扇转起来了，机身也热起来了——这是好事，说明 CPU 终于是在真的燃烧，而不是被闷在低速状态下”假装”在跑。最后几秒温度摸到设定的 88°C 墙时，系统还能做出正常的边界内微调（3300→3294→3290→3284），说明整套配置是在正常工作，不是粗暴一刀切。
吐槽
折腾了小十轮 turbostat，从怀疑 EPP、怀疑 governor、怀疑温度墙、怀疑电池模式，一路排除嫌疑人排除到最后，发现真凶是笔记本自己的固件在演戏——Windows 下靠 Lenovo Vantage 一直喂着它才显得”很正常”，换个系统它就原形毕露，摆明了是”没人管我就摆烂”的架势。
这软件的开源作者当年取名 lenovo_fix，属实是相当克制了；用户群里但凡用过这玩意儿排查过同款问题的，大概都会打心底里觉得，这名字应该叫 lenovo_fuck 才更贴切——不过话说回来，Dell、HP、华硕家的 EC 也不是什么省油的灯，只是 Lenovo 用户基数大、社区声量大，第一个把这坑填出来给全世界抄作业罢了。东西能用就行
