做内核功耗/性能调优的朋友几乎都遇到过这种尴尬场景系统明明处于空闲状态某个外设却在报“中断响应超时、数据丢了”一类的问题。反过来音频、显示、USB这些模块对延迟和带宽又有硬需求而 cpuidle、cpufreq 又总想把系统往低功耗方向推。这两边的矛盾怎么协调Linux 从早期就给了个答案PM QoS framework一套把“需求侧约束”传遍整个电源管理决策链的机制。这一篇就专门把这个框架拆开来看从数据结构、聚合逻辑到实际用法和调试技巧都过一遍。很多同学管 PM QoS 叫“很薄的一层”这话对也不对。说它薄是因为它本身不负责具体行为只维护“约束值”说它不对是因为这层薄薄的协调机制挂在 cpuidle、cpufreq、设备 runtime PM、调度器等多个子系统的关键路径上一旦用错系统要么频繁进深睡导致延迟爆炸要么一直醒着功耗直线上升。这篇文章适合正在做 Linux 内核电源管理、音频低延迟、车载系统功耗优化的工程师参考也适合内核初学者把这套框架当成理解“子系统间如何优雅通信”的范本。1. PM QoS 框架到底解决什么问题1.1 把“需求”和“决策”解耦先想一个具体场景手机在播放音乐时音频线程要求中断响应延迟不能超过 100us此时系统如果没有限制cpuidle 可能会切入 C6/C7 这种深睡状态CPU 要几十到几百微秒才能醒来音频数据就出断流了。反过来如果一直锁住 CPU 不睡功耗又会明显上涨。PM QoS 的想法就是不要在每一个驱动里直接去 hack cpuidle 或者 cpufreq而是让驱动声明“我需要多少延迟/带宽”系统统一汇总这些需求然后 cpuidle、cpufreq 在决策时都参考这个汇总值。这样一来“需求侧”和“决策侧”彻底解耦音频驱动只管提需求不管 CPU 到底怎么睡cpuidle 也不用关心谁是调用方只看一个数字就行。这就是整个框架的核心设计思路也是它虽然代码量不大、却值得单独拉出来梳理的原因。1.2 三类约束对象与含义PM QoS 在全局层面维护的主要有三类约束看内核里的pm_qos_class定义最容易理解QoS 类型约束含义典型使用场景CPU_DMA_LATENCYCPU 响应中断/DMA 的最大延迟容忍值音频、串口、DMA 搬运、车载系统NETWORK_LATENCY网络收发路径的延迟上限网络设备、实时音视频推流NETWORK_THROUGHPUT网络吞吐需求下限高吞吐传输场景其中最常打交道的就是PM_QOS_CPU_DMA_LATENCY因为音频、外设这类模块对 CPU 续航状态最敏感。比如在 Android 上AudioFlinger或者 HAL 层通过写/dev/cpu_dma_latency来锁住 CPU 延迟保证低延迟播放VHAL、蓝牙、modem 相关驱动也都有类似操作。另外还有一类标志型约束比如PM_QOS_FLAG_NO_POWER_OFF用于阻止设备在某个状态下被断电。这类约束虽然不涉及数值但挂在同一个框架里管理原理大同小异。2. 核心链路请求、聚合与通知2.1 一次请求的生命周期PM QoS 约束从发起到生效大体走这么四步驱动/模块创建一个pm_qos_request对象调用pm_qos_add_request()把约束值加入对应约束类系统内部重新聚合目标值并通知注册过的客户端需求变化时调用pm_qos_update_request()更新用完后pm_qos_remove_request()移出。内核侧的使用形态非常朴素一个典型的添加请求代码长这样static struct pm_qos_request audio_qos_req; static void audio_qos_activate(void) { pm_qos_add_request(audio_qos_req, PM_QOS_CPU_DMA_LATENCY, 100); } static void audio_qos_deactivate(void) { pm_qos_remove_request(audio_qos_req); }如果后续要动态调整就调用pm_qos_update_request(audio_qos_req, 500);这套 API 在 2.6.x 时代就有了后续版本虽然内部实现改过几轮但使用模型一直是“ add 一个请求 → update 数值 → remove 请求”的套路。很多刚接触内核的读者会觉得这无非是“往链表里塞个节点”但其实关键在于第二步系统是怎么把多个请求聚合成一个目标值的。2.2 数据结构里的两件套plist notifierPM QoS 内部最核心的结构是struct pm_qos_constraints它管理三样东西请求链表、目标值、通知链。请求链表用的不是普通 list而是优先队列。原因很简单系统每次聚合约束时都要快速拿到“最严格”的请求如果用普通链表每次都要 O(n) 扫一遍用 plist 之后插入时按数值排好序取最值就是 O(1)。通知链用的是 blocking notifier一旦目标值发生变化系统要把新目标值广播给所有关心它的模块。比如cpuidle关心 CPU 延迟约束它注册一个回调函数当目标值变小更严格或者变大更宽松时就重新计算可选的 C-state。一个简化版的pm_qos_constraints结构可以理解为struct pm_qos_constraints { struct plist_head list; /* 所有请求按值排序 */ s32 target_value; /* 聚合后的目标值 */ s32 default_value; /* 无请求时的默认值 */ enum pm_qos_type type; /* PM_QOS_MIN / PM_QOS_MAX */ struct blocking_notifier_head notifiers; };2.3 聚合算法为什么一定取“最严格”这是理解 PM QoS 的关键。假设有三个进程请求了三个不同的 CPU 延迟约束进程 A2000us进程 B100us进程 C500us聚合结果是多少是 100us。理由非常直觉系统必须满足所有请求中最苛刻的那一个。因为延迟约束是上界只要能满足最严格的 100us那 2000us 和 500us 的要求自然都能满足但如果取 500us进程 B 就先炸了。所以延迟类约束按“最小值”聚合也就是 plist 里排最前面的值。在通知其它模块时这个target_value就是它们唯一参考的数字。cpuidle看到它就知道不能选择“唤醒时间超过这个值”的 C-state。这里有个容易混淆的点type字段。延迟约束是“越小越严格”所以 type 是PM_QOS_MIN而网络吞吐这类“必须不小于某个值”的约束type 才是PM_QOS_MAX。设计上为了统一处理框架内部会按 type 决定取列表头部还是尾部但业务层你不用关心排序方向只要理解最终值一定是最不利、最严格的那一个。3. 内核各模块怎么配合 PM QoS3.1 cpuidle 的 C-state 选择cpuidle子系统是 PM QoS 最大的消耗者。在menugovernor 选择 C-state 时会读取当前的 CPU 延迟约束把它作为硬条件过滤掉唤醒时间超标的浅睡状态。举个例子。当前 CPU 延迟约束是 50usmenu governor 扫描可用的 C-stateC-state退出延迟是否可用C11us可用C230us可用C3150us不可用C6500us不可用于是 CPU 最多只能进 C2哪怕 C6 能省更多功耗。没有 PM QoS 时驱动只能通过acpi_idle或直接禁 C-state 的方式硬设既笨又不灵活。实际项目里常见的坑是某个驱动长期持有一个过严的延迟约束忘了释放比如一直锁着 10us那 CPU 基本就只能停留在 C1/C2待机功耗高出几倍。这类问题不是“驱动功能坏了”而是“QoS 约束脏了”。3.2 cpufreq 和调度器为何也要看它PM QoS 不只是 cpuidle 在用。cpufreq在某些策略下也会参考 QoS 约束特别是涉及到最高频率限制、boost 开关、以及特定调度负载需求的场景。比如系统要求网络低延迟调度器为了保证 CPU 不因频率爬升太慢而丢包可能就不允许降到最低频率。另外在较新的内核里调度器的唤醒逻辑也会关注设备级 QoS。schedutil调度器根据当前负载决定频率时如果系统处于“低延迟约束”状态它会更积极地拉升频率。这其实体现了 CPU 频率与响应延迟之间“上游需求传导到下游参数”的关系。这里多说一句PM QoS 并不是直接告诉cpufreq必须跑多快而是提供一个约束基线。频率决策仍然由 governor 根据负载完成只是这个基线会影响 governor 的预算。理解这个边界很重要否则排查功耗问题时容易把两个子系统混为一谈。3.3 设备级 PM QoSdev_pm_qos除了全局的三类约束PM QoS 还有一套设备级机制叫dev_pm_qos。它解决的场景更细某个设备在 runtime PM 过程中什么时候允许进入低功耗、什么时候必须保持可快速唤醒。设备级 QoS 的请求类型主要有请求类型作用DEV_PM_QOS_RESUME_LATENCY设备恢复运行的最大延迟DEV_PM_QOS_LATENCY_TOLERANCE设备可容忍的延迟上限DEV_PM_QOS_FLAGS控制设备电源状态标志最常见的用法是DEV_PM_QOS_RESUME_LATENCY。比如一个磁盘控制器如果它挂起后要 200ms 才能恢复但上层文件系统要求 50ms 内必须能继续 I/O那系统就不能让该设备进入深度挂起。驱动可以这样请求struct dev_pm_qos_request resume_qos; dev_pm_qos_add_request(pdev-dev, resume_qos, DEV_PM_QOS_RESUME_LATENCY, 50);设备级 QoS 与全局 QoS 的差别在于作用对象全局 QoS 影响 CPU/网络的总体行为设备级 QoS 只作用于单个设备。但两者共享同一套“请求-聚合-通知”模型理解了全局机制设备级机制也就没什么新大陆了。4. 实操驱动与用户态怎么用4.1 内核驱动使用示例实际写驱动时PM QoS 三个 API 基本就够用pm_qos_add_request、pm_qos_update_request、pm_qos_remove_request。以音频 DMA 驱动为例典型流程是打开音频流时添加一个 100us 的 CPU 延迟约束播放中根据音频数据量动态调整约束值关闭音频流时移除约束。代码样式如下#include linux/pm_qos.h static struct pm_qos_request audio_latency_req; void audio_stream_start(void) { pm_qos_add_request(audio_latency_req, PM_QOS_CPU_DMA_LATENCY, 100); } void audio_stream_update(u32 latency_us) { pm_qos_update_request(audio_latency_req, latency_us); } void audio_stream_stop(void) { pm_qos_remove_request(audio_latency_req); }这里有一个必须强调的点pm_qos_add_request不是为了“主动加速”而是为了“承诺延迟上限”。它只影响低功耗策略并不会直接压榨 CPU 性能。如果驱动把它误解成“我要高性能”就会在不需要低延迟的场景里误锁约束造成无谓功耗。4.2 用户态节点与 sysfs内核态之外PM QoS 也给用户空间开放了访问入口最常见的就是/dev/cpu_dma_latency。传统用法是打开这个节点直接写入一个延迟值int fd open(/dev/cpu_dma_latency, O_WRONLY); int32_t latency 100; /* 微秒 */ write(fd, latency, sizeof(latency)); /* 保持 fd 打开约束就持续生效 */注意关键点只要 fd 不关闭约束就存在一旦进程退出或关闭 fd这个约束立刻消失。很多人写过类似代码却没意识到 fd 的生命周期和 QoS 约束绑定导致“为什么我的进程退出了系统还保持低延迟”或者反过来“为什么我明明写了值却失效了”。设备级 QoS 在 sysfs 里也有暴露路径一般是/sys/devices/.../power/pm_qos_resume_latency_us /sys/devices/.../power/pm_qos_latency_tolerance_us直接往这些文件里写值等同于从用户态添加一个设备级约束。这在调试设备电源状态时非常实用不用改驱动快速验证设备能不能在指定延迟内恢复。4.3 典型场景组合低延迟音频 深睡策略真实项目里往往不是单一约束而是多个约束叠加。以车载系统为例音频路径请求CPU_DMA_LATENCY 80us保证音频数据不欠载显示屏刷新的某个 DMA 请求CPU_DMA_LATENCY 200us后台下载任务请求NETWORK_THROUGHPUT 200Mbps。最终 CPU 延迟约束取 80us因为音频最苛刻其它模块都跟着受益网络吞吐则单独聚合。整体状态就是CPU 可以浅睡但不能深睡网络路径不能进入节能模式其余模块可以正常挂起。这种“浅睡 其它模块照常入睡”的状态正是 PM QoS 追求的效果需求侧互不干扰系统整体功耗又不会因为某一模块的特殊需求而全盘失控。5. 路上踩过的坑与排查技巧5.1 约束“凭空消失”是为什么很多人排查功耗时遇到过自己明明在用户态写入了/dev/cpu_dma_latency但 cpuidle 的 C-state 还是选得很深。第一个动作应该是确认写入进程还活着、fd 还开着。因为用户态 QoS 请求是跟随 fd 生命周期的进程崩溃或被 kill 后请求自动销毁系统恢复正常策略。反过来谁持有了过严约束、导致 CPU 无法深睡排查方法是一样的查哪个进程打开着/dev/cpu_dma_latency或者在内核侧注册了未释放的pm_qos_request。5.2 把约束语义搞反前面说过延迟类是取“最小值”聚合而网络吞吐这类取“最大值”。实际项目里见过有人把 CPU 延迟请求写成很大值比如 5000us以为“数字越大越好”结果系统只给一个非常宽松的响应保障音频还是断流。正确理解对于延迟约束写入值越小系统越“精神”写入值越大系统越“放任”。音频低延迟要写小值比如 50~200us如果想恢复默认行为写一个远大于默认的值比如 2000us 以上大多数系统就会表现得很“亲民”。5.3 排查与观测手段PM QoS 的调试要看两个层面全局约束和单个设备约束。内核侧可以通过trace-cmd或perf trace观察pm_qos_update_target、pm_qos_add_request的调用流程。比如想知道哪个驱动在动态改 QoS直接 tracepm_qos_update_request相关函数再按调用栈定位模块。设备级约束可以看 sysfs 下的power相关目录也可以在内核里打开CONFIG_PM_DEBUG和CONFIG_PM_ADVANCED_DEBUG通过 debugfs 观察设备电源状态与 QoS 参数。实测下来最常用的手段其实是动态打印在目标驱动的runtime_suspend和runtime_resume加上dev_dbg()配合 QoS 值变化很快能推断出是谁在限制设备挂起。5.4 一个容易漏掉的细节notifier 回调里别睡pm_qos_add_request导致约束变化时会同步回调所有注册的 notifier。这些回调里的逻辑一定要短平快不能做耗时操作更不能睡眠。原因很简单这个函数可能运行在中断上下文或者非常苛刻的原子上下文里。如果回调里用了 mutex、睡眠、IO 操作轻则系统死锁重则直接崩溃。实际写代码时如果回调逻辑较复杂建议把工作丢进schedule_work或者timer延后处理。5.5 从功耗角度反推 QoS 是否“脏”最后分享一个实用技巧。在项目调试阶段我都会给测试镜像里放一个小工具统计一段时间内全局 CPU 延迟约束的最大值、最小值和持续时长。如果发现最小值长期存在就该去查谁持有这个约束。很多功耗问题追根溯源都是“某个模块升级后忘了释放 PM QoS 请求”而不是 cpuidle 或 cpufreq 本身的算法出了问题。我个人的习惯是在关键驱动里为 QoS 请求增加 trace 或 debugfs 导出记录每次 add/update/remove 的调用点。成本很低但排查线上问题时能少熬好几个夜。PM QoS 这个框架说简单也简单说重要是真重要它把“省多少电”和“响应多快”的博弈压缩成了几个简洁的数值理解它之后你再去看 cpuidle 和 cpufreq 的代码很多看似奇怪的行为都能顺理成章地解释了。
