把 Windows 的「處理器排程」改成「背景服務」會發生什麼 - 整理 quantum、優先權提升、P-Core／E-Core

「把應用程式切到背景就會爆音」
「把處理器排程改成背景服務之後就穩了」

在 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. 程式 與 背景服務 的差別

大致整理如下比較清楚：

客戶端 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. 處理器排程 的 背景服務
   • 舊版 UI 裡的設定
   • 主要影響 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 就可能改變。所以在配備 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. 參考資料

• Sawady: バックグラウンドサービスを優先する設定（CPUをサボらせない）
• Microsoft Learn: Win32_OperatingSystem class
• 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