Windows 的处理器计划设置 - 后台服务与 P 核 / E 核

“把应用移出前台就会出现爆音” “把 处理器计划 改成 后台服务 之后就稳定了”

在 Windows 上，这类说法从很早以前就有。尤其是音频、视频、测量、直播、常驻处理这类比起 UI 更看重持续处理的场景，人们会格外在意。

不过，这个设置并不是什么神奇的加速开关。它既不是直接提高 CPU 频率的设置，也不是把应用变成 Windows 服务的设置，更不是把线程固定到 P 核上的设置。真正改变的，主要是前台应用与后台运行的处理之间如何分配 CPU 时间。

flowchart TB
    accTitle: 这个设置改变的东西
    accDescr: 表示处理器计划设置既不是提高频率，也不是把应用变成服务或把线程固定到 P 核上，而是改变前台应用与后台处理之间 CPU 时间分配方式的图。
    st1["处理器计划设置"] -.->|"这些都不会改变"| notx["频率、服务化、固定核心"]
    st1 -->|"改变的是"| shr1["前台与后台的 CPU 时间分配方式"]

图1：不要把它当成加速开关，而要当成切换 CPU 时间分配方式的设置来读。

本文会把 程序 与 后台服务 各自改变了什么，与 Windows 调度器的基础、quantum（时间片）、对 foreground 的优待，以及带 P 核 / E 核的 CPU 的行为串起来梳理。

1. 先说结论

先把要点列出来。

• 这个设置直接改变的，与其说是 CPU 的“马力”，不如说是 CPU 时间的“分配方式”。
• 程序 容易偏向照顾前台应用，后台服务 则偏向让前台与后台的处理更均衡。
• 因此，在比起前台 UI 更看重后台持续处理截止时间的工作负载上，后台服务 有时会有效。
• 不过在 P 核 / E 核 CPU 上，“线程放到哪种核心上”如今不只取决于这个设置，QoS、电源策略、hybrid scheduling、Intel Thread Director 等机制的影响更强。
• 也就是说，改成 后台服务 并不会变成“后台处理就去 P 核”“服务就去 E 核”这么简单的事。
• 如果音频爆音或 dropout 来自 DPC / ISR、USB 省电、驱动程序、thermal throttling 或 EcoQoS，光靠这个设置修不好。

一句话概括，这个设置 不是 CPU 的频率设置，而是改变排队规则的设置。

flowchart TB
    accTitle: 有效与无效的大致范围
    accDescr: 表示对后台持续处理的截止时间重要的工作负载，后台服务一侧有时会有效，而放到 P 核还是 E 核上则更多由 QoS 和电源策略等机制决定的图。
    bgss1["后台服务一侧"] -->|"有时会有效"| dl1["后台持续处理的截止时间"]
    bgss1 -.->|"由别的机制决定"| core1["P 核 / E 核的选择"]
    core1 --> qos1["QoS、电源策略、hybrid scheduling"]

图2：对截止时间可能有效，但核心选择由这个设置之外的机制决定。

1.1 先要理解的术语

本文开头就会出现一些要读到第 6 章前后才讲清楚实体的术语，先在这里汇总。

图中实线表示始终成立的关系，虚线表示带条件的关系（成立条件写在详情页各关系的说明中）。关系的完整列表（共 18 条，附依据与确信度）以及主要概念的定义，汇总在知识地图详情页（日文）。数据：JSON-LD / Turtle

2. 这个设置到底改变了什么

设置界面里的 处理器计划，是 Windows 由来已久的调度策略之一。它在内部与 Win32PrioritySeparation 绑定，历史相当悠久。

这里首先要理解的，是 Windows 使用 CPU 时的基本原则。

• 调度器会先 从可运行的线程中挑出优先级最高的那个。
• 优先级相同时，就 每次运行一段固定时间轮流执行。
• 这段“固定时间”就是 quantum（时间片）。

