Linux电源管理框架：子系统架构与关键组件

好，我们开始聊Linux电源管理框架。说实话，这个框架刚接触时会觉得有点乱——又是PM Core，又是PM QOS，还有Runtime PM，一堆缩写。但你别被吓到，它们的分工其实很清晰。

我个人习惯把Linux电源管理想象成一个三层结构：底层是硬件相关的驱动和固件，中间是核心框架层，上层是策略和接口。今天咱们重点啃中间这层——PM Core、PM QOS和Runtime PM。这三兄弟撑起了整个Linux电源管理的大梁。

PM Core：电源管理的中枢神经

PM Core是整个电源管理框架的心脏。它负责管理系统的suspend/resume流程，维护状态机，协调各个子系统的休眠唤醒动作。说白了，它就是那个发号施令的总指挥。

我记得刚接手一个嵌入式项目时，发现系统休眠后经常唤醒失败。查了两天才定位到问题——某个驱动没有正确注册suspend回调，PM Core在遍历设备列表时直接跳过了它。嗯，这种坑踩过一次就记住了。

PM Core的核心职责包括：

系统级休眠流程编排：冻结进程、挂起设备、关闭非启动CPU、进入低功耗模式
唤醒流程管理：检测唤醒源、恢复CPU、恢复设备、解冻进程
通知链机制：在休眠/唤醒的关键节点通知各子系统
状态机维护：PM_SUSPEND_FREEZE、PM_SUSPEND_STANDBY、PM_SUSPEND_MEM、PM_SUSPEND_MAX

关键数据结构：

// include/linux/suspend.h
enum suspend_state_t {
    PM_SUSPEND_FREEZE,   // 冻结空闲任务
    PM_SUSPEND_STANDBY,  // 待机（浅度休眠）
    PM_SUSPEND_MEM,      // 挂起到内存（深度休眠）
    PM_SUSPEND_MAX       // 非法状态
};

struct suspend_stats {
    int success;
    int fail;
    int failed_suspend;
    int failed_resume;
    int failed_freeze;
    // ... 更多统计字段
};

你可能会问：PM Core怎么知道该先挂起哪个设备？答案是依赖关系。设备之间有父子关系、供电域关系，PM Core会按照拓扑顺序依次调用驱动的suspend回调。我曾经在一个项目中遇到过设备挂起顺序反了，导致某个外设在父设备断电后还在访问寄存器，直接挂死。从那以后，我每次写驱动都会仔细检查dev_pm_domain的配置。

PM QOS：服务质量与功耗的博弈

PM QOS的全称是Power Management Quality of Service。它解决的是一个很实际的问题：系统想省电，但应用层和设备层对性能有要求，怎么办？

举个例子：你正在播放视频，CPU想降频省电，但视频解码需要足够的算力。PM QOS就是那个仲裁者——它收集各个组件提出的约束条件，然后给出一个折中方案。

PM QOS主要管理三类约束：

约束类型	含义	典型场景
CPU_DMA_LATENCY	CPU从低功耗状态唤醒的最大延迟	音频播放需要低延迟响应
NETWORK_LATENCY	网络设备唤醒延迟	实时网络应用
CPU_FREQ_MIN	CPU最低运行频率	视频解码、游戏渲染

调试技巧：查看当前系统的PM QOS约束值：

# cat /sys/devices/system/cpu/cpu0/cpuidle/state*/latency
# cat /sys/power/pm_qos_resume_latency_us

如果发现某个约束值异常小（比如0），说明有进程在阻止系统进入深度休眠。可以用ftrace追踪是谁设置的。

PM QOS的实现其实不复杂。它维护了一个约束列表，每个约束有一个目标值和一个当前值。当某个组件提出新约束时，PM QOS会重新计算最小值，然后通知相关子系统调整策略。我建议你在调试功耗问题时，第一个检查的就是PM QOS——很多时候系统睡不深，就是因为某个驱动或应用设了一个过于严格的延迟约束。

Runtime PM：运行时动态电源管理

Runtime PM是Linux电源管理中最灵活、也最容易出问题的一块。它允许设备在不使用时自动进入低功耗状态，使用时自动唤醒。整个过程对用户空间透明，完全由内核和驱动管理。

Runtime PM的核心机制是引用计数：

pm_runtime_get()：增加引用计数，唤醒设备
pm_runtime_put()：减少引用计数，如果计数为0则尝试挂起
pm_runtime_autosuspend()：延迟挂起，避免频繁开关

我曾经踩过的坑：某个USB网卡驱动在pm_runtime_get后忘了对应的put，导致设备永远无法挂起。电池续航直接砍半。排查时发现引用计数一直为1，用下面的命令才定位到问题：

# cat /sys/devices/.../power/runtime_usage
# cat /sys/devices/.../power/runtime_status

记住：get和put必须成对出现，否则就是内存泄漏级别的bug。

Runtime PM的状态机也很清晰：

状态	含义	触发条件
RPM_ACTIVE	设备正常工作	引用计数 > 0
RPM_SUSPENDED	设备已挂起	引用计数 == 0，且满足挂起条件
RPM_SUSPENDING	正在挂起中	调用suspend回调
RPM_RESUMING	正在唤醒中	调用resume回调

sysfs与procfs接口：用户空间的窗口

sysfs和procfs是用户空间与内核电源管理交互的主要通道。我个人更常用sysfs，因为它结构清晰，每个设备一个目录，方便脚本处理。

sysfs关键接口：

/sys/power/
├── state              # 写入休眠状态：freeze/standby/mem
├── wakeup_count       # 唤醒事件计数
├── pm_async           # 是否启用异步挂起/恢复
├── pm_qos_resume_latency_us  # PM QOS唤醒延迟约束
└── image_size         # 休眠镜像大小限制（仅hibernate）

/sys/devices/.../power/
├── control            # 控制策略：auto/on/off
├── runtime_status     # 运行时状态：active/suspended
├── runtime_usage      # 运行时引用计数
├── runtime_active_time # 活跃时间统计
└── autosuspend_delay_ms # 自动挂起延迟

procfs接口（主要用于ACPI）：

/proc/acpi/
├── wakeup             # 查看/配置唤醒源
├── sleep              # 触发休眠（已废弃，建议用sysfs）
└── info               # ACPI信息

实用命令：

# 手动触发休眠
echo mem > /sys/power/state

# 查看哪些设备可以唤醒系统
cat /proc/acpi/wakeup

# 查看某个设备的Runtime PM状态
cat /sys/devices/platform/serial8250/power/runtime_status

# 设置自动挂起延迟为2秒
echo 2000 > /sys/devices/.../power/autosuspend_delay_ms

嗯，这里要注意一点：sysfs的接口在不同内核版本间可能有细微差异。比如3.x内核和5.x内核的PM QOS接口路径就不完全一样。我建议你在写自动化脚本时，先检查一下目标内核的文档，或者直接读内核源码——Documentation/power/目录下的文档写得还算清楚。

好了，Linux电源管理框架的三驾马车——PM Core、PM QOS、Runtime PM——我们已经走了一遍。它们各自负责不同的层面，但又紧密配合。PM Core管全局流程，PM QOS管约束仲裁，Runtime PM管设备级动态开关。再加上sysfs/procfs这个窗口，你就能从用户空间观察和控制整个电源管理行为。