Linux Power Management 子系统：从 suspend/resume 到 Runtime PM、PM QoS

Joseph Cooper2026-05-01 15:31

文章目录

  • [Linux Power Management 子系统：从 suspend/resume 到 Runtime PM、PM QoS](#Linux Power Management 子系统：从 suspend/resume 到 Runtime PM、PM QoS)
    • [1. 先分清两类 PM：整机睡眠和运行态省电](#1. 先分清两类 PM：整机睡眠和运行态省电)
    • [2. System suspend：从 `/sys/power/state` 到平台固件](#2. System suspend：从 /sys/power/state 到平台固件)
    • [3. 为什么 suspend 前要 freeze 进程](#3. 为什么 suspend 前要 freeze 进程)
    • [4. 设备 PM 回调：不是所有动作都塞进 `suspend()`](#4. 设备 PM 回调：不是所有动作都塞进 suspend())
    • [5. Wakeup source：能中断，不等于能唤醒系统](#5. Wakeup source：能中断，不等于能唤醒系统)
    • [6. Runtime PM：系统醒着，设备也可以睡](#6. Runtime PM：系统醒着，设备也可以睡)
    • [7. CPUIdle、CPUFreq、OPP：CPU 省电不是一个按钮](#7. CPUIdle、CPUFreq、OPP：CPU 省电不是一个按钮)
    • [8. PM QoS：它不是省电按钮，而是约束系统别省过头](#8. PM QoS：它不是省电按钮，而是约束系统别省过头)
    • [9. 调试 suspend/resume 时按层切，不要一把抓](#9. 调试 suspend/resume 时按层切，不要一把抓)
    • [10. 写驱动时的 PM checklist](#10. 写驱动时的 PM checklist)
    • 参考资料

Linux Power Management 子系统：从 suspend/resume 到 Runtime PM、PM QoS

做 Linux 驱动或 BSP 时，电源管理问题通常不是一句"进 suspend 了"就能解释清楚的。

同样是省电，echo mem > /sys/power/state 是整机进入睡眠；pm_runtime_put_autosuspend() 是单个设备在运行态下自动降功耗；CPUIdle 是 CPU 在没有任务时挑一个合适的 C-state；CPUFreq/Devfreq 是运行中根据负载调频；PM QoS 则经常反过来告诉内核"别睡太深， latency 顶不住"。

这些机制都属于 Linux Power Management，但它们解决的问题完全不同。本文按一条主线把它们串起来：先分清 system-wide PM 和 working-state PM，再看 suspend/resume 的路径、wakeup IRQ 的处理方式，最后回到 Runtime PM、CPUIdle、DVFS 和 PM QoS。

1. 先分清两类 PM：整机睡眠和运行态省电

Linux 内核文档把电源管理分成两种高层策略：

策略 典型场景 核心目标 常见机制
System-wide power management 系统长时间不用，要进入睡眠 让整个系统进入一个全局低功耗状态，用户态停止运行 freeze、standby、mem、disk、system suspend/resume
Working-state power management 系统仍在工作，但某些 CPU 或设备暂时不用 在不停止整个系统的前提下降低局部功耗 Runtime PM、CPUIdle、CPUFreq、Devfreq、OPP、GenPD、PM QoS

原资料里把这两类称为 Static 和 Dynamic。更准确地说，Static 关注"系统整体已经不活跃时怎么省电"，Dynamic 关注"系统还在运行时，短暂空闲或负载变化时怎么省电"。

不要把这两类混在一起看。system suspend 会冻结用户态、停止设备、关 CPU、进入平台 sleep state；Runtime PM 不会冻结用户态，它只管理单个设备的运行态 idle；CPUIdle 甚至是每个 CPU 在 idle loop 里根据预测挑一个睡眠深度。

2. System suspend：从 /sys/power/state 到平台固件

用户态触发系统睡眠最常见的入口是 /sys/power/state：

bash 复制代码 
cat /sys/power/state
cat /sys/power/mem_sleep

echo freeze > /sys/power/state
echo mem > /sys/power/state
echo disk > /sys/power/state

几个常见 sleep state 的差异可以先这样记：

状态 常见名字 大致动作 唤醒代价
freeze Suspend-to-Idle / S2Idle 纯软件 suspend：冻结用户态、暂停 timekeeping、设备进低功耗，CPU 进最深 idle 最小
standby / shallow Power-on suspend 在 S2Idle 基础上 offline nonboot CPU，挂起底层系统功能 中等
mem / deep Suspend-to-RAM / STR RAM 自刷新，其他大部分模块掉电，通常需要平台/固件配合 较大
disk Hibernation / STD 内存镜像写入持久化存储后掉电，唤醒时重新加载镜像 最大

在嵌入式 ARM/ARM64 SoC 上，mem/deep 往往会走到平台相关的 suspend hook，再通过 PSCI 调用进入 ATF/固件，由固件完成最后的掉电或低功耗状态切换。也就是说，Linux PM core 负责通用流程，平台代码和固件负责最后那一段 SoC 相关动作。

简化后的 suspend 路径可以看成这样：

text 复制代码 
echo mem > /sys/power/state
  -> pm_suspend()
    -> enter_state()
      -> suspend_prepare()
        -> suspend notifiers
        -> freeze user processes
        -> freeze freezable kernel threads
      -> suspend_devices_and_enter()
        -> dpm_suspend_start()
          -> device ->prepare()
          -> device ->suspend()
        -> suspend_enter()
          -> device ->suspend_late()
          -> suspend_device_irqs()
          -> device ->suspend_noirq()
          -> disable_nonboot_cpus()
          -> syscore_suspend()
          -> platform suspend_ops->enter()

Resume 基本按相反方向回来：

text 复制代码 
platform wakeup
  -> syscore_resume()
  -> enable_nonboot_cpus()
  -> device ->resume_noirq()
  -> resume_device_irqs()
  -> device ->resume_early()
  -> device ->resume()
  -> device ->complete()
  -> thaw tasks
  -> resume notifiers

这个流程里有三个分界点特别重要：

分界点 发生了什么 驱动要注意什么
freezer 之后 用户态和可冻结内核线程不再正常运行 不要在 late 阶段还依赖用户态服务
late 之后、noirq 之前 设备大多已经 quiesce，随后 IRQ handler 会被屏蔽 会和中断竞争的寄存器保存、唤醒配置要放对阶段
平台 enter 之前 nonboot CPU offline，syscore 已 suspend 平台 hook 里通常只剩很少的内核上下文可用

3. 为什么 suspend 前要 freeze 进程

Freezer 不是为了"让系统看起来安静一点"，而是为了避免用户态或部分内核线程在设备 suspend 时继续访问硬件。

官方 freezer 文档里有几个关键点：

对象 freeze 方式 驱动相关影响
用户态进程 freezer 启动后，通过类似信号路径让任务进入冻结状态 用户态不会继续通过 ioctl、mmap、sysfs 等路径碰设备
可冻结内核线程 线程必须主动 set_freezable() 并周期性调用 try_to_freeze() 或使用 wait_event_freezable() 驱动私有线程如果会直接访问设备，要么用 freezer，要么用更精确的锁/状态机同步
不可冻结内核线程 默认不会 freeze 不能假设所有内核线程都停了

这解释了一个常见问题：如果 resume 回调里调用 request_firmware()，可能会卡住或超时。因为用户态还没完全回来，提供 firmware 的用户态进程可能仍处在冻结阶段。驱动需要的 firmware 应该在 suspend 前准备好，或者用合适的 notifier 提前处理。

4. 设备 PM 回调：不是所有动作都塞进 suspend()

struct dev_pm_ops 是设备驱动和 PM core 之间最常见的接口：

c 复制代码 
struct dev_pm_ops {
        int (*prepare)(struct device *dev);
        void (*complete)(struct device *dev);
        int (*suspend)(struct device *dev);
        int (*resume)(struct device *dev);
        int (*suspend_late)(struct device *dev);
        int (*resume_early)(struct device *dev);
        int (*suspend_noirq)(struct device *dev);
        int (*resume_noirq)(struct device *dev);
        int (*runtime_suspend)(struct device *dev);
        int (*runtime_resume)(struct device *dev);
        int (*runtime_idle)(struct device *dev);
};

写驱动时可以按阶段分配职责：

阶段 典型职责 不适合做什么
prepare() 阻止新的 child device 注册；处理 direct-complete 判断 不要直接把设备打到低功耗
suspend() 停 I/O、停队列、保存主要上下文、必要时配置 wakeup 不要长时间阻塞
suspend_late() 做 suspend 后半段，通常是保存剩余状态、关闭部分资源 不要再依赖 Runtime PM 继续调度
suspend_noirq() 在普通 action IRQ handler 不会再运行后，处理会和中断竞争的状态 不要做需要普通中断完成的等待
resume_noirq() 在 IRQ action handler 恢复前，把设备恢复到能识别中断来源的状态 不要假设完整业务 I/O 已恢复
resume_early() 撤销 late 阶段动作 不要过早唤醒用户可见业务流
resume() 恢复设备正常 I/O 能力 不要忘记 Runtime PM 状态一致性
complete() 撤销 prepare 阶段动作；处理 direct-complete 后续 不要假设所有设备都走过完整 suspend/resume

一个实用判断是：如果某段代码可能和中断处理函数抢同一组寄存器，它通常不应该放在普通 suspend() 里，而要考虑 late/noirq 阶段。反过来，如果某段代码需要睡眠、需要用户态、需要复杂依赖，它就不应该放到 noirq 之后。

5. Wakeup source：能中断，不等于能唤醒系统

资料里的触摸屏唤醒案例很典型：设备平时有普通中断，系统 suspend 后又希望"双击屏幕"能唤醒整机。驱动里通常会看到这些接口：

c 复制代码 
/* 声明设备具备 wakeup 能力，并启用 wakeup source */
device_init_wakeup(dev, true);

static int foo_suspend(struct device *dev)
{
        struct foo *foo = dev_get_drvdata(dev);

        if (device_may_wakeup(dev))
                enable_irq_wake(foo->irq);

        return 0;
}

static int foo_resume(struct device *dev)
{
        struct foo *foo = dev_get_drvdata(dev);

        if (device_may_wakeup(dev))
                disable_irq_wake(foo->irq);

        return 0;
}

这里最容易混淆的是 enable_irq_wake() 和 IRQF_NO_SUSPEND：

机制 作用 关键区别
enable_irq_wake() 把某条 IRQ 配置成系统 wakeup IRQ 目标是唤醒系统，平台可能要把信号路由到专门的唤醒逻辑
IRQF_NO_SUSPEND suspend/resume 周期内不被 suspend_device_irqs() 关闭 只能说明这条 IRQ suspend 时仍可触发，不保证能唤醒系统

官方文档明确强调：IRQF_NO_SUSPEND 不等价于系统唤醒。如果目标是把系统从 sleep state 拉回来，要使用 enable_irq_wake()。同一个设备上通常也不应该同时混用 IRQF_NO_SUSPEND 和 enable_irq_wake()，因为二者在 suspend 后是否执行普通 interrupt handler 的语义是冲突的。

再看 wakeup IRQ 的时序：

text 复制代码 
suspend_late 完成
  -> suspend_device_irqs()
  -> wakeup IRQ 保持特殊 armed 状态
  -> 系统进入 sleep
  -> 设备触发 wake signal
  -> PM core 记录 wakeup event，启动 resume
  -> resume_noirq / resume_device_irqs()
  -> 设备正常 IRQ handler 才适合恢复完整处理

所以双击唤醒这类驱动不要假设"中断来了就可以马上访问所有硬件资源"。如果 IRQ 线程可能在 resume 尚未完成时跑起来，常见做法是只记录 wake 事件，或者在 threaded IRQ/workqueue 中等待一个 resume completion，并且一定要带 timeout，避免 PM 路径被驱动自己卡死。

6. Runtime PM：系统醒着，设备也可以睡

System suspend 是整机级别的状态迁移；Runtime PM 是设备级别的运行态 idle 管理。

Runtime PM 的典型模型是 use count：

c 复制代码 
static int foo_open(struct inode *inode, struct file *file)
{
        struct foo *foo = container_of(inode->i_cdev, struct foo, cdev);

        pm_runtime_get_sync(foo->dev);
        return 0;
}

static int foo_release(struct inode *inode, struct file *file)
{
        struct foo *foo = container_of(inode->i_cdev, struct foo, cdev);

        pm_runtime_mark_last_busy(foo->dev);
        pm_runtime_put_autosuspend(foo->dev);
        return 0;
}

static const struct dev_pm_ops foo_pm_ops = {
        SET_RUNTIME_PM_OPS(foo_runtime_suspend,
                           foo_runtime_resume,
                           foo_runtime_idle)
};

pm_runtime_get_sync() 表示"我要用设备，确保它恢复到 active"；pm_runtime_put_autosuspend() 表示"我暂时不用了，过一段 autosuspend delay 后可以进 runtime suspend"。当 use count 归零且策略允许时，PM core 会调用 runtime_suspend()；再次使用时调用 runtime_resume()。

Runtime PM 的价值在于它不影响用户态整体运行，也不要求整个系统进入 sleep。摄像头、I2C/SPI 外设、GPU、显示管线、USB 控制器等，都可以在系统醒着时按需关闭 clock、regulator 或 power domain。

不过 Runtime PM 和 System PM 会相遇。系统进入 suspend 时，某个设备可能已经 runtime-suspended。驱动要决定：保持它 suspend 状态直接跨过系统睡眠，还是先 runtime resume 回来再配置系统 wakeup。这个决策没有通用答案，取决于硬件 wake 能力和子系统约束。

7. CPUIdle、CPUFreq、OPP：CPU 省电不是一个按钮

运行态 CPU 电源管理至少要分两件事：

子系统 管什么 典型问题
CPUFreq CPU 忙的时候跑多快，也就是 P-state / 频率电压选择 当前负载需要多少算力
CPUIdle CPU 没任务时睡多深，也就是 C-state 选择 预计能睡多久，允许多大唤醒延迟

CPUFreq 由 core、governor 和 driver 组成。governor 根据利用率估计需要的性能，driver 负责把请求落到硬件。很多 SoC 上 CPUFreq/Devfreq 最后都会落到 OPP，也就是一组频率、电压二元组：

text 复制代码 
{ 300 MHz, 1.0 V }
{ 800 MHz, 1.2 V }
{ 1 GHz,   1.3 V }

OPP 的意义不是"频率列表"这么简单，而是把"这个频率至少需要多少电压"结构化，供 CPUFreq、Devfreq、thermal、regulator、clock 等模块协同使用。

CPUIdle 关注的是另一件事：当 scheduler 发现某个 CPU 没有 runnable task，CPU 会进入 idle loop。CPUIdle governor 会结合几个条件选择 idle state：

条件 为什么重要
下一次 timer event 还有多久 睡太深可能还没省回成本就被 timer 叫醒
idle state 的 target residency 进入该状态至少要待多久才划算
idle state 的 exit latency 从该状态醒来最坏要多久
PM QoS latency limit 有业务声明低延迟要求时，不能选超过限制的深睡眠

所以"系统耗电高"不一定是 CPUFreq 没降频，也可能是 CPUIdle 被某个 PM QoS 请求限制，只能进浅 C-state；也可能是频繁 timer/IRQ 让 CPU 根本睡不久。

8. PM QoS：它不是省电按钮，而是约束系统别省过头

PM QoS 的名字容易误导。它不是直接省电的机制，而是性能约束接口。它告诉内核：在省电时要满足某些 latency、throughput 或 device-specific 限制。

最常见的是 CPU latency QoS。内核维护一组请求，并把有效值聚合出来。对 CPU latency 来说，聚合值通常取所有请求里的最小值，因为最严格的 latency 约束必须被满足。

用户态可以通过保持 /dev/cpu_dma_latency 打开的方式提交约束：

c 复制代码 
int32_t latency_us = 100;
int fd = open("/dev/cpu_dma_latency", O_WRONLY);

write(fd, &latency_us, sizeof(latency_us));

/* fd 保持打开期间，请求持续有效；关闭 fd 后请求自动清理 */

设备也有自己的 PM QoS：

c 复制代码 
struct dev_pm_qos_request qos_req;

dev_pm_qos_add_request(dev, &qos_req,
                       DEV_PM_QOS_RESUME_LATENCY,
                       500);

dev_pm_qos_update_request(&qos_req, 1000);
dev_pm_qos_remove_request(&qos_req);

这类约束会影响 Runtime PM、GenPD governor、CPUIdle state 选择等策略。比如音频播放需要稳定低延迟时，系统可能不能让 CPU 进入 exit latency 很大的深 C-state；某个设备 resume latency 受限时，它所在的 power domain 可能不能轻易 power off。

9. 调试 suspend/resume 时按层切，不要一把抓

调试 PM 问题最怕从整条链路同时猜。更好的办法是按层拆：

现象 优先检查
写 /sys/power/state 后直接失败 dmesg 里 PM core 报错、freezer 是否失败、哪个 device callback 返回错误
能 suspend 但马上醒 wakeup source、/proc/interrupts、/sys/kernel/debug/wakeup_sources、ACPI/SoC wake IRQ
suspend 卡住 device suspend callback 是否阻塞、是否在 noirq 后等待普通中断、是否请求用户态资源
resume 后设备不可用 resume_noirq/early/resume 阶段是否恢复寄存器、clock/regulator、IRQ 状态
运行态功耗高 CPUIdle state、PM QoS 请求、timer/IRQ 唤醒频率、Runtime PM use count

常用命令可以先准备这些：

bash 复制代码 
dmesg -T | grep -iE 'PM:|suspend|resume|wakeup|freez|irq'

cat /sys/power/state
cat /sys/power/mem_sleep
cat /sys/power/wakeup_count

find /sys/devices -path '*/power/wakeup' -print

mount -t debugfs none /sys/kernel/debug
cat /sys/kernel/debug/wakeup_sources

cat /proc/interrupts
cat /sys/devices/system/cpu/cpuidle/current_driver
cat /sys/devices/system/cpu/cpuidle/current_governor_ro

如果内核打开了 CONFIG_PM_DEBUG，还可以用 /sys/power/pm_test 按层测试：

bash 复制代码 
cat /sys/power/pm_test

echo freezer > /sys/power/pm_test
echo mem > /sys/power/state

echo devices > /sys/power/pm_test
echo mem > /sys/power/state

echo none > /sys/power/pm_test

freezer -> devices -> platform -> processors -> core 是逐步深入的。哪一级失败，就先看那一级之前刚引入的动作，不要一开始就怀疑全部驱动或整个平台固件。

10. 写驱动时的 PM checklist

最后给一个驱动侧 checklist：

问题 建议
设备是否能作为系统唤醒源 probe 时用 device_init_wakeup()；suspend/resume 中按 device_may_wakeup() 配置 enable_irq_wake() / disable_irq_wake()
suspend 回调是否会等用户态 不要在 suspend 后半程依赖用户态；firmware 等资源提前准备
是否在 noirq 阶段等待普通 IRQ 避免；普通 action handler 已被屏蔽
是否有 runtime PM system PM 回调要考虑设备已经 runtime-suspended 的情况
是否共享 power domain 不要只看单设备，GenPD 可能因为同域其他设备或 QoS 不能 power off
是否有低延迟业务 检查 PM QoS 请求，CPUIdle/Runtime PM 可能因此被限制
resume 后硬件是否可能被重置 对 deep sleep/平台 suspend 要能完整 reinit，不能只假设寄存器保持

把 Linux PM 看成一条链会很乱。更好的心智模型是：system-wide PM 负责"整机什么时候睡、怎么睡、怎么醒"；working-state PM 负责"系统醒着时，哪些局部资源可以按需降功耗"；PM QoS 则是在二者之间不断加约束，防止省电策略破坏 latency、throughput 或设备恢复时间。

调 suspend/resume 时，先定位自己站在哪一层，再看对应的接口和时序。这样问题会小很多。

参考资料

相关推荐
wj3055853782 小时前
CC-Switch 在 WSL Ubuntu 中安装记录
linux·运维·ubuntu
Joseph Cooper2 小时前
Linux HID 子系统实战：从虚拟键盘到 input 事件上报
linux·c语言·计算机外设
原来是猿2 小时前
【Socket编程预备知识】
linux·运维·服务器·网络
__beginner__3 小时前
CentOS 磁盘占用异常排查与处理手册（df 高、du/ncdu 低）
linux·运维·centos
坚持就完事了4 小时前
YARN资源管理器
大数据·linux·hadoop·学习
Joseph Cooper4 小时前
Linux regmap 子系统实战：在驱动中 dump PMIC 寄存器定位供电问题
linux·运维·服务器
计算机安禾4 小时前
【Linux从入门到精通】第35篇：容器化技术预备——Docker安装与基本概念
linux·运维·docker
子木HAPPY阳VIP4 小时前
信创UOS,Docker 完整操作部署（Dockerfile部署方式）&排错整合
linux·运维·redis·nginx·docker·容器·tomcat
瞎折腾啥啊5 小时前
vcpkg与CMake
linux·c++·cmake·cmakelists
热门推荐
01GitHub 镜像站点02要裂开了！ChatGPT要手机号验证了？注册Codex要求验证电话号码怎么办？2026年登陆Codex要手机号验证的解决办法03Codex 接入 DeepSeek API 完整配置文档042026年4月AI大事件深度解读：大模型竞争进入“深水区“05【AI】2026 年具身智能模型和世界模型总结06裂开！ChatGPT 居然开始要手机号验证，附详细解决方法07实测可用｜小米 MiMo 百万亿 Token 免费领，开发者速冲08近期有什么ai的新消息，新动态？ 2026.4月092026年AI编程工具终极横评：Cursor vs Claude Code vs Copilot10在Windows 11上安装Docker的踩坑记录