flowchart LR
    ready["可运行的线程"] --> pick["调度器挑出优先级最高的线程"]
    pick --> run["运行 1 个 quantum"]
    run --> wait{"是否有同优先级的等待线程"}
    wait -- yes --> switch["上下文切换"]
    switch --> pick
    wait -- no --> run

图3：调度器挑出优先级最高的线程，每次运行 1 个 quantum 轮流执行。

处理器计划 主要动的，就是这里的 quantum 分配方式，以及 对 foreground 优待到什么程度。

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

重要的是，即使选了 后台服务，自己的应用也不会因此变成 Windows 服务。改变的不是 叫作服务的那种身份，而是 foreground 与 background 的 CPU 分配规则。这里的命名确实相当容易混淆。

flowchart TB
    accTitle: 后台服务这个名字容易引起的误解
    accDescr: 表示即使选择后台服务，自己的应用也不会变成 Windows 服务，改变的只是 foreground 与 background 的 CPU 分配规则的图。
    sel2["选择后台服务"] -.->|"不会变成这样"| svcx["应用变成 Windows 服务"]
    sel2 -->|"改变的是"| rule1["前台与后台的 CPU 分配规则"]

图4：与名字给人的印象相反，改变的不是进程的种类，而是分配规则。

2.1 打开设置界面的路径

这个设置藏在控制面板相当深的位置。到达路径有 2 条。

• 通过 Win + R 运行 SystemPropertiesPerformance.exe，会直接打开“性能选项”。处理器计划 就在它的“高级”选项卡里。
• 如果要手动一层层点，顺序是“系统属性”>“高级”选项卡>“性能”的“设置”>“高级”选项卡。“系统属性”本身可以用 sysdm.cpl 打开。

选择的结果会写入注册表中的下列值。

如果只想确认当前值，用 PowerShell 就能读到。为了随时能改回去，修改前先记下原值比较稳妥。

flowchart TB
    accTitle: UI 中的选择与注册表的关系
    accDescr: 表示在性能选项界面中选择的结果会写入 Win32PrioritySeparation 这个注册表值，当前值可以用 PowerShell 读取，因此先记下修改前的值再动手的流程图。
    uix2["在 UI 中选择"] --> regw1["写入 Win32PrioritySeparation"]
    regw1 --> pr1["可以用 PowerShell 读取当前值"]
    pr1 -.-> keep2["先记下修改前的值再改"]

图5：UI 中选择的实体就是注册表值，动手之前先记下当前值。

Get-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\PriorityControl' -Name 'Win32PrioritySeparation'

2.2 适用的 Windows 版本与值的含义

“性能选项”里的 处理器计划，在 Windows 10 / Windows 11 客户端和 Windows Server 上都有。不过，同一个值在客户端和服务器上的解释并不相同，这正是这个设置难懂的地方。

在 Microsoft 的注册表说明中，Win32PrioritySeparation 被解释为把 6 个位每 2 位分成 3 组（AABBCC）的位掩码。

• 高 2 位：quantum 偏长还是偏短
• 中 2 位：quantum 是可变还是固定
• 低 2 位：foreground 比 background 优待多少倍（只有可变时才生效）

在此基础上，文档说明 UI 中的选择会分别写入下列值（当时 UI 上的写法是 Applications 与 Background services，对应现在的 程序 与 后台服务）。

再往数值上深入一步。Microsoft 的解说文章中说明，0x26 时 foreground 的 quantum 是 18、background 是 6，0x18 时两者都是 36。quantum 以 clock tick 的三分之一为单位，换算成 tick 就是 前台 6 tick / 后台 2 tick 与 两者都是 12 tick。同一篇文章还举了 x86 多处理器机器上 clock tick 为 15.625 毫秒的例子，这种情况下二者的差别就是“前台最多连续运行约 94 毫秒的设置”与“前台和后台各运行约 188 毫秒的设置”。

