第4章 链路降速现象：降速表现与常见触发场景
做ASPM调优这些年，最头疼的不是配置不会写，而是链路降了速你还浑然不觉。系统运行着，业务跑着，莫名其妙的卡顿就来了。你想想看，明明配了PCIe Gen4，结果设备只在Gen1上跑，这性能差距可不是一星半点。
我在一线排查过不少这类问题，说实话，大部分情况不是因为硬件坏了，而是触发场景没搞明白。这一章，咱们就专门聊聊链路降速到底是什么样的表现，以及在什么情况下最容易触发。
4.1 降速后的具体表现
链路降速不是只有一种表现。我个人习惯先看三种典型现象，然后根据现象反过来定位原因。
| 现象类别 | 典型特征 | 用户感知 |
|---|---|---|
| 吞吐量骤降 | NVMe顺序读写掉到几百MB/s | 文件拷贝、数据库写入明显变慢 |
| 延迟抖动 | 网络ping延迟从0.2ms跳到5ms+ | 视频会议卡顿、交易系统超时 |
| 连接不稳定 | dmesg中反复出现"PCIe link retrain" | 设备间歇性丢失，需要重启恢复 |
吞吐量骤降是最好发现的。比如你用fio测NVMe盘，本来能跑到3.5GB/s，结果只有不到1GB/s。这时候用lspci -vvv看一下，很可能显示Speed 2.5GT/s——这对应的就是PCIe Gen1。我遇到过一台存储服务器，客户一直抱怨备份慢，我上去一看，所有盘都降到了Gen1，典型的ASPM导致链路协商失败。
延迟抖动则更隐蔽。你跑iperf可能看不出问题，但切换到真实业务场景——比如数据库事务——延迟的波动就暴露了。我用perf抓过网络中断处理时间，发现当ASPM进入L1状态后，退出延迟能到几十甚至上百微秒，这在金融交易场景下是完全不可接受的。
至于连接不稳定，这往往伴随着硬件复位。我记得有个项目，GPU在跑AI推理时频繁掉卡，dmesg大量报"PCIe Bus Error"。后来抓了lspci -vvv的链路状态，发现ASPM让GPU在L1和省电模式之间来回跳，导致RC（Root Complex）误判链路异常，最终触发复位。
重点提醒：不要只看"速度降了"就认为是硬件故障。ASPM导致的降速通常伴随链路状态变化，用lspci -vvv | grep LnkSta能直接看到当前协商的速率和宽度。如果Speed/Width频繁变化，优先查ASPM配置。
4.2 常见触发场景分析
说白了，链路降速不是无缘无故的。我总结下来，逃不出下面几个典型场景。
4.2.1 热插拔后的链路重协商
很多人以为热插拔之后驱动会自动恢复最佳链路，但实际没那么简单。以NVMe U.2盘为例，你热插了一块盘，系统检测到设备，ASPM默认策略可能会让新盘直接进入L1省电模式。如果盘本身并不完全支持L1，链路就会降速。
我排查过一个案例：数据中心的存储节点，每次在线更换SSD后，新盘的读写性能只有正常值的一半。通过setpci读取链路控制寄存器，发现ASPM控制位被设置成了"启用L1"。手动强制L0s后，链路才恢复正常速率。
避坑指南：我曾经遇到过SAS转PCIe的转接卡，热插后链路协商到Gen1。后来发现转接卡里的ASPM策略与主板不兼容。解决办法是在/sys/bus/pci/devices/.../power/control里写入"on"，强制设备不进入省电状态。
4.2.2 BIOS/UEFI固件中的ASPM策略冲突
这是最容易被忽略的。你操作系统里配置得再好，BIOS里如果有个"Auto"选项，系统一重启就可能被覆盖。不同厂商的BIOS对这个"Auto"的定义也不同——有的让它完全开，有的只允许L0s。
我记得有回国产品牌服务器，换了一批NVMe盘后，所有盘的链路都降到了Gen2。查了两天，最后发现BIOS的"PCIe ASPM Support"设置为"Auto"，而之前老的盘默认支持L1，新盘不支持。BIOS检测到不支持就自动把链路降了一档。
| BIOS设置项 | 典型值 | 对链路速度的影响 |
|---|---|---|
| ASPM Support | Auto | 由固件根据设备能力决定，可能降速 |
| ASPM Support | Disabled | 完全禁用省电，链路最高速率 |
| L1 Substates | Enabled | 如果设备不支持L1.2，可能触发降速 |
4.2.3 电源状态切换（S3/S4唤醒）
系统从睡眠(S3)或休眠(S4)恢复时，所有PCIe设备都要重新枚举。这时候ASPM的恢复机制如果不完善，链路就可能锁定在低速率。我跟踪过一台笔记本，合盖再打开后，内置的NVMe盘速度从Gen3掉到Gen2。重启又能恢复。
为什么？因为系统唤醒时，ASPM策略还没来得及加载，设备已经完成了链路协商。等策略加载完，链路已经在低速率下运行了——而ASPM只管进省电，不管帮你重新协商回高速。
4.2.4 驱动或固件版本不匹配
这也是个坑。操作系统自带的通用驱动和厂商特定驱动，在ASPM处理上有时是两套逻辑。我之前调试一块Intel网卡，lspci显示ASPM L1 Enabled，但用ethtool测吞吐，峰值只能跑满一半。后来换成厂商最新驱动，问题解除。
找原因也比较直接：厂商驱动在初始化时改了链路控制寄存器中的"ASPM Control"字段，把默认的"L0s and L1"改成了"L0s Only"。换句话说，通用驱动不会帮你做这套优化。
经验之谈：如果你同时接多种PCIe设备——比如GPU、NVMe、万兆网卡——最好统一这些设备的ASPM支持能力。让高速设备和低速设备共用一套ASPM策略，很容易出现互相拖累的情况。机柜里同时插计算卡和硬盘的场景尤其要注意。
4.3 如何快速确认是否降速
说了这么多，最关键的一步其实是确认链路状态。我一般只用两个命令就搞定。
# 查看所有PCIe设备的链路速度和宽度
lspci -vvv | grep -E "LnkSta:|LnkCap:" -A 1 | grep -E "Speed|Width"
# 只看NVMe设备
lspci -vvv -s $(lspci -D | grep "Non-Volatile" | awk '{print $1}') | grep LnkSta输出像这样：
LnkSta: Speed 8GT/s (ok), Width x4 (ok) # 这是Gen3 x4，正常
LnkSta: Speed 2.5GT/s (downgraded), Width x1 (downgraded) # 这是降速一旦看到"downgraded"字样，就可以进入下一步排查了——看看ASPM是不是那个幕后黑手。