小村软件有限公司
日本語 English 한국어 繁體中文 简体中文 العربية
联系我们
菜单

把 Windows 的「处理器计划」改成「后台服务」会发生什么 - 整理 quantum、优先级提升、P-Core／E-Core

· · Windows, 性能调优, 调度, 音频, CPU

「把应用切到后台就会爆音」 「把处理器计划改成后台服务之后就稳了」

在 Windows 上这类讨论一直都有。特别是音频、视频、测量、直播、常驻处理这类，UI 的流畅度不如持续处理重要的场景，特别在意这一点。

但这个设置并不是什么神奇的加速开关。它不是直接把 CPU 频率拉高的设置，也不是把应用变成 Windows 服务，更不是把线程钉死在 P-Core 上的设置。真正会变动的，是前台应用与后台处理之间 CPU 时间如何分配。

本文会把程序与后台服务各自改变的东西，与 Windows 调度器基础、quantum（时间片）、前台偏好，以及 P-Core／E-Core 处理器的行为串起来整理。

1. 先下结论

先把重点列出来：

  • 这个设置直接改变的是 CPU 时间的「分配方式」，而不是 CPU 的「马力」。
  • 程序 比较偏向照顾前台应用；后台服务 则偏向让前台与后台处理更均衡。
  • 因此，对于前台 UI 不是重点、后台持续处理的截止时间比较重要的工作负载，后台服务 可能会有效。
  • 不过在 P-Core／E-Core CPU 上，「要放在哪一种核心」的决策，现在更多是由 QoS、电源策略、hybrid scheduling、Intel Thread Director 这些机制决定。
  • 所以并不是设成 后台服务 就会变成「后台就丢 P-Core」「服务就丢 E-Core」这种简单的结果。
  • 如果音频爆音、丢音是来自 DPC／ISR、USB 省电、驱动、thermal throttling、EcoQoS，那光改这个设置是修不好的。

一句话总结，这个设置 不是 CPU 频率开关，而是排队规则的开关。

2. 这个设置到底在改什么

设置界面里的处理器计划，是 Windows 很久以前就有的调度策略之一，内部与 Win32PrioritySeparation 绑在一起，历史相当久。

先把 Windows 使用 CPU 的基本原则放在前面：

  • 调度器会先 从可运行的 thread 中挑优先级最高的。
  • 同优先级下，每次给一段固定时间轮流运行。
  • 这段「固定时间」就是 quantum（时间片）。
flowchart LR
    ready["可运行的 thread"] --> pick["调度器选出优先级最高者"]
    pick --> run["运行 1 个 quantum"]
    run --> wait{"同优先级是否有等待者"}
    wait -- yes --> switch["切换 context"]
    switch --> pick
    wait -- no --> run

处理器计划主要动到的，就是这里的 quantum 分配方式，以及 对前台的偏好程度。

这里说的 foreground，是当前用户正在操作的前台应用。反过来，被切到后台的应用、其他进程的 worker、Windows 服务、辅助进程、常驻处理等，会偏向 background 那一边。

要注意的是：选了 后台服务，并不代表你的应用就变成了 Windows 服务。改变的不是 是不是「服务」这个身份，而是 前台与后台的 CPU 分配规则。这个命名真的相当容易混淆。

3. 程序 与 后台服务 的差别

大致整理如下比较清楚：

观点 程序 后台服务
基本思路 偏向让前台应用体感更好 让前台与后台处理更均衡
前台偏好 强 减弱
CPU 吃紧时 UI 容易保持流畅 后台持续处理较不会被压住
较适合的场景 以交互为主的桌面操作 服务、采集、编码、持续处理
常见副作用 后台的截止时间较容易落后 前台 UI 的流畅感可能略下降

客户端 Windows 基本上是让前台应用运行更顺的取向。所以日常桌面操作用 程序 最自然。

不过下列这些场景就另当别论：

  • 后台一直要把缓冲填满的音频处理
  • UI 轻量，但有另一条 thread／另一个 process 在持续运行的采集或分析
  • 前台放着浏览器或 IDE，但希望后台处理仍能守住截止时间
  • 偏服务器、偏服务、偏常驻的工作负载