也就是说，后台服务 一侧是 单次运行的时间更长，但不只偏袒前台 的分配方式。后台处理不容易陷入“轮不到自己”的状态。

flowchart TB
    accTitle: 两种设置下 quantum 的分配方式
    accDescr: 表示程序设置下前台是 6 tick、后台是 2 tick，前台运行得更久；后台服务设置下两者各 12 tick，单次运行时间更长但不只偏袒前台的图。
    pg1["程序设置"] --> fg6["前台 6 tick、后台 2 tick"]
    bg2["后台服务设置"] --> eq12["前台和后台都是 12 tick"]
    eq12 --> nofam1["后台不容易陷入轮不到自己的状态"]

图6：一边让前台运行得更久，另一边把更长的时间片均等地分配出去。

另外，对这个默认值的解释也存在操作系统差异。Microsoft 关于 Win32_OperatingSystem 的说明中写道，客户端 Windows 默认是 可变长 quantum，且前台应用的 quantum 更长，Windows Server 默认是 固定长 quantum。注册表说明一侧也写着，同一个默认值 0x2 在客户端表示“偏短、可变、前台 3 倍”，在服务器上表示“偏长、固定、均等”。服务器一开始就偏向相当于 后台服务 的设置，原因就在这里。

flowchart TB
    accTitle: 同一个默认值在客户端与服务器上解释不同
    accDescr: 表示同一个默认值在客户端 Windows 上被解释为偏短、可变、前台 3 倍，在 Windows Server 上被解释为偏长、固定、均等，因此服务器一开始就偏向相当于后台服务的设置的图。
    dv1["同一个默认值"] -->|"客户端"| cl2["偏短、可变、前台 3 倍"]
    dv1 -->|"服务器"| sv4["偏长、固定、均等"]
    sv4 -.-> lean1["一开始就相当于后台服务"]

图7：分出默认解释的不是值本身，而是操作系统这一侧。

这里列出的具体数值，基于 Windows 2000 / XP 时代的 Microsoft 文档和解说文章。注册表值与 UI 的对应关系至今相同，但实际的 quantum 处理方式可能随操作系统版本变化，所以请把这些数值当作“大致是什么量级”的参考来读。

3. 程序 与 后台服务 到底有什么不同

两者的差别，用表格对照着看比较清楚。

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

另一方面，也有情况不同的场景。

• 在后台一直不断填充缓冲的音频处理
• UI 很轻，但在另一个线程 / 另一个进程中持续运行的采集或分析
• 前台开着浏览器或 IDE，但仍希望守住后台处理的截止时间
• 偏服务器、偏服务、偏常驻的工作负载

这种时候，与其只强烈优待 foreground，不如让后台处理更容易抢回 CPU 更稳定。从这个意义上说，后台服务 有时是合理的。

flowchart TB
    accTitle: 哪种分配方式更合适
    accDescr: 表示以交互为主的桌面操作适合偏向前台的程序设置，而后台持续处理的截止时间更重要时，让后台更容易抢回 CPU 的后台服务设置更合理的图。
    wl1["工作负载的性质"] -->|"以交互为主的操作"| pgn1["程序更自然"]
    wl1 -->|"后台的截止时间更重要"| bgn1["后台服务是候选"]
    bgn1 --> back2["后台处理更容易抢回 CPU"]

图8：要守住前台的顺滑感还是后台的截止时间，决定了该选哪一边。

4. 为什么在音频和连续处理上有时会有效

以音频爆音和 dropout 为例最好理解。

音频处理光靠“平均速度够快”是不够的。它需要以数毫秒、甚至更短的单位，在必要的时机之前把缓冲填满。即使平均 CPU 使用率很低，只要恰好在那一瞬间跑不上，就会出现爆音。

举一个具体的情形。

