1. 功耗管理的隐形裁判：PM QoS 到底在管什么
做过嵌入式 Linux 功耗优化的朋友大概率遇到过这种场景：系统明明已经进入 idle，CPU 该关的核也关了，但整机功耗就是比预期高出一截，怎么调都下不来。查了半天 CPUIdle、调了半天 OPP 表，最后发现是某个驱动在后台悄悄拉了一个约束，把系统死死钉在高性能状态上。这个"幕后黑手"，十有八九就是 PM QoS framework。
PM QoS，全称 Power Management Quality of Service，直译过来是"电源管理服务质量"。这个名字听起来有点抽象，但它的核心思想其实非常朴素：系统里不同的使用场景对延迟、吞吐、功耗有不同的要求，PM QoS 就是把这些要求量化、汇总、仲裁，然后告诉底层电源管理模块"现在到底该用多激进的省电策略"。举个生活化的例子，你家里的空调有个"舒适度"旋钮，有人要 26 度有人要 22 度，PM QoS 就是那个收集所有人诉求、最后拍板定一个温度的角色。
它解决的问题是：Linux 内核里电源管理策略（比如 CPUIdle 的 C-state 选择、CPUfreq 的调频、运行时的 PM runtime）如果各自为政，很容易出现"一个驱动想省电、另一个驱动要低延迟"的冲突。PM QoS 提供了一套统一的约束注册、聚合、通知机制，让所有参与者都能表达自己的需求，同时让决策者拿到一个全局最优的结论。
这篇文章适合谁看？如果你正在做嵌入式 Linux 功耗调优、Android 系统开发、或者单纯想搞明白内核里"为什么我的设备进不了深度睡眠"，那这篇梳理会帮你把 PM QoS 的框架脉络、关键数据结构、约束聚合逻辑、以及实际调试中踩过的坑一次性讲清楚。我会尽量用从业者的视角，把源码里的关键路径和实际调试经验揉在一起讲，而不是干巴巴地翻译文档。
2. 框架整体设计：为什么是"约束"而不是"命令"
2.1 从"命令式"到"约束式"的设计哲学
理解 PM QoS 的第一步，是理解它为什么采用"约束（constraint）"模型，而不是简单的"命令（command）"模型。
命令式模型长这样：某个驱动直接调用set_cpu_idle_state(deep)，告诉系统"我要进深度 idle"。这种模型的问题在于，多个驱动之间会互相覆盖，A 驱动刚设完，B 驱动又改回去，最后谁说了算完全看调用顺序，系统行为不可预测。
约束式模型则是：每个参与者只表达"我的需求边界"，比如"我要求 CPU 唤醒延迟不能超过 50 微秒"，至于最终系统选哪个 C-state，由 PM QoS 框架把所有约束聚合后统一决策。这样即使有十个驱动同时提要求，框架也能算出一个满足所有约束的最优解。这个思路和网络里的 QoS、实时系统里的优先级继承是一脉相承的。
提示：约束式设计的精髓在于"关注点分离"——需求方只管提要求，决策方只管算最优，双方通过框架解耦。这也是为什么 PM QoS 能同时服务于 CPUIdle、CPUfreq、PM runtime 等多个子系统。
2.2 两类约束：CPU 延迟约束与全局 QoS 约束
PM QoS 框架里的约束大致分两大类，理解这个分类是读懂源码的前提。
第一类是CPU 延迟约束（CPU Latency QoS），也叫 PM QoS latency。它主要服务于 CPUIdle 子系统，核心语义是"我要求 CPU 从 idle 状态唤醒的延迟不能超过某个值"。这个值越小，说明对响应速度要求越高，系统就只能选浅一点的 C-state；值越大，说明可以容忍慢唤醒，系统就能选更省电的深 C-state。CPUIdle governor 在做决策时，会读取当前聚合后的延迟约束，然后过滤掉那些唤醒延迟超标的 C-state。
第二类是全局 QoS 约束（Global QoS），通过/dev/cpu_dma_latency或者 per-device 的 QoS 接口暴露。它更通用，可以表达"设备级别的延迟容忍度"或者"系统级别的性能要求"。Android 里很多场景（比如音频播放、视频解码）就是通过这类接口来拉约束的。
这两类约束在实现上共享同一套核心数据结构struct pm_qos_constraints，但注册路径和聚合策略略有差异。下面这张表可以帮你快速建立印象：
| 约束类型 | 典型接口 | 主要服务对象 | 聚合方式 |
|---|---|---|---|
| CPU 延迟约束 | cpu_latency_qos_add_request | CPUIdle governor | 取最小值（最严格） |
| 全局 QoS 约束 | pm_qos_add_request | 设备驱动、用户空间 | 按类型取 min/max |
| per-device QoS | dev_pm_qos_add_request | 单个设备 | 设备级聚合 |
2.3 框架的分层结构
从代码组织上看，PM QoS 大致分三层。
最底层是核心聚合层，位于kernel/power/qos.c，负责维护约束链表、执行聚合算法、在约束变化时触发通知链（notifier chain）。这一层是纯逻辑，不关心具体是哪个子系统在用。
中间层是子系统适配层，比如 CPUIdle 通过cpu_latency_qos_*系列接口接入，PM runtime 通过dev_pm_qos_*接入。这一层把子系统的语义翻译成框架能理解的约束。
最上层是用户空间接口层，通过 sysfs、字符设备（如/dev/cpu_dma_latency）暴露给应用。Android 的 PowerHAL、音频服务就是通过这一层拉约束的。
这种分层的好处是：核心逻辑只写一遍，任何新子系统想接入，只要实现适配层即可。这也是为什么 PM QoS 能成为内核功耗管理里一个相对稳定的基础设施。
3. 核心数据结构拆解：约束是怎么被组织和聚合的
3.1 pm_qos_constraints：约束的容器
整个框架的核心是struct pm_qos_constraints，它定义在include/linux/pm_qos.h里。这个结构体承载了一个"约束集合"的全部信息，关键字段包括：
list：约束请求的链表头，所有通过pm_qos_add_request注册的请求都挂在这里。target_value：当前聚合后的目标值，也就是所有请求算出来的最终结果。default_value：默认值，当没有任何请求时使用。type：约束类型，决定聚合时是取最小值还是最大值。notifiers：通知链头，约束变化时用来通知订阅者。
理解这个结构的关键在于type字段。PM QoS 支持几种聚合类型，最常见的是PM_QOS_MIN（取所有请求里的最小值）和PM_QOS_MAX（取最大值）。为什么延迟约束要用 MIN？因为延迟是"越小越严格"，只要有一个请求要求 50 微秒，那系统就必须满足 50 微秒，不能被其他宽松请求"平均"掉。这个逻辑和"木桶效应"完全一致——最短的那块板决定水位。
3.2 pm_qos_request：一次约束注册
每次调用pm_qos_add_request，框架会分配一个struct pm_qos_request，里面记录了请求的值、所属的约束集合、以及链表节点。这个结构是请求方的"句柄"，后续更新或删除约束都要靠它。
这里有个容易踩的坑：pm_qos_request的生命周期必须由调用方保证。如果你在栈上分配一个 request 然后注册，函数返回后栈被回收，框架链表里就挂了一个野指针，后续聚合时直接 crash。我见过不止一个驱动犯这个错误，正确做法是用静态分配或者堆分配，并确保在模块卸载时调用pm_qos_remove_request。
3.3 聚合算法：update_target 的触发时机
约束聚合的核心函数是update_target（不同内核版本名字略有差异，有的叫pm_qos_update_target）。它的逻辑大致是：
- 遍历约束链表，根据
type算出新的target_value。 - 如果新值和旧值不同，更新
target_value。 - 触发通知链，把所有订阅者叫醒。
这里有个性能考量：聚合是 O(n) 的，n 是请求数量。在请求频繁变化的场景（比如音频每帧都更新延迟约束），这个开销不能忽视。所以内核里对通知链做了优化，只有值真正变化时才通知，避免无谓的唤醒。
注意：聚合算法本身很简单，但"什么时候触发聚合"是个设计难点。如果每次 add/update/remove 都全量重算，请求多的时候会有性能问题；如果做增量更新，又要处理各种边界情况。内核选择了"全量重算 + 值变化才通知"的折中方案，实测在几十个请求的量级下完全够用。
3.4 通知链：约束变化的广播机制
notifiers是一个标准的blocking_notifier_head。任何关心约束变化的模块都可以注册一个 notifier，在约束更新时收到回调。CPUIdle governor 就是通过这个机制感知延迟约束变化的——约束一变，governor 重新评估该选哪个 C-state。
通知链用的是 blocking 版本，意味着回调里可以睡眠。这点很重要，因为有些订阅者可能需要在回调里做比较重的操作（比如重新计算 idle 状态表）。但也正因为可以睡眠，回调里绝对不能持有自旋锁，否则会触发调度问题。
4. 实操路径：从注册约束到影响 CPUIdle 决策
4.1 用户空间拉约束：/dev/cpu_dma_latency 的用法
最直观的实操入口是/dev/cpu_dma_latency这个字符设备。用法很简单：打开设备，往里面写一个 32 位整数（单位微秒），这个值就作为延迟约束生效；关闭文件描述符，约束自动移除。
#include <fcntl.h> #include <unistd.h> #include <stdint.h> int main(void) { int fd = open("/dev/cpu_dma_latency", O_WRONLY); if (fd < 0) { return -1; } /* 要求唤醒延迟不超过 50 微秒，系统将避免进入深 C-state */ int32_t latency = 50; write(fd, &latency, sizeof(latency)); /* 在这里做对延迟敏感的工作，比如音频处理 */ /* 关闭 fd 自动移除约束 */ close(fd); return 0; }这段代码的意图很明确：在需要低延迟的窗口期内，把系统"钉"在浅 idle 状态，保证响应速度；窗口期结束就释放约束，让系统回到省电模式。Android 的音频 HAL 就是这么干的。
这里有个细节值得说：写进去的值是"最大可容忍延迟"，不是"期望延迟"。你写 50，意思是"我最多能忍 50 微秒"，系统会选一个唤醒延迟小于等于 50 的最深 C-state。写 0 表示"一点延迟都不能忍"，系统基本就停在 C0/C1 了。
4.2 内核驱动注册约束：cpu_latency_qos_add_request
驱动侧注册 CPU 延迟约束的标准姿势是：
#include <linux/pm_qos.h> static struct pm_qos_request my_latency_req; static int my_driver_probe(struct platform_device *pdev) { /* 注册一个 100 微秒的延迟约束 */ cpu_latency_qos_add_request(&my_latency_req, 100); return 0; } static int my_driver_remove(struct platform_device *pdev) { cpu_latency_qos_remove_request(&my_latency_req); return 0; }注意my_latency_req是静态分配的，生命周期覆盖整个驱动存活期。如果驱动运行中需要动态调整约束，调用cpu_latency_qos_update_request(&my_latency_req, new_value)即可。
老版本内核里这套接口叫pm_qos_add_request，参数里要显式传PM_QOS_CPU_DMA_LATENCY这个 class。新内核（5.x 之后）做了重构，把 CPU 延迟约束单独抽出来，接口更清晰，也避免了 class 参数传错的问题。如果你在维护老代码，迁移时要注意这个变化。
4.3 约束如何影响 CPUIdle 决策
约束注册完之后，它是怎么影响 CPUIdle 的？关键在 CPUIdle governor 的->select回调里。
以menugovernor 为例，它在决定进哪个 C-state 时，会调用cpu_latency_qos_limit()拿到当前的延迟约束值，然后遍历所有可用的 idle 状态，过滤掉exit_latency超过这个约束的状态。剩下的状态里再根据预测的空闲时间选最深的那个。
这个流程可以概括成一句话：PM QoS 提供"延迟上限"，governor 在这个上限内找"最省电的解"。两者职责清晰，互不越界。这也是为什么调功耗时，如果发现系统进不了深 idle，第一反应应该是查 PM QoS 约束，而不是去改 governor 参数。
4.4 一个完整的调试实例
假设你发现设备待机功耗偏高，怀疑是某个约束没释放。排查步骤可以这样走：
- 先看当前聚合后的延迟约束值。新内核可以通过 debugfs 查看，路径通常在
/sys/kernel/debug/pm_qos/或者通过cpu_latency_qos_limit()的导出接口。 - 如果约束值很小（比如 0 或个位数），说明有请求方拉着不放。
- 用
ftrace打开pm_qos_update_target相关的事件，观察约束变化的时间线，定位是哪个进程或驱动在频繁更新。 - 结合
cat /proc/*/fd找到持有/dev/cpu_dma_latency的进程。
我实际排查过一个案例：某设备待机时约束值一直是 0，最后发现是一个测试用的音频进程忘了关 fd，导致约束一直生效。这种问题用 ftrace 几分钟就能定位，比盲猜快得多。
5. 常见问题与排查技巧实录
5.1 约束不生效？先查这几个点
约束注册了但系统行为没变化，是新手最常遇到的问题。按优先级排查：
- 约束类型对不对：CPU 延迟约束要用
cpu_latency_qos_*，全局约束要用pm_qos_*，用错了接口约束不会进到 CPUIdle 的决策路径。 - 聚合类型对不对：延迟约束必须是 MIN 聚合，如果约束集合的 type 配错了，聚合结果可能完全不符合预期。
- 有没有订阅者：约束注册了，但如果没有 notifier 订阅，或者订阅者没在回调里重新决策，约束就是"死"的。
- 值有没有真的变化：如果新值和当前 target_value 相同，框架不会触发通知，看起来就像"没生效"。
5.2 常见问题速查表
| 现象 | 可能原因 | 排查手段 |
|---|---|---|
| 系统进不了深 idle | 有延迟约束拉着 | 查聚合约束值、ftrace 约束变化 |
| 约束注册后 crash | request 结构生命周期错误 | 检查是否栈分配、是否提前释放 |
| 约束值频繁抖动 | 请求方更新过于频繁 | ftrace 看更新频率，考虑合并更新 |
| 通知回调死锁 | 回调里持锁或睡眠不当 | 检查 notifier 回调的上下文 |
| 用户空间约束不释放 | fd 泄漏 | 查/proc/*/fd找持有者 |
5.3 几个只有踩过才知道的坑
坑一：约束的"粘性"。约束一旦注册，就会一直生效直到显式移除。很多驱动在 suspend/resume 路径里忘了重新评估约束，导致 resume 后约束状态和实际需求不符。建议在 resume 回调里主动检查并更新约束。
坑二：通知链的顺序。多个订阅者注册到同一个通知链时，回调顺序是不确定的。如果你的订阅者依赖另一个订阅者的结果，就会出问题。正确做法是让每个订阅者独立决策，不要有隐式依赖。
坑三：per-device QoS 和全局 QoS 的叠加。设备级约束和全局约束是分开聚合的，但最终都会影响系统行为。调试时要两个都看，别只盯着一个。
坑四：debugfs 的开关。PM QoS 的 debugfs 接口需要内核配置CONFIG_PM_QOS_DEBUG或者类似选项，很多发行版默认不开。调试前先确认配置，不然找不到接口会白折腾半天。
5.4 性能与精度的权衡
PM QoS 的聚合是实时的，请求越多开销越大。在请求数量很大的场景（比如几百个设备同时注册 per-device QoS），可以考虑：
- 合并同一模块内的多个约束，减少请求数量。
- 对不敏感的约束用较大的更新间隔，避免频繁触发聚合。
- 在热路径上避免频繁 add/remove，改用 update。
这些优化不是必须的，但在极端场景下能省下可观的 CPU 开销。我个人的经验是，请求数量在几十个以内时，完全不用操心性能；上百个之后再考虑优化。
6. 写在最后的一点个人体会
PM QoS 这个框架，代码量不大，但设计思想很值得琢磨。它用"约束聚合"这个简单的模型，解决了多个子系统争抢电源策略的复杂问题，而且扩展性很好——新子系统接入只需要实现适配层，核心逻辑一行不用改。
我在实际调功耗时最大的体会是：遇到"系统不进深睡眠"这类问题，先查 PM QoS，再查其他。因为约束是"显式"的，查起来有迹可循；而 governor 参数、OPP 表这些是"隐式"的，盲调容易越调越乱。把 PM QoS 的约束链路理清楚，很多功耗问题会迎刃而解。
另外提醒一句，不同内核版本的 PM QoS 接口差异不小，尤其是 5.x 之后对 CPU 延迟约束做了重构。移植代码或者查资料时，一定要先确认内核版本，别拿着老接口去对新内核，会浪费很多时间。
