Windows 的處理器排程設定 - 背景服務與 P-Core／E-Core

「把應用程式移出前景，聲音就會斷斷續續」 「把 處理器排程 改成 背景服務 之後就穩定了」

在 Windows 上，這類說法從很久以前就一直出現。尤其是音訊、影像、量測、直播、常駐執行的處理這種比起 UI 更看重持續處理的場合，特別讓人在意。

不過，這個設定並不是什麼神奇的加速開關。它既不是直接把 CPU 時脈拉高的設定，也不是把應用程式變成 Windows 服務的設定，更不是把執行緒釘在 P-Core 上的設定。主要會改變的，是前景應用程式與背後執行的處理之間，CPU 時間要怎麼分配。

flowchart TB
    accTitle: 這個設定會改變的東西
    accDescr: 說明處理器排程設定既不是拉高時脈，也不是把應用程式變成服務或釘住核心，而是改變前景應用程式與背後處理之間 CPU 時間分配方式的圖。
    st1["處理器排程設定"] -.->|"這些都不會改變"| notx["時脈、變成服務、釘住核心"]
    st1 -->|"改變的是"| shr1["前景與背後的 CPU 時間分配方式"]

圖 1: 不要當成加速開關，而要當成切換 CPU 時間分配方式的設定來讀。

本文梳理 程式 與 背景服務 之間到底改變了什麼，並把 Windows 排程器的基本原理、quantum（時間配量）、foreground 的優待，一路連到具備 P-Core／E-Core 的 CPU 行為。

1. 先講結論

先把重點列出來。

• 這個設定直接改變的，與其說是 CPU 的「馬力」，不如說是 CPU 時間的「分配方式」。
• 程式 傾向優待前景應用程式，背景服務 則傾向把前景與背後的處理看得更均等。
• 因此，在比起前景 UI、更重視背後持續處理截止時間的工作負載上，背景服務 有時候會有效。
• 不過在 P-Core／E-Core 的 CPU 上，「會被放到哪一種核心」現在已經不是只由這個設定決定，QoS、電源原則、hybrid scheduling、Intel Thread Director 這些機制的影響更大。
• 也就是說，改成 背景服務 並不會變成「背景處理丟給 P-Core」「服務丟給 E-Core」這種單純的結果。
• 如果音訊的爆音或 dropout 是源自 DPC／ISR、USB 省電、驅動程式、thermal throttling、EcoQoS，光靠這個設定是修不好的。

一句話總結，這個設定 不是 CPU 的頻率設定，而是改變排隊規則的設定。

flowchart TB
    accTitle: 有效與無效的大致範圍
    accDescr: 說明對於重視背後持續處理截止時間的工作負載，背景服務這一側有時候會有效，但要放到 P-Core 還是 E-Core 是由 QoS 與電源原則等機制決定的圖。
    bgss1["背景服務這一側"] -->|"有時候會有效"| dl1["背後持續處理的截止時間"]
    bgss1 -.->|"由別的機制決定"| core1["P-Core／E-Core 的選擇"]
    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: 說明在效能選項的 UI 選好之後，結果會寫進 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 時的 quantum 是 foreground 為 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: 一邊讓前景跑得久，另一邊把較長的持有時間平均分配。

另外，連這個預設值的解讀也有 OS 上的差異。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: 分開預設解讀的不是值本身，而是 OS 這一側。

這裡舉出的具體數值，來自 Windows 2000 / XP 世代的 Microsoft 文件與解說文章。登錄檔值與 UI 的對應關係至今相同，但實際上 quantum 怎麼處理會隨 OS 版本而變，因此這些數字請當成「大概是哪個數量級」的參考值來讀。

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-Core 上的設定

就是這麼一回事。

flowchart TB
    accTitle: 「不讓它偷懶」的準確意思
    accDescr: 說明這個設定實際改變的不是 CPU 的閒置控制或頻率，而是執行緒以什麼順序、跑多長的時間，它並不是 turbo、C-state、core parking 或釘住 P-Core 的設定的圖。
    sabo1["不讓 CPU 偷懶，這種感覺"] -->|"實際改變的是"| ord2["執行的順序與長度"]
    sabo1 -.->|"不會改變的是"| pw2["turbo、C-state、core parking、釘住核心"]

圖 12: 「不讓它偷懶」的實體不是電源控制，而是順序與持有時間的變更。

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

這裡是最容易被誤解的地方。