• 前台是浏览器、DAW 的 UI 或别的应用
• 后台的音频处理线程按固定周期运行，负责供给缓冲
• 音频处理线程的优先级并不算高，MMCSS 和 QoS 也没有用充分
• CPU 有些拥挤

这时如果是 程序，前台应用一侧容易连续运行较久，后台的音频处理就可能出现“平均没有问题，偏偏那一瞬间慢了”的情况。这种情况持续下去就会变成 underrun，进而听到爆音。

反过来切到 后台服务，后台的持续处理更容易抢回 CPU，也就更不容易错过截止时间。

也就是说，有效的时候发生的并不是“CPU 变快了”，而是

• 前台应用的优待稍微减弱
• 后台持续处理能插进来的次数与时机得到改善
• 结果 deadline miss 减少

这样一条链路。

flowchart TB
    accTitle: 爆音减少的过程
    accDescr: 表示程序设置下前台连续运行较久，后台的音频处理偏偏在那一瞬间延迟而出现 underrun；切到后台服务后前台优待被削弱，后台更容易插进来，deadline miss 随之减少的图。
    fgl1["前台连续运行较久"] --> late1["音频处理偏偏在那一瞬间延迟"]
    late1 --> ur1["underrun 造成爆音"]
    even2["把分配方式往均等一侧调"] --> take1["后台更容易插进来"]
    take1 --> less1["deadline miss 减少"]

图9：有效的时候不是 CPU 变快了，而是后台处理赶上了截止时间。

5. 原理 - quantum 与对 foreground 的优待

再往底层看一点，生效的脉络是这样的。

5.1 quantum 越长，同优先级的对手越容易被拖住

当同一优先级区间内有多条线程竞争时，某一条线程拿到的 quantum 越长，其他线程就相应地越容易等待。

在优待前台应用的设置下，foreground 一侧更容易连续运行较久。于是优先级相近的 background 一侧，就会相应地更容易吃到“现在还轮不到你”。

对于音频、视频、周期测量、轮询、监控这类 哪怕每次一点点也要定期运行 的处理，这个差别很关键。

flowchart TB
    accTitle: 长 quantum 会让同级对手等待
    accDescr: 表示同一优先级区间内有多条线程竞争时，一方拿到的 quantum 越长，其他线程越容易被拖住，越是想定期运行的处理受到的影响越明显的图。
    comp1["在同一优先级区间竞争"] --> long1["一方拿到较长的 quantum"]
    long1 --> wt2["其他线程容易被拖住"]
    wt2 -.-> perio1["越是要定期运行的处理差别越明显"]

图10：quantum 的长度会原封不动地反映为同级竞争对手的等待时间。

5.2 Windows 会以多种方式照顾 foreground

Windows 本来就对 foreground 相当照顾。具有代表性的有这些。

• 对切到前台的进程的优待
• 对拥有接收输入窗口的线程的优待
• I/O 完成后对线程的动态优先级提升

也就是说，仅仅把应用移出前台，它在调度上的待遇就会明显变化。可以把 后台服务 理解为：在这些 foreground 优待中，特别是把 CPU 时间分配的偏斜 缩小的方向。

flowchart TB
    accTitle: Windows 照顾 foreground 的几种方式
    accDescr: 表示 Windows 通过优待切到前台的进程、优待拥有接收输入窗口的线程、I/O 完成后的动态优先级提升等多种方式照顾 foreground，因此仅仅把应用移出前台待遇就会变化的图。
    fgc1["优待前台进程"] --> chg2["仅仅移出前台待遇就会变"]
    fgc2["优待接收输入的窗口线程"] --> chg2
    fgc3["I/O 完成后的动态提升"] --> chg2
    chg2 -.-> shrink1["这个设置作用于缩小分配的偏斜"]

图11：前台优待是多种机制的叠加，这个设置只作用于其中的分配偏斜。

5.3 “不让 CPU 偷懒”一半说对了，一半有偏差