这种场景下，与其只强化前台偏好，让后台处理更容易抢回 CPU 反而比较稳。这种时候选 后台服务 就合理。

4. 为何音频与持续处理有时会有效

以音频爆音、丢音为例最好理解。

音频处理光「平均速度够快」不够，它要在 数毫秒、甚至更短的单位内，在必要的时机把缓冲填好。就算平均 CPU 用量不高，只要那个当下没跑成，就会爆音。

举例：

  • 前台是浏览器、DAW 的 UI 或别的应用
  • 后台的音频处理 thread 依固定周期运行，把缓冲填起来
  • 音频处理 thread 并没有特别高的优先级，也没有充分用到 MMCSS 或 QoS
  • CPU 大致上有点拥挤

这时候用 程序，前台应用容易连续跑比较久，后台的音频处理就会出现「平均没问题、刚好那一下慢了」的状况。长期下去就变 underrun，也就是爆音。

切到 后台服务 后，后台持续处理比较容易抢回 CPU，于是更不容易错过截止时间。

所以真正有效时，发生的并不是「CPU 变快」，而是：

  • 前台偏好被削弱一点
  • 后台持续处理插进来的频率与时机变好
  • 结果 deadline miss 变少

这样的路径。

5. 原理 - quantum 与前台偏好

再稍微往底层看，效力的脉络是这样。

5.1 quantum 越长，同优先级对手越会被挡住

当同优先级区段有多条 thread 在竞争时，某一条拿到越长的 quantum，别条就越容易等不到。

在前台偏好较强的设置下，foreground 比较容易连续跑一段；于是同优先级的 background 就更容易吃到「现在不是你」。

对于音频、视频、周期测量、轮询、监控这类 要一点一点、但要定期跑 的处理，这个差异就会显现出来。

5.2 Windows 对 foreground 本来就有多重偏好

Windows 本身对 foreground 就已经给了不少照顾，常见的有：

  • 切到前台的 process 的偏好
  • 接收输入的窗口所属 thread 的偏好
  • I/O 完成后 thread 的动态优先级提升（boost）

所以光把应用切离前台，调度的待遇就已经会变。后台服务 可以想成是 把前台偏好造成的 CPU 时间分配失衡拉回来一点，这样比较好理解。

5.3 「不要让 CPU 偷懒」一半对、一半偏

「不要让 CPU 偷懒」这种感觉上的说法能懂。就「后台处理不容易被压到后面」这一点来说也确实如此。

但准确一点说，改变的并不是 CPU 的 idle 控制或频率本身，而是 thread 被以什么顺序、用多长的时间片运行。

因此这个设置：

  • 并不是拉高 turbo boost
  • 并不是关闭 C-state
  • 并不是直接改 core parking
  • 并不是钉死 P-Core

6. 在 P-Core／E-Core CPU 上的效果

这里最容易被误解。

选 后台服务 并不会让 Windows 按「后台就丢 E-Core」、「服务就丢 P-Core」这样单纯分派。在现代 Windows，特别是 Windows 11 的 hybrid CPU 上，P-Core／E-Core 的选择是多层决策。

6.1 名字相近、其实是两回事

先点名两个名字相似但不同的东西。

  1. 处理器计划 的 后台服务
    • 旧版界面里的设置
    • 主要影响 foreground／background 的 CPU 时间分配
    • 属于 quantum 与前台 boost 的范畴
  2. QoS 的 Utility / Eco / Low 等
    • 现代 Windows 的 power／performance 分类
    • 也会影响 core 选择与频率控制
    • 与 P-Core／E-Core 的行为直接相关

这两个并不是同一件事。

6.2 Windows 11 的 QoS 与 visibility

现代 Windows 中，priority 之外，QoS 也会有影响。特别是在 heterogenous processor（也就是 P-Core／E-Core 结构）上，QoS 会决定 偏好哪一种核心。

