3、链路降速现象定义
很多工程师一看到链路速率掉下来，第一反应就是“坏了，降速了”。其实没那么简单。你得先搞清楚：什么叫真正的降速？它和ASPM正常的节电行为有什么区别？我刚开始做PCIe调试时，就吃过这个亏——把正常的L1状态当成故障排查了好几天。
说白了，链路降速是性能不满足业务需求。你可以从三个维度去感知：带宽、延迟、吞吐量。下面我一个个说。
3.1 算“降速”的三种现象
- 带宽不足：链路协商出来的速率低于预期。比如Gen3 ×4的卡，实际跑在Gen2 ×2。这个最直接，
lspci -vvv一看就清楚。 - 延迟增大：端到端传输延迟明显变长。我用
perf测过，正常10μs的操作变成50μs，那肯定是哪儿卡住了。 - 吞吐量下降：实际有效数据速率达不到理论极限。比如NVMe SSD标称3.5GB/s，你测出来只有1.2GB/s。这往往是ASPM进入L1状态后，退出延迟吃掉了很多传输窗口。
这里有个坑：吞吐量下降不一定等于带宽不足。举个例子，Gen3 ×8的理论带宽是8GB/s，你跑4KB小包随机读，吞吐只有几百MB/s——这很正常，不是降速，是IO模式问题。真正的降速是在相似的负载下，数据速率比以前明显低了。
| 现象 | 典型表现 | 常用测量手段 |
|---|---|---|
| 带宽不足 | 协商速率/宽度降低 | lspci -vvv | grep Speed |
| 延迟增大 | Ping/IO延迟飙升 | perf stat、ftrace |
| 吞吐量下降 | 读写速率达不到规格 | fio、dd、iostat |
3.2 正常节电 vs 异常降速
ASPM的节电机制天生就会让链路降速——它会在空闲时主动切到低功耗状态。问题是，你怎么判断这个“降速”是正常的节电行为，还是出了问题？
我个人习惯用两个维度来判断：触发条件和持续时间。
- 正常节电：只在不传输数据时进入L0s/L1/L2。一旦有请求，立即退出，延迟在几微秒内。我测过，好的设计退出延迟不超过3μs。
- 异常降速：链路明明有流量，却退不回L0；或者退出的时间太长（几十上百微秒），导致数据卡住。还有一种情况：ASPM应该只在空闲时降速，结果它导致链路重协商，速率永久掉到低档——比如从Gen3掉到Gen1，再也升不回来。
一句话区分：正常节电是“瞬态降速、自动恢复”，异常降速是“持续降速、或恢复极慢”。你拿个逻辑分析仪抓一下LTSSM状态机，一眼就能看出区别。
3.3 实战判断方法
我在项目中遇到过一台服务器，跑分布式存储，网络吞吐死活上不去。一开始怀疑网卡，后来用ethtool -S看统计，发现ASPM进入L1的次数异常多，而且每次退出都要花20μs。这已经不是正常节电了——它连小包IO都受影响。
怎么系统地判断？我建议你按以下步骤来：
- 先确认链路协商状态：
lspci -vvv -s 01:00.0，看LnkSta和LnkCap。 - 检查ASPM当前策略：
cat /sys/module/pcie_aspm/parameters/policy，是powersave、performance还是default。 - 跑实际业务负载，同时抓
perf stat -e power:pstate或trace-cmd record -e pcie*。 - 看链路状态切换频率：如果空闲时降速没问题，但负载一上去还频繁进L1，那就不对了。
⚠ 特别注意：有些主板BIOS的ASPM策略是写死的，你改内核参数没用。我曾经遇到过一台机器，pcie_aspm=off都没生效——最后发现是BIOS的_POS固件强制启用了ASPM。遇到这种情况，只能找厂商要补丁。
你想想看，如果把这些信息画成决策流程，会清晰很多。下面这张图就是我在实际项目中总结的判断逻辑——帮你一眼分清正常节电和异常降速。
💡 小技巧：判断是不是ASPM导致的降速，最快的方法就是关掉它试试——echo "performance" > /sys/module/pcie_aspm/parameters/policy。如果性能恢复，那就是ASPM在捣鬼。但我建议你最后再这么做，因为生产环境改策略需要评估功耗和热设计。
总结一下，链路降速不可怕，可怕的是分不清正常节电和异常故障。记住三个核心指标：带宽、延迟、吞吐量。再结合空闲/非空闲的触发条件，你就能快速定位问题。我自己的经验是：先看lspci确认链路状态，再看ASPM策略，最后用perf或ftrace抓状态切换——三步走，基本不会跑偏。