“不让 CPU 偷懒”这种说法，从感觉上是能理解的。就“后台处理不容易被推到后面”这一点而言确实如此。

不过，技术上说得更准确一些会更好：实际改变的与其说是 CPU 的空闲控制或频率本身，不如说是 线程以什么顺序、运行多长时间。

所以这个设置：

• 不是提高 turbo boost 的设置
• 不是关闭 C-state 的设置
• 不是直接改变 core parking 的设置
• 不是固定到 P 核的设置

flowchart TB
    accTitle: 不让 CPU 偷懒的准确含义
    accDescr: 表示这个设置实际改变的不是 CPU 的空闲控制或频率，而是线程以什么顺序、运行多长时间，它不是 turbo、C-state、core parking 或固定核心的设置的图。
    sabo1["不让 CPU 偷懒这种感觉"] -->|"实际改变的是"| ord2["运行的顺序与时长"]
    sabo1 -.->|"不会改变的是"| pw2["turbo、C-state、core parking、固定核心"]

图12：“不让 CPU 偷懒”的实质不是电源控制，而是顺序与持有时间的改变。

6. 在 P 核 / E 核 CPU 上怎么生效

这里是最容易被误解的地方。

改成 后台服务，并不代表 Windows 就会简单地判断“是后台处理所以去 E 核”“是前台所以去 P 核”。在现代 Windows，尤其是 Windows 11 的 hybrid CPU 上，P 核 / E 核的选择要经过更多层。

6.1 名字相似，其实是两回事

首先，有两个名字相似但完全不同的东西。

1. 处理器计划 的 后台服务
   • 旧界面里的设置
   • 主要作用于 foreground / background 的 CPU 时间分配
   • 属于 quantum 与 foreground boost 这一系
2. QoS 的 Utility / Eco / Low 等
   • 现代 Windows 的 power / performance 分类
   • 也会影响 core 选择与频率控制
   • 更直接地关系到 P 核 / E 核的行为

这两者并不是同一件事。

flowchart TB
    accTitle: 名字相似的两回事
    accDescr: 表示处理器计划是旧界面里的设置，作用于 quantum 与 foreground 优待这一系；QoS 是现代 Windows 的 power / performance 分类，作用于核心选择与频率控制，两者并不相同的图。
    old2["处理器计划设置"] --> qt1["quantum 与 foreground 优待这一系"]
    newq1["QoS 的分类"] --> cs2["核心选择、频率控制这一系"]
    old2 -.->|"并不相同"| newq1

图13：名字给人的感觉相似，但它们起作用的层次完全不同。

6.2 Windows 11 的 QoS 与 visibility

在现代 Windows 中，不只是 priority，QoS 也会起作用。特别是在 heterogenous processor，也就是 P 核 / E 核这样的结构上，QoS 会影响 偏好哪一种核心。

Windows 11 的大致分类如下。

这个表是把 Microsoft Learn 的“Quality of Service”中的两个表，也就是 QoS 级别一览（High / Medium / Low / Utility / Eco / Media / Deadline）与 QoS 分类（从窗口的显示状态决定 QoS 的对应关系）重新整理而成的，并不是从观测归纳出来的分类。同一篇文档中还有这样的规定：被判定为正在发声的进程按 High 对待；以及上面任何一条都不适用的线程，会依据优先级等启发式规则自动分配。

还有一处对做测量的人来说很重要的记述：用电池运行时，如果一段时间没有用户输入，前台应用的 QoS 可能会被降到 Medium。文档中提醒，用电池做性能测量时应当关闭这个功能，并给出了关闭方法：在 HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Power\PowerThrottling 下把 DisableUserPresenceQos（REG_DWORD）设为 1。如果在没有输入的自动化测试中出现“只有用电池时才慢”，先怀疑这里最快。

这里重要的是，仅仅最小化，QoS 就可能发生变化。也就是说，在配备混合架构 CPU 的笔记本电脑上，

