NVMe 低功耗机制、状态切换与问题排查

目录

一、概述

二、NVMe 低功耗机制

1. NVMe Power State

1.1 工作状态和非工作状态

Operational Power State

Non-Operational Power State

2. Power State 描述信息

3. APST 自动电源状态切换

4. PCIe ASPM 和 L1 Substates

4.1 ASPM

4.2 L1 Substates

5. Runtime PM 和 D3

三、NVMe 状态切换流程

1. 初始化阶段

2. 正常工作阶段

3. 空闲进入低功耗

4. 新 I/O 到达后的恢复

四、功耗与延迟的权衡

五、典型应用场景

六、常见问题与原因分析

1. 空闲后第一次 I/O 延迟明显升高

可能原因

判断方法

2. 空闲后出现 I/O Timeout 或控制器 Reset

可能原因

重点观察

3. 已启用 APST，但功耗没有明显下降

可能原因

4. 性能出现周期性抖动

可能原因

5. 系统休眠唤醒后掉盘

七、Linux 下的检查方法

1. 查看 NVMe 电源状态能力

2. 查看 Power Management 和 APST 配置

3. 查看 Linux 对 APST 的延迟限制

4. 查看 PCIe ASPM 和 L1 Substates

5. 查看 Runtime PM

6. 收集错误日志

八、推荐的问题排查流程

1. 先建立默认配置基线

2. 按层次进行单变量测试

3. 根据结果定位

九、优化建议

对低延迟业务

对电池和待机功耗

对稳定性问题

十、总结

一、概述

NVMe 低功耗管理的目标是在保证 I/O 性能的同时，降低 SSD 在空闲状态下的能耗。其核心并不是单一的“省电开关”，而是由多个层次共同完成：

常见机制包括：

• NVMe Power State；
• APST（Autonomous Power State Transition）；
• PCIe ASPM；
• PCIe L1 Substates；
• Runtime PM；
• 系统 Suspend/Resume 和 D3 电源状态。

因此，在分析 NVMe 低功耗问题时，需要区分：

SSD 控制器低功耗、PCIe 链路低功耗，以及整个设备挂起，并不是同一种状态。

二、NVMe 低功耗机制

1. NVMe Power State

NVMe 控制器通常支持多个电源状态，常见表示为：

PS0、PS1、PS2、PS3……

一般来说：

• PS0 通常是最高性能工作状态；
• 编号更高的状态往往功耗更低；
• 某些状态仍可直接处理 I/O；
• 某些状态属于非工作状态，需要退出后才能处理请求。

但需要注意：

PS 编号没有统一的性能和功耗含义，PS3 并不代表所有 SSD 都具有相同的功耗或唤醒延迟。

1.1 工作状态和非工作状态

Operational Power State

工作状态下，控制器仍然可以处理正常 I/O，只是可能通过以下方式降低功耗：

• 降低控制器时钟频率；
• 关闭部分内部模块；
• 降低并行处理能力；
• 限制内部带宽或队列处理能力。

此类状态适合：

• 低负载持续运行；
• 对延迟有一定要求；
• 不能接受较长唤醒时间的场景。

Non-Operational Power State

非工作状态下，控制器不能直接处理正常 I/O，收到请求后需要先恢复到可工作的状态。

此类状态适合：

• 长时间空闲；
• 笔记本电池模式；
• 间歇性访问设备；
• 对空闲功耗要求较高的场景。

2. Power State 描述信息

主机可以通过 Identify Controller 获取 SSD 支持的电源状态描述信息，重点字段包括：

其中，ENLAT 和 EXLAT 是分析低功耗唤醒延迟的重要依据。

实际应用中，不能只根据功耗数值选择状态，还需要综合考虑：

• 首次 I/O 延迟；
• P99/P99.9 尾延迟；
• 空闲时间长度；
• SSD 固件稳定性；
• 业务对响应时间的要求。

3. APST 自动电源状态切换

APST 是 NVMe 的自动电源状态切换机制。

主机通过配置 APST 表，为 SSD 指定：

• 空闲多长时间后进入低功耗状态；
• 进入哪个电源状态；
• 允许使用的最大退出延迟。

逻辑上可以表示为：

PS0 工作状态
│
├─ 短时间空闲 → 较浅低功耗状态
│
└─ 长时间空闲 → 更深低功耗状态

当有新 I/O 到达时，控制器根据需要退出低功耗状态，然后继续处理请求。

需要注意：

