sleep mode基础：定义、分类（浅睡/深睡）、典型应用场景（移动端、嵌入式、数据中心）
在《sleep mode唤醒延迟与推理调度平衡实战指南》的开篇，我们必须先厘清一个核心事实：sleep mode（休眠模式）并非简单的“关掉屏幕”或“暂停任务”，而是一种系统级的电源状态管理策略。它通过切断或降低芯片内部时钟、电源域、外设及存储器的供电，在牺牲一定唤醒延迟的前提下，换取功耗数量级的下降。理解sleep mode的基础，是后续讨论“唤醒延迟”与“推理调度”平衡的基石——因为所有调度策略的优化空间，都受限于硬件所定义的休眠深度与恢复路径。
本章将围绕三个核心问题展开：sleep mode的本质定义是什么？浅睡与深睡在硬件行为、功耗收益和恢复代价上有何差异？移动端、嵌入式、数据中心三类典型场景对sleep mode的诉求有何不同？我们将通过一张系统性的分类与权衡图，建立全局视角，再深入各小节拆解原理、方法、案例与误区。
上图展示了sleep mode的核心分类框架。浅睡与深睡并非两个离散的点，而是一条“功耗-延迟”权衡光谱的两端。在实际硬件中，往往存在多个中间状态（如WFI、WFI+Cache Flush、Power Gating等），但理解这两个极端有助于我们把握设计主线。下面我们逐一展开。
2.1 sleep mode的核心定义与本质
核心原理：sleep mode的本质是“选择性关闭”——关闭那些当前不参与计算或感知的硬件资源，以降低动态功耗（与时钟频率和电压平方成正比）和静态功耗（漏电流）。从操作系统视角看，sleep mode是CPU空闲时进入的一种低功耗状态；从硬件视角看，它是电源管理单元（PMU）根据软件请求，对时钟树、电源域、锁相环（PLL）和存储阵列进行分级下电的过程。
一个关键概念是“唤醒源”。进入sleep mode后，系统必须保留至少一个中断源（如RTC定时器、GPIO边沿触发、网络唤醒包），以便在需要时恢复执行。唤醒源的数量和类型，直接决定了该休眠状态的应用边界。例如，一个仅保留GPIO唤醒的深睡模式，无法用于需要定时唤醒的传感器采集任务。
从软件栈来看，Linux内核中的cpuidle框架将不同休眠状态编号为C-states（C0为运行态，C1为暂停，C6为深睡），而ARM处理器则使用WFI（Wait For Interrupt）和WFE（Wait For Event）指令配合PSCI固件接口实现。理解这些底层机制，是后续优化推理调度（如NPU任务与CPU休眠的协同）的前提。
2.2 浅睡（Light Sleep）与深睡（Deep Sleep）的对比
判断方法：区分浅睡与深睡，可以从三个维度进行判断——电源域切断范围、存储保持策略、唤醒路径长度。浅睡通常只关闭CPU核心时钟，保留L1/L2缓存和片上SRAM的供电；深睡则可能切断整个CPU电源域，仅保留一个独立的Always-On域（包含RTC、唤醒控制器和少量SRAM）。
| 对比维度 | 浅睡（Light Sleep） | 深睡（Deep Sleep） |
|---|---|---|
| 时钟状态 | CPU时钟门控，外设时钟可保留 | 主PLL关闭，仅保留32kHz RTC时钟 |
| 电源域 | 逻辑电源域保持，电压可微降 | 主电源域断电，仅Always-On域供电 |
| 上下文保存 | 寄存器/缓存内容自动保留 | 需软件主动保存到SRAM或Flash |
| 典型唤醒延迟 | 10µs ~ 100µs | 1ms ~ 100ms（含Flash加载时间） |
| 功耗降低幅度 | 降至运行功耗的1/10 ~ 1/100 | 降至运行功耗的1/1000 ~ 1/10000 |
| 典型应用 | 音频播放暂停、传感器轮询间隔 | 待机、关机前的最后阶段、电池供电设备长待机 |
操作流程：在实际工程中，选择浅睡还是深睡，需要遵循以下判断流程：
- 评估唤醒频率：如果系统需要每100ms以内唤醒一次，浅睡是唯一可行选择，因为深睡的唤醒延迟可能超过事件间隔。
- 检查上下文大小：深睡需要保存的上下文（如DMA描述符、浮点寄存器、MMU配置）如果超过可用SRAM容量，则必须选择浅睡或增加非易失存储。
- 计算功耗预算：假设待机时间为T，浅睡功耗为PL，深睡功耗为PD，唤醒延迟为tL和tD，则需满足：
PL×(T-tL) + Pactive×tL < PD×(T-tD) + Pactive×tD，否则深睡无收益。
2.3 典型应用场景：移动端、嵌入式、数据中心
场景拆解：三类场景对sleep mode的诉求差异极大，源于其供电约束、任务特征和散热条件的不同。
移动端（智能手机/平板）：以SoC为中心，包含CPU、GPU、NPU、Modem、ISP等多个异构计算单元。移动端的核心矛盾是“感知-响应”——用户随时可能点亮屏幕或触发语音助手，因此系统必须支持从深睡到全速运行的亚毫秒级快速唤醒。典型策略是：屏幕关闭后进入浅睡（CPU暂停，Modem保持监听），若长时间无交互则逐步降级到深睡（仅保留RTC和电源按键唤醒）。
嵌入式（MCU/物联网节点）：电池供电且任务周期性强（如每10秒采集一次温湿度）。嵌入式系统通常只有两级休眠：运行态和深睡（Stop/Mode 2）。由于MCU的唤醒延迟极短（微秒级），深睡几乎总是首选。但需要注意外设的独立休眠控制——例如LoRa模块的接收窗口必须与MCU的唤醒时序精确对齐。
数据中心（服务器/加速器）：这里sleep mode的粒度更细，通常以“核级”或“域级”为单位。CPU空闲时进入C6状态，但内存控制器、PCIe链路和网络接口必须保持活跃以响应远程请求。数据中心的挑战在于“唤醒风暴”——当大量虚拟机同时收到网络包时，所有核同时唤醒会导致电源尖峰和温度骤升。因此，调度器需要引入“唤醒延迟预算”，将不同优先级的任务映射到不同休眠深度。
背景与约束：某农业物联网节点采用STM32L4 MCU，搭载SHT30温湿度传感器和SX1262 LoRa模块，使用2节AA电池供电，要求续航2年。初始设计为每60秒唤醒一次，采集数据后立即深睡。
初始现象：实测平均电流为45µA，远高于理论值（深睡2µA + 唤醒平均3µA）。分析发现，LoRa模块在发送后进入Standby模式（功耗1.2mA），而非Shutdown模式（0.3µA），且MCU在每次唤醒后等待LoRa模块稳定（需5ms）期间保持运行态。
分析过程：通过电流探头抓取波形，发现每次唤醒周期中，MCU运行时间长达120ms（含LoRa初始化、传感器读取、数据发送、等待ACK超时），其中80ms是无效等待。进一步检查代码，发现传感器读取使用了阻塞式I2C，且未启用DMA。
实际操作：①将LoRa模块在发送后立即切换到Shutdown模式，仅保留DIO1引脚作为唤醒源；②将I2C读取改为DMA+中断方式，使MCU在等待传感器数据时进入浅睡（WFI）；③将等待ACK超时从100ms缩短至20ms，失败则进入深睡等待下个周期重试。
结果对比：优化后平均电流降至8.5µA，其中深睡占比99.2%，有效唤醒时间仅占0.8%。理论续航从1.1年提升至2.3年，满足设计指标。
风险与代价：缩短ACK超时可能导致在弱信号区域丢包率上升（从0.1%升至0.4%），但通过增加一次重试机制（每10个周期额外唤醒一次）补偿，整体可靠性未受影响。
复盘经验：sleep mode的优化不能只看MCU本身，必须将外设的休眠状态纳入统一管理。外设的“假休眠”往往是功耗黑洞。
2.4 常见误区与总结复盘
误区一：将“关屏”等同于“sleep mode”。在移动端，关屏只是显示子系统休眠，CPU可能仍在全速运行（如后台下载）。真正的sleep mode需要CPU进入idle状态并触发cpuidle governor的深度状态选择。
误区二：忽视唤醒源配置。一个常见的bug是：进入深睡后，由于未正确配置唤醒引脚的复用功能，导致只能通过复位唤醒，丢失所有上下文。务必在进入休眠前，用echo mem > /sys/power/state测试所有唤醒路径。
误区三：在数据中心盲目追求C6状态。对于延迟敏感型服务（如Redis缓存），C6的唤醒延迟（约200µs）可能超过RPC超时阈值。此时应锁定C1状态，或使用intel_idle.max_cstate=1内核参数禁用深睡。
总结复盘：sleep mode的设计本质是“功耗-延迟-复杂度”的三方权衡。浅睡适合高频短时等待，深睡适合低频长时待机。在实际项目中，建议采用以下清单进行自检：
- 是否列出了所有唤醒源，并验证其电气特性（边沿/电平触发）？
- 深睡时的上下文保存代码是否经过CRC校验？
- 外设的休眠模式是否与主控的休眠状态联动？
- 是否测量了实际唤醒延迟（用示波器抓GPIO到指令执行）？
- 是否评估了休眠/唤醒切换频率对电源纹波的影响？