• 把应用移出了前台
• 又进一步最小化了
• 结果 QoS 下降了
• 更容易被放到 efficient core 一侧
• 体感或截止时间随之恶化

这样的事会很自然地发生。

flowchart TB
    accTitle: 从最小化到截止时间恶化的连锁
    accDescr: 表示在配备混合架构 CPU 的笔记本电脑上，把应用移出前台并最小化会让 QoS 下降，用电池时更容易被放到 efficient core 一侧，体感与截止时间随之恶化的连锁的图。
    mn2["移出前台并最小化"] --> qd1["QoS 下降"]
    qd1 -->|"用电池时尤其明显"| ec1["被放到 efficient core 一侧"]
    ec1 --> ws1["体感与截止时间恶化"]

图14：仅仅是最小化这一个操作，就可能引发一直传导到核心配置的连锁。

6.3 Thread Director 与 hybrid scheduling

在 Intel 第 12 代以后的 hybrid CPU 上，Intel Thread Director 会向操作系统给出提示。Windows 11 会利用它，更聪明地决定 P 核 / E 核的分配。

此外，Windows 一侧还有 heterogenous scheduling 的策略。

• SchedulingPolicy
• ShortSchedulingPolicy
• ShortThreadRuntimeThreshold

把它们保持为 Automatic 时，就是 由操作系统参考 QoS 与系统配置来决定 的机制。而在其背后，处理器电源管理一侧的 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 核 / E 核与频率"]

图15：优先级、QoS、可见状态、scheduling 策略与 Thread Director 的提示汇合到一起，决定核心与频率。

7. 什么时候有效，什么时候没有效

从实务上看，把容易生效的情况与其实是别的问题的情况分开来看会更快。

7.1 容易生效的情况

在这些情况下，后台服务 可能是思路正确的对策。

• 一把焦点切到前台应用，就只有后台的持续处理变得不稳定
• CPU 使用率并没有饱和，却只有周期处理错过截止时间
• 关键处理位于 legacy app / helper process / worker thread 一侧，而 MMCSS 或 QoS 用得不充分
• 服务或常驻处理才是主角，比起前台 UI 的顺滑感，后台处理的稳定更重要

7.2 效果有限，或其实是别的问题的情况

反过来，也有光靠这个设置不够的问题。

• DPC / ISR 延迟很大
• USB controller 或 audio driver 的缺陷
• USB selective suspend 或设备省电的影响
• thermal throttling
• battery saver、power throttling、EcoQoS 的影响
• 缓冲区太小
• 应用已经正确使用了 MMCSS / Deadline，问题出在别的地方

尤其在 Windows 11 加 hybrid CPU 的笔记本电脑上，visibility 与 QoS 的变化 影响相当大。如果症状是最小化后变慢、只有用电池时才变差，那么比起 处理器计划，怀疑 QoS / power 一侧更容易命中。

flowchart TB
    accTitle: 根据症状该怀疑哪一层
    accDescr: 表示把焦点切到前台后只有后台的持续处理变得不稳定时这个设置是候选，只在最小化或用电池时恶化就怀疑 QoS 与 power 一侧，DPC / ISR 或驱动程序引起的则属于另一类问题的排查图。
    smp2["观察症状出现的方式"] -->|"切到前台后后台不稳定"| this1["这个设置是候选"]
    smp2 -->|"只在最小化、用电池时恶化"| qsp1["怀疑 QoS / power 一侧"]
    smp2 -->|"DPC / ISR、驱动程序引起"| oth2["这个设置修不好的另一类问题"]

图16：症状对条件的依赖方式，会告诉你该看这个设置、QoS，还是别的问题。

8. 实务中的观察方式

真要排查的话，按下面的顺序推进比较清楚。

1. 固定条件
   • 接电源还是用电池
   • 电源模式
   • 缓冲区大小
   • foreground / visible / minimized 的状态