• APST 是“允许控制器自动切换”，不是主机实时控制每一次切换；
• 实际是否进入某个状态还取决于设备实现；
• 查询配置不等于实时获取当前状态；
• 后台 I/O、日志、SMART 查询都可能打断空闲计时。

4. PCIe ASPM 和 L1 Substates

NVMe SSD 通常通过 PCIe 总线连接，PCIe 链路也有独立的低功耗机制。

4.1 ASPM

ASPM 主要管理 PCIe 链路状态，包括：

• L0：正常工作；
• L0s：较浅的链路省电状态；
• L1：较深的链路省电状态。

4.2 L1 Substates

L1 Substates 在 L1 基础上进一步细分：

• L1.1；
• L1.2。

其中，L1.2 通常可以关闭更多物理层电路，因此功耗更低，但链路恢复时间和兼容性要求也更高。

PCIe 低功耗带来的延迟可能包括：

链路恢复延迟
+ 控制器退出 NVMe 电源状态的延迟
+ 正常 I/O 处理延迟

因此，即使 NVMe 控制器没有进入很深的低功耗状态，PCIe 链路进入 L1/L1.2 也可能影响空闲后的第一次 I/O。

5. Runtime PM 和 D3

Runtime PM 是操作系统对整个 PCIe 设备的运行时电源管理。

常见设备状态包括：

• D0：设备正常工作；
• D3hot：设备进入较深的低功耗状态，但仍可能保留部分配置；
• D3cold：设备的供电进一步关闭，恢复过程更复杂。

与 APST 相比，Runtime PM 通常是更重的电源管理动作，可能涉及：

因此：

APST 主要是 SSD 内部电源状态切换，Runtime PM 则可能影响整个设备生命周期。

三、NVMe 状态切换流程

1. 初始化阶段

典型流程如下：

PCIe 枚举
↓
NVMe 驱动加载
↓
Identify Controller
↓
读取 Power State 描述信息
↓
检查 APST 支持能力
↓
结合延迟预算选择可用状态
↓
配置 APST
↓
配置 PCIe ASPM/L1SS
↓
启用 Runtime PM 策略

驱动通常会根据以下条件筛选低功耗状态：

• 设备是否支持 APST；
• 是否为非工作状态；
• 进入和退出延迟；
• 当前电源模式；
• 内核或驱动的延迟预算；
• 已知设备兼容性问题。

2. 正常工作阶段

应用发起 I/O
↓
操作系统构造请求
↓
NVMe 驱动提交命令
↓
控制器处理 I/O
↓
完成命令写入 Completion Queue
↓
中断或轮询获取完成结果

持续 I/O 期间，SSD 通常保持在 PS0 或其他可处理 I/O 的工作状态。

3. 空闲进入低功耗

没有待处理 I/O
↓
达到 APST 空闲时间阈值
↓
控制器保存必要上下文
↓
降低时钟或关闭部分模块
↓
进入低功耗状态

同时，PCIe 链路可能独立进入：

L0
↓
L0s 或 L1
↓
L1.1 / L1.2

两套状态机不一定同步：

• 控制器可能已经进入低功耗，但 PCIe 链路仍处于 L0；
• PCIe 链路可能进入 L1，而控制器仍处于较浅工作状态；
• Runtime PM 可能进一步让设备进入 D3。

4. 新 I/O 到达后的恢复

新 I/O 到达
↓
PCIe 链路恢复
↓
控制器退出低功耗状态
↓
恢复必要时钟和模块
↓
处理新 I/O
↓
返回完成结果

首次 I/O 延迟可能由以下部分构成：

NVMe 电源状态退出延迟
+ PCIe 链路恢复延迟
+ Runtime PM 恢复延迟
+ 实际 I/O 处理延迟

并不是每一次 I/O 都会经历完整流程，是否触发恢复取决于设备当前所处状态。

四、功耗与延迟的权衡

低功耗状态并不是越深越好。进入和退出深度状态本身也会产生时间和能量开销。

如果空闲时间过短，可能出现：

进入低功耗
↓
很快被唤醒
↓
再次进入低功耗

这种频繁切换可能导致：

• 平均功耗不降反升；
• 首次 I/O 延迟增加；
• 尾延迟出现周期性抖动；
• 控制器或链路频繁重建状态。

可以用以下思路理解临界空闲时间：

Tidle>EswitchPactive−PlowTidle​>Pactive​−Plow​Eswitch​​

其中：

• TidleTidle​：预计空闲时间；
• EswitchEswitch​：进入和退出状态的额外能量；
• PactivePactive​：工作状态功耗；
• PlowPlow​：低功耗状态功耗。

