当前位置：首页 > news >正文

电源管理——系统级省电协同：从占空比到能量-延迟权衡

news 2026/5/4 19:58:10

所有省电技术，都是同一个数学公式的不同变体。系统级省电不是在单点优化，而是让每一层都朝着“降低占空比”这个目标协同。

你可能见过各种省电技巧：CPU进C‑State、蓝牙调广播间隔、Wi‑Fi开PSM、USB选择性挂起……它们五花八门，但背后都指向同一个简单的数学公式：

P_avg = P_active × D + P_sleep × (1 - D)

其中 D = T_active / (T_active + T_sleep) 就是占空比——活跃时间占总时间的比例。

P_active 和 P_sleep 由物理工艺决定，很难大幅改变。所以，系统级省电的唯一出路，就是尽可能让 D 趋近于 0。但 D 不能任意小，因为从睡眠回到活跃需要时间——这个时间叫唤醒延迟。而唤醒延迟会损害系统的响应性。

于是，每一层都在做同一个权衡：为了降低占空比，我最多能忍受多大的延迟？

一、能量-延迟权衡曲线

你可以想象一条向右下倾斜的曲线：横轴是“允许的唤醒延迟”，纵轴是“能达到的平均功耗”。你愿意等越久，功耗就能降得越低。

技术/模式	唤醒延迟	平均功耗	适用场景
CPU C1 (HLT)	< 1µs	1-5% of active	极短空闲
CPU C6	~100µs	<0.1% of active	较长空闲
BLE广播间隔20ms	~20ms	250µA	快速发现
BLE广播间隔2s	~2s	5µA	极低功耗待机
Wi‑Fi PSM (100ms)	~100ms	几mA	移动设备
Wi‑Fi TWT (1s)	~1s	几百µA	物联网

关键启发：当你面对一个新的低功耗技术时，第一反应不应该是“它有多省电”，而应该是 “它引入了多大的延迟代价”。省电能力与延迟代价是同一枚硬币的两面。

C‑State 数字越大，睡眠越深，唤醒越慢，功耗越低。操作系统会根据预测的空闲时长选择最深的可行 C‑State。

协同要点：OS的cpuidle governor会预测下次唤醒的时间，只有预测空闲时长大于某个阈值（target residency）时，才敢进入深睡眠。如果预测不准，深睡反而浪费能量。

传统OS内核有固定时钟中断（如1ms一次），即使系统空闲也会每1ms唤醒CPU，阻止进入深度C‑State。Tickless模式在空闲时停止周期性中断，只设置一个单次定时器（下一个已知事件的时间），CPU可以在此期间进入任意深度的睡眠。

效果：唤醒频率从1000Hz降到下一个事件的频率（如0.1Hz），占空比下降几个数量级。

最上层根据当前场景动态调整下层参数。例如：

系统级协同不是各管各的，而是一层层契约：

这就是协同的数学本质：一个全局优化问题——在满足各层延迟约束的前提下，最小化总能耗。

更深的睡眠不一定更省电
如果空闲时间太短，进入深度睡眠再醒来的能量开销（保存/恢复状态、重新锁定PLL）可能超过浅睡一直等的能量。这叫“睡眠开销过路费”。因此，只有当预测空闲时长大于target residency时，才值得进入深睡。
最快的计算也是最省电的
对于突发性任务，用最高频率快速完成（race‑to‑idle），然后让CPU进入极深睡眠，总能耗往往低于降频慢慢跑。因为睡眠时的功耗远低于运行时的功耗。
最大的敌人不是功耗，是唤醒频率
一颗芯片深度睡眠时可能只耗1µA，但如果每10ms被唤醒一次（哪怕只醒1ms），平均功耗 ≈ 1mA×0.1 + 1µA×0.9 ≈ 100µA，比1µA大了100倍。所以合并中断、延长轮询间隔、使用硬件offload这些减少唤醒次数的技术，往往比降低活跃功耗更有效。

当你拿到一个带电源管理的系统，按以下四步走：

画出唤醒时间线：记录系统从启动到下一次睡眠之间，被哪些事件唤醒（中断、定时器、DMA）。每个事件标出：唤醒时刻、活跃时长、下一次睡眠时刻。
计算当前占空比：D = ΣT_active / T_total。目标是把D压到1%以下（对电池供电设备）。
找出占空比的主要贡献者：
- 唤醒次数太多 → 合并中断，增大轮询间隔，用硬件保活。
- 单次活跃时间太长 → 优化代码，或用race‑to‑idle。
- 某个外设无法睡眠 → 检查驱动是否支持runtime PM。
逐层检查“延迟预算”：
- 从应用层往下问：用户/应用能忍受的最大延迟是多少？
- 这个延迟能否分配给下层的睡眠？
- 下层是否提供了相应深度的睡眠状态？
- 如果某层没有提供足够的睡眠深度，那就是瓶颈。