2. 在相同条件下比较 程序 与 后台服务
   • 不只看体感，还要记录 dropout 次数、glitch 次数、处理延迟
3. 如果是 Windows 11 / hybrid CPU，就怀疑 QoS 一侧
   • 是不是只在最小化时恶化
   • 是不是随 audible 状态变化
   • 是不是只在用电池时恶化
4. 如果是音频或视频，先看 MMCSS
   • 关键线程有没有向 Windows 传达“这个的截止时间很重要”
5. 仍然没有解决，就去挖 DPC / ISR / USB / driver
   • 到这一层已经是调度器之前的问题了

flowchart TB
    accTitle: 排查的顺序
    accDescr: 表示先固定条件，再在相同条件下比较程序与后台服务，如果是 hybrid CPU 就怀疑 QoS 一侧，音频或视频先确认 MMCSS，仍未解决再去挖 DPC / ISR 与驱动程序的排查顺序的图。
    o1["固定条件"] --> o2["在相同条件下比较两种设置"]
    o2 --> o3["hybrid CPU 就怀疑 QoS 一侧"]
    o3 --> o4["音频、视频先确认 MMCSS"]
    o4 --> o5["仍有问题就去挖 DPC / ISR 与驱动程序"]

图17：排查从固定条件开始，调度器之前的那一层放到最后再挖。

8.1 各项具体怎么确认

为了不停在“怀疑”这一步，这里列出确认的手段。

wpr 是 Windows Performance Recorder 的命令，包含在 Windows ADK 中。需要从管理员权限的控制台运行。

在实务中，比起平均 CPU 使用率，“有没有赶上截止时间” 更重要。这一点相当本质。

flowchart TB
    accTitle: 该看的指标是截止时间
    accDescr: 表示在这类问题上，比起平均 CPU 使用率，周期处理有没有赶上截止时间才是更重要的指标的图。
    avg2["平均 CPU 使用率"] -.->|"只看这个不够"| judge1["是否稳定的判断"]
    ddl1["有没有赶上截止时间"] -->|"要看的是这个"| judge1
    ddl1 -.-> cnt1["用 dropout 和 glitch 的次数来计数"]

图18：平均值低照样会错过截止时间，所以要数有没有赶上来判断。

9. 总结

把 处理器计划 改成 后台服务 会发生什么，用相当短的话重新说一遍就是这样。

• 改变的不是 CPU 的速度本身，而是 foreground 与 background 之间的 CPU 时间分配方式
• 程序 容易让前台应用更顺滑
• 后台服务 让后台的持续处理不容易被压制
• 因此在音频、视频、采集、监控、常驻处理这类后台截止时间重要的场景中，有时会有效
• 不过在 P 核 / E 核 CPU 上，实际的 core 配置还会受到 QoS、power policy、hybrid scheduling、Thread Director 的强烈影响
• 所以在如今的 Windows 上，把这个设置看作 有时会有效，但不是单独的主角 才自然

总之，这是一个 改变工作分派方式的旋钮，而不是提升 CPU 马力的旋钮。

是优先前台应用的顺滑感，还是让后台持续处理更容易守住截止时间。把它理解成把这个平衡稍微往 background 一侧挪的设置，就相当好懂了。

而到了 hybrid CPU 时代，在它之上还叠着 QoS 与 P / E 核心选择的层。把这些一起看，就能明白“为什么有时会有效”“为什么有时又没有效”。

flowchart TB
    accTitle: 这个旋钮在当下的位置
    accDescr: 表示这个设置是把工作分派稍微往 background 一侧挪的旋钮，在 hybrid CPU 时代其上还叠着 QoS 与 P / E 核心选择的层，所以它有时会有效但不是单独的主角的图。
    knob1["把分派往 background 一侧挪的旋钮"] --> base2["quantum 与优待的层"]
    base2 -.->|"叠在其上的是"| upper1["QoS 与 P / E 核心选择的层"]
    upper1 --> view1["有效的理由和无效的理由都能看清"]