因此：

• 空闲时间短，应优先使用浅状态；
• 空闲时间长，可以使用更深状态；
• 对尾延迟敏感时，应限制最大退出延迟；
• 对电池续航敏感时，可接受一定唤醒延迟换取更低功耗。

五、典型应用场景

需要区分：

• 低功耗管理：主要发生在空闲阶段；
• 热管理：主要通过降频、限速解决高温；
• 垃圾回收和缓存管理：可能在持续写入时影响性能。

连续负载下出现性能下降，不一定是 APST 导致的，也可能是温度过高、缓存耗尽或 NAND 垃圾回收。

六、常见问题与原因分析

1. 空闲后第一次 I/O 延迟明显升高

可能原因

• SSD 进入较深的 NVMe Power State；
• PCIe 链路进入 L1/L1.2；
• 设备进入 Runtime PM 或 D3；
• CPU 深度 C-State 或调度延迟；
• SSD 固件的唤醒路径效率较低。

判断方法

分别测试不同空闲时间：

持续 I/O
空闲 10 ms
空闲 100 ms
空闲 1 s
空闲 10 s

如果空闲时间超过某个阈值后，第一次 I/O 延迟突然增加，通常说明触发了某一级低功耗状态。

2. 空闲后出现 I/O Timeout 或控制器 Reset

可能原因

• APST 深度状态退出异常；
• PCIe L1 Substates 恢复不稳定；
• SSD 固件缺陷；
• BIOS、芯片组和 SSD 之间存在兼容性问题；
• D3cold 恢复后设备上下文丢失；
• 供电、信号质量或硬件连接问题。

重点观察

I/O timeout
controller reset
controller is down
Device not ready
PCIe AER error

需要确认错误是否具有以下特征：

• 总是在长时间空闲后发生；
• 只在系统休眠唤醒后发生；
• 关闭 APST 后消失；
• 关闭 ASPM 后消失；
• 是否伴随 PCIe AER 报错。

不能仅凭 AER 日志就断定是 APST 问题，PCIe 信号、插槽、供电和硬件接触也可能产生类似现象。

3. 已启用 APST，但功耗没有明显下降

可能原因

• APST 只是配置启用，设备并未真正进入深度状态；
• 后台进程持续产生 I/O；
• SMART、监控工具频繁访问设备；
• PCIe ASPM 没有启用；
• 驱动的延迟预算限制了可用状态；
• SSD 内部正在执行垃圾回收或其他维护操作；
• 测量位置包含主机端其他功耗。

需要注意：

“配置已开启”不等于“设备实际长期驻留在低功耗状态”。

4. 性能出现周期性抖动

可能原因

• APST 空闲阈值与业务访问周期接近；
• 设备频繁进入和退出低功耗；
• SSD 温度周期性升高；
• SLC 缓存耗尽；
• 垃圾回收；
• CPU、中断或调度因素。

判断方法：

• 与空闲时间相关：优先检查 APST、ASPM；
• 与温度相关：优先检查散热和热降频；
• 与写入量相关：优先检查缓存和垃圾回收。

5. 系统休眠唤醒后掉盘

此类问题不能只检查 APST，还应重点检查：

• Suspend/Resume 流程；
• D3hot/D3cold；
• BIOS 和 ACPI 配置；
• PCIe 链路重新训练；
• NVMe 控制器重新初始化；
• SSD 固件和内核版本兼容性。

七、Linux 下的检查方法

1. 查看 NVMe 电源状态能力

sudo nvme id-ctrl -H /dev/nvme0

重点查看：

• APST 支持情况；
• NPSS；
• 各个 Power State 的最大功耗；
• Operational/Non-Operational 属性；
• ENLAT 和 EXLAT。

2. 查看 Power Management 和 APST 配置

# 查看 Power Management Feature
sudo nvme get-feature /dev/nvme0 -f 0x02 -H
查看 APST Feature
sudo nvme get-feature /dev/nvme0 -f 0x0c -H

注意：

读取 Feature 主要用于查看配置，不能简单地作为 SSD 当前实时电源状态的判断依据。

部分查询操作本身也可能唤醒设备。

3. 查看 Linux 对 APST 的延迟限制

cat /sys/module/nvme_core/parameters/default_ps_max_latency_us

在部分内核中，可以通过启动参数限制或关闭 APST 低功耗状态选择：

nvme_core.default_ps_max_latency_us=0