改成 背景服務，並不代表 Windows 就會照著「背景處理所以丟 E-Core」「前景所以丟 P-Core」這樣單純地決定。在現代的 Windows，特別是 Windows 11 的 hybrid CPU 上，P-Core／E-Core 的選擇是更多層的。

6.1 名字相近，其實是兩回事

首先，有 2 個名字相似但完全不同的東西。

1. 處理器排程 裡的 背景服務
   • 舊 UI 裡的設定
   • 主要作用在 foreground／background 的 CPU 時間分配方式
   • 屬於 quantum 與 foreground boost 這個系統
2. QoS 的 Utility / Eco / Low 等
   • 現代 Windows 的 power／performance 分類
   • 也會作用在 core 的選擇與頻率控制
   • 容易直接牽動 P-Core／E-Core 的行為

這 2 個並不是同一件事。

flowchart TB
    accTitle: 名字相近的兩回事
    accDescr: 說明處理器排程設定是舊 UI 的設定，作用在 quantum 與 foreground 優待這個系統，而 QoS 是現代的 power/performance 分類，作用在核心選擇與頻率控制，兩者並不相同的圖。
    old2["處理器排程設定"] --> qt1["quantum 與 foreground 優待的系統"]
    newq1["QoS 的分類"] --> cs2["核心選擇、頻率控制的系統"]
    old2 -.->|"並不相同"| newq1

圖 13: 名字的氣味雖然相似，作用的層級卻完全不同。

6.2 Windows 11 的 QoS 與 visibility

在現代的 Windows 上，起作用的不只有 priority，QoS 也會有影響。特別是在 heterogenous processor，也就是 P-Core／E-Core 這種架構上，QoS 會影響 偏好哪一種核心。

Windows 11 大致的分類如下。

這張表是把 Microsoft Learn「Quality of Service」裡的 2 張表重新整理而成：一張是 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 就可能改變。也就是說，在搭載 hybrid CPU 的筆記型電腦上：

• 把應用程式移出前景
• 又進一步最小化
• 結果 QoS 下降
• 變得容易被放到偏 efficient core 的位置
• 體感與截止時間都惡化

這樣的事情很常發生。

flowchart TB
    accTitle: 從最小化到截止時間惡化的連鎖
    accDescr: 說明在搭載 hybrid CPU 的筆記型電腦上，把應用程式移出前景並最小化之後 QoS 會下降，用電池時容易被放到偏 efficient core 的位置，體感與截止時間因而惡化的連鎖圖。
    mn2["移出前景並最小化"] --> qd1["QoS 下降"]
    qd1 -->|"用電池時尤其明顯"| ec1["被放到偏 efficient core 的位置"]
    ec1 --> ws1["體感與截止時間惡化"]

圖 14: 光是最小化這個操作，就可能引發一路影響到核心配置的連鎖。

6.3 Thread Director 與 hybrid scheduling

在 Intel 12th Gen 以後的 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 與頻率"]

圖 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["在相同條件下比較 2 種設定"]
    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-Core／E-Core 的 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-Core/E-Core 選擇的層，因此有時候會有效但不是單獨主角的圖。
    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-Core 上嗎？

不會。要放到 P-Core 還是 E-Core，比起這個設定，QoS、電源原則、hybrid scheduling、Intel Thread Director 這些機制的影響大得多。在 Windows 11 上，光是把應用程式最小化 QoS 就會下降，用電池時被放到偏 efficient core 的位置也很常見。如果只有最小化時才變慢、只有用電池時才變差，懷疑 QoS 或電源那一側，會比懷疑這個設定更容易命中。

音訊中斷或 dropout 的原因該怎麼縮小範圍？

先把條件固定下來：是不是接市電、電源模式、緩衝區大小、視窗是在前景還是已最小化；接著在相同條件下比較「程式」與「背景服務」，記錄 dropout 次數與處理延遲。如果是 Windows 11 的 hybrid CPU，就看看是不是只有最小化或只有用電池時才惡化，從 QoS 那一側懷疑起。音訊或影像則要先查看重要的執行緒有沒有用上 MMCSS；若還是修不好，再往 DPC／ISR、USB、驅動程式挖。到了這一層，就已經是排程器以前的問題了。

作者檔案

本文作者的個人檔案頁面。

Go Komura

小村軟體有限公司 代表

以 Windows 軟體開發、技術諮詢與故障調查為中心，在難以重現的故障調查與既有資產仍在運作的專案上具有優勢。