图19：这个旋钮只作用于下面的层，如今的核心选择由它上面的层决定。

10. 参考资料

• Sawady: 优先后台服务的设置（不让 CPU 偷懒）
• Microsoft Learn: Win32_OperatingSystem class
• Microsoft Learn: Win32PrioritySeparation 注册表值的说明 - 各个位的含义，以及 UI 中的选择会写入的值。
• Microsoft Learn: Master Your Quantum - Win32PrioritySeparation 各个值对应的 quantum。
• Microsoft Learn: Know Thy Tick - clock tick 与 quantum 的关系。
• Microsoft Learn: CPU Analysis in Windows Performance Analyzer
• Microsoft Learn: Windows Performance Recorder
• Microsoft Learn: Priority Boosts
• Microsoft Learn: Window Features
• Microsoft Learn: Quality of Service
• Microsoft Learn: SetThreadInformation function
• Microsoft Learn: SetProcessInformation function
• Microsoft Learn: Multimedia Class Scheduler Service
• Microsoft Learn: Processor power management options overview
• Microsoft Learn: SchedulingPolicy
• Microsoft Learn: ShortSchedulingPolicy
• Microsoft Learn: ShortThreadRuntimeThreshold
• Intel Support: Is Windows 10 Task Scheduler Optimized for 12th Generation Intel Core Processors?
• Intel White Paper: Intel performance hybrid architecture & software optimizations, Part Two

相关文章

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

相关主题

与本文相近的主题页面。以本文为起点，可以进一步了解相关服务和其他文章。

与本主题相关的服务

本文与以下服务页面相关联，欢迎从最接近的入口查看。

常见问题

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

把处理器计划改成后台服务会发生什么变化？

变化的不是 CPU 的速度或频率，而是前台应用与后台运行的处理之间如何分配 CPU 时间。它在内部与 Win32PrioritySeparation 绑定，作用于 quantum（时间片）的分配方式以及对 foreground 的优待程度。程序容易偏向照顾前台应用，后台服务则偏向让前台与后台更均衡。另外要注意，即使选了这个设置，自己的应用也不会因此变成 Windows 服务。

为什么改成后台服务有时能修好爆音？

因为音频处理光靠平均速度快是不够的，它必须在每隔数毫秒的截止时间之前把缓冲填满。在程序设置下，前台应用一侧容易连续运行较久，后台的音频处理就算平均没有问题，也可能偏偏在那一瞬间延迟而出现 underrun。切到后台服务后，后台的持续处理更容易抢回 CPU，deadline miss 有时就会减少。不过 DPC / ISR 延迟、USB 省电、驱动程序缺陷、thermal throttling、EcoQoS 引起的问题，靠这个设置修不好。

改成后台服务，后台处理就会跑在 P 核上吗？

不会。放到 P 核还是 E 核上，比起这个设置，更多由 QoS、电源策略、hybrid scheduling、Intel Thread Director 等机制决定。在 Windows 11 上，仅仅把应用最小化 QoS 就会下降、用电池时更容易被放到 efficient core 一侧，这些都很常见。如果只有最小化时变慢、只有用电池时变差，那么比起这个设置，怀疑 QoS 或 power 一侧更容易命中。

爆音和 dropout 的原因该怎么排查？

先固定条件，比如是否接电源、电源模式、缓冲区大小、前台还是最小化的状态，然后在相同条件下比较程序与后台服务，记录 dropout 次数和处理延迟。如果是 Windows 11 的 hybrid CPU，就看是不是只在最小化或用电池时恶化，从而怀疑 QoS 一侧。如果是音频或视频，先确认关键线程有没有用上 MMCSS；仍然没修好，就去挖 DPC / ISR、USB 与驱动程序。到这一步已经是调度器之前的问题了。

作者简介

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

Go Komura

小村软件有限公司 代表

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