该方式适合用于故障定位和对照测试。关闭后通常会增加空闲功耗，不能直接作为最终配置。

4. 查看 PCIe ASPM 和 L1 Substates

sudo lspci -vv -s 0000:04:00.0
cat /sys/module/pcie_aspm/parameters/policy

重点查看：

• LnkCap；
• LnkCtl；
• ASPM 配置；
• L1 Substates 能力和状态。

可以使用性能策略进行对照测试：

echo performance | sudo tee /sys/module/pcie_aspm/parameters/policy

需要注意：

• 某些平台由 BIOS 或固件控制 ASPM；
• 内核可能不允许动态修改；
• 该设置可能影响多个 PCIe 设备；
• 测试完成后应恢复原策略。

5. 查看 Runtime PM

cat /sys/bus/pci/devices/0000:04:00.0/power/control
cat /sys/bus/pci/devices/0000:04:00.0/power/runtime_status

常见结果：

对照测试：

echo on | sudo tee /sys/bus/pci/devices/0000:04:00.0/power/control

该操作只影响 Runtime PM，不会同时关闭 APST 或 ASPM。

6. 收集错误日志

sudo nvme smart-log /dev/nvme0
sudo nvme error-log /dev/nvme0
journalctl -k -b | grep -Ei 'nvme|pcie|aer|timeout|reset'

重点关联以下信息：

• 错误发生时间；
• 最近一次 I/O 时间；
• 是否刚从休眠恢复；
• 当前温度；
• 是否出现 PCIe AER；
• 是否发生控制器 Reset；
• 固件、BIOS、内核版本。

八、推荐的问题排查流程

1. 先建立默认配置基线

记录默认情况下的：

• 平均 I/O 延迟；
• P99/P99.9 尾延迟；
• 空闲后首次 I/O 延迟；
• 空闲功耗；
• 温度；
• Timeout、Reset 和 AER 次数。

2. 按层次进行单变量测试

不要一开始同时关闭全部省电机制，否则即使问题消失，也无法确定具体根因。

3. 根据结果定位

• 关闭 APST 后问题消失：重点检查 NVMe 电源状态和 SSD 固件；
• 调整 ASPM 后问题消失：重点检查 PCIe 链路、L1SS 和平台 BIOS；
• 禁止 Runtime PM 后问题消失：重点检查 D3 和设备恢复路径；
• 只在系统休眠唤醒后发生：重点检查 Suspend/Resume 和 D3cold；
• 与温度或持续写入相关：优先排查热管理、缓存和垃圾回收。

九、优化建议

对低延迟业务

• 限制使用深度非工作状态；
• 设置合理的最大退出延迟；
• 重点观察 P99/P99.9，而不仅是平均延迟；
• 必要时保留较浅的 NVMe Power State。

对电池和待机功耗

• 启用 APST；
• 启用 ASPM 和 L1 Substates；
• 允许 Runtime PM；
• 减少无意义的后台轮询；
• 通过实测确认功耗确实下降。

对稳定性问题

• 升级 SSD 固件；
• 更新 BIOS、芯片组驱动和操作系统内核；
• 临时限制深度 APST 状态；
• 对比关闭 ASPM 或 Runtime PM 的结果；
• 检查 PCIe 插槽、供电和硬件连接；
• 不要将所有问题直接归因于省电机制。

十、总结

NVMe 低功耗管理主要由三层机制组成：

NVMe Power State / APST
+
PCIe ASPM / L1 Substates
+
Runtime PM / D3

其典型状态变化为：

正常工作
↓
空闲检测
↓
进入 NVMe 低功耗状态
↓
PCIe 链路进入低功耗
↓
新 I/O 到达
↓
链路和控制器恢复
↓
继续处理 I/O

在实际系统中，低功耗与性能、延迟、稳定性之间存在明显权衡。排查问题时，应重点关注：

• 空闲时间与延迟变化的关系；
• APST、ASPM、Runtime PM 三者的区别；
• 首次 I/O 延迟和尾延迟；
• 控制器 Reset、Timeout 和 PCIe AER 日志；
• SSD 固件、BIOS、内核与硬件平台的组合兼容性。

最终目标不是简单地“关闭所有省电”或“启用最深低功耗”，而是：

根据业务的功耗目标和延迟预算，选择合适的低功耗深度，并通过分层、单变量测试验证其稳定性。

你在实际项目中遇到过 NVMe 低功耗导致的延迟升高或掉盘问题吗？欢迎在评论区分享你的排查经验，一起交流讨论。