粗略来看，Windows 11 有类似下列的分类：

状态／类别 QoS 的概念 对 P／E 核心的影响
前台且 focus 中的 windowed app High 偏高性能
有显示但非 focus 的 app Medium 居中
最小化／完全隐藏的 app Low 用电池时偏 efficient core
后台服务 Utility 用电池时偏 efficient cores
明确标记 EcoQoS 的处理 Eco 偏 efficient cores
带音频 deadline 的多媒体 thread Deadline 偏高性能

这里重点是 只是最小化，QoS 就可能改变。所以在配备 hybrid CPU 的笔记本电脑上：

  • 应用切离前台
  • 又最小化
  • 结果 QoS 下降
  • 更容易被放到 efficient core
  • 体感或截止时间恶化

这种流程会相当自然地发生。

6.3 Thread Director 与 hybrid scheduling

在 Intel 第 12 代以后的 hybrid CPU 上，Intel Thread Director 会向 OS 提供提示。Windows 11 会用这些提示把 P-Core／E-Core 的分派做得更聪明。

Windows 这边也有 heterogenous scheduling 的策略设置：

  • SchedulingPolicy
  • ShortSchedulingPolicy
  • ShortThreadRuntimeThreshold

这些在 Automatic 下，由 OS 依 QoS 与系统配置来决定。此外，其背后还有 processor power management 的 core parking engine 与 performance state engine 运作。

整体可以用下图的思路理解：

flowchart TD
    t["Thread"] --> p["Priority / dynamic priority"]
    t --> q["QoS (High / Medium / Low / Utility / Eco / Deadline)"]
    t --> v["Visibility / audible / input state"]
    t --> h["Hybrid scheduling policy<br/>SCHEDPOLICY / SHORTSCHEDPOLICY"]
    t --> td["Intel Thread Director hints<br/>Windows 11 on Intel hybrid"]
    v --> q
    p --> s["Windows scheduler + Processor Power Management"]
    q --> s
    h --> s
    td --> s
    s --> c["决定放在 P-Core / E-Core 与频率"]

7. 何时会有效、何时其实是别的问题

实务上建议先把「有效的场景」与「其实是别的问题」分开看。

7.1 容易有效的场景

下列场景中，后台服务 可能是个合理的对策：

  • 一把焦点切给前台应用，后台的持续处理就变不稳
  • CPU 使用率并没有饱和，但周期性处理只有它在 miss deadline
  • 重要处理位于 legacy app／helper process／worker thread，而且没有好好用 MMCSS 或 QoS
  • 服务或常驻处理才是主角，前台 UI 的流畅感反而不是重点

7.2 效果有限或根本是别的问题

反之，下列问题光调这个设置是不够的：

  • DPC／ISR 延迟偏大
  • USB 控制器或音频驱动的问题
  • USB selective suspend 或设备省电的影响
  • thermal throttling
  • battery saver、power throttling、EcoQoS 的影响
  • 缓冲区太小
  • 应用其实已经正确使用 MMCSS／Deadline，问题不在这里

尤其是 Windows 11 + hybrid CPU 的笔记本电脑，visibility 与 QoS 的变化 影响很大。若症状是「最小化后就糟」、「只有用电池时才糟」，怀疑 QoS／power 这一层会比怀疑处理器计划更容易命中。

8. 实务上的观察方式

实际拆分的顺序，建议如下：

  1. 固定条件
    • 接电源还是用电池
    • 电源模式
    • 缓冲区大小
    • 是前台／可见／最小化的哪一种
  2. 在相同条件下比较 程序 与 后台服务
    • 除了体感，也要记录 dropout 次数、glitch 次数、处理延迟
  3. 若是 Windows 11／hybrid CPU，先怀疑 QoS 这一层
    • 是不是只在最小化时恶化
    • 是不是取决于 audible 状态
    • 是不是只在电池模式才恶化
  4. 音频或视频要先看 MMCSS
    • 重要 thread 是否有让 Windows 知道「这有截止时间」
  5. 仍然没修好，就挖 DPC／ISR／USB／驱动
    • 这一层已经不是调度器能决定的事

实务上，「有没有赶上截止时间」比平均 CPU 使用率重要。这点很核心。

9. 总结

把处理器计划改成后台服务的效果，用比较精简的说法：

  • 改变的不是 CPU 的速度，而是前台与后台的 CPU 时间分配方式
  • 程序 偏向让前台应用流畅
  • 后台服务 让后台持续处理不容易被压住
  • 所以在音频、视频、采集、监控、常驻处理这类后台截止时间吃重的场景可能有效
  • 不过在 P-Core／E-Core CPU 上，实际 core 的配置更受 QoS、power policy、hybrid scheduling、Thread Director 影响
  • 也因此在现代 Windows 上，这个设置 有时候会有效，但不是单独的主角

总之，这是一个 改变工作分配的旋钮，不是放大 CPU 马力的旋钮。

把重点放在前台应用的流畅，或是后台持续处理的截止时间，看你怎么取舍；这个设置就是把天平往 background 那边挪一点。

到了 hybrid CPU 时代，这之上还叠着 QoS 与 P／E 核心选择的层级。把这些一起看，你就会清楚「为什么有时有效」、「为什么有时又没效」。

10. 参考资料

相关文章

共享相同标签的最新文章。可以围绕相近的主题进一步加深理解。

伪随机数与真随机数的区别 - 如何区分的整理

本文整理伪随机数与真随机数的区别，重点不在输出外观而在生成器结构：普通 PRNG 重视可重现性、CSPRNG / DRBG 主打不可预测性、NRBG 则以物理熵源为基础。文中说明种子（seed）与重新播种（reseed）、健康检测（health test）的作用，并给出信息...

阅读文章

常见问题

汇总了咨询这一主题时常见的问题。

把 Windows 的处理器计划改成「后台服务」会变快吗？
不会直接变快。这个设置改变的是 CPU 时间的分配方式，不是 CPU 的马力，它不会拉高 turbo boost、不会关闭 C-state、不会直接改 core parking，也不会把线程钉在 P-Core 上。「程序」偏向照顾前台应用，「后台服务」让前台与后台处理更均衡，所以对前台 UI 不是重点、后台持续处理的截止时间比较重要的工作负载才可能有效。
为什么改成「后台服务」有时能改善音频爆音？
因为音频处理要在数毫秒单位内于必要时机把缓冲填好，光平均速度够快不够。在「程序」设置下前台应用容易连续跑比较久，后台的音频处理就会出现「平均没问题、刚好那一下慢了」的状况，长期下去变成 underrun 爆音。切到「后台服务」后前台偏好被削弱一点，后台连续处理插进来的频率与时机变好，deadline miss 就变少。发生的不是 CPU 变快，而是排队规则改变。
设成「后台服务」会让程序被丢到 E-Core 吗？
不会这么单纯。这个设置属于 quantum 与前台偏好的范畴，而 P-Core／E-Core 的选择在 Windows 11 的 hybrid CPU 上是由 QoS、电源策略、hybrid scheduling、Intel Thread Director 等多层决策决定的。要注意的反而是窗口只是最小化，QoS 就可能下降，用电池时更容易被放到 efficient core，导致体感或截止时间恶化。
哪些性能问题不是改这个设置能解决的？
DPC／ISR 延迟偏大、USB 控制器或音频驱动的问题、USB selective suspend 或设备省电、thermal throttling、battery saver / power throttling / EcoQoS 的影响、缓冲区太小等，光调这个设置是不够的。特别是 Windows 11 加 hybrid CPU 的笔记本电脑，若症状是「最小化后就糟」「只有用电池时才糟」，怀疑 QoS／power 这一层会比怀疑处理器计划更容易命中。

作者简介

本文作者的个人简介页面。

Go Komura

小村软件有限公司 代表

以 Windows 软件开发、技术咨询与故障排查为中心，擅长难以复现的故障调查，以及既有资产仍在运行的项目。

联系我们
返回博客列表