Планирование процессора в Windows: «Фоновые службы» и P-/E-ядра

«Снял приложение с переднего плана — в звуке пошли щелчки» «Поставил Планирование процессора в Фоновые службы — и стало стабильнее»

Такие истории в Windows ходят давно. Особенно это важно там, где непрерывная обработка важнее UI: звук, видео, измерения, трансляция, постоянно работающие процессы.

Но это не волшебный переключатель ускорения. Параметр не поднимает тактовую частоту CPU, не превращает приложение в службу Windows и не привязывает его к P-ядрам. Меняется в основном то, как процессорное время делится между приложением на переднем плане и работой, которая идёт в фоне.

flowchart TB
    accTitle: Что меняет этот параметр
    accDescr: Параметр планирования процессора не поднимает частоту, не превращает приложение в службу и не привязывает к ядру; он меняет распределение процессорного времени между приложением на переднем плане и фоновой работой.
    st1["Параметр «Планирование процессора»"] -.->|"это не меняет"| notx["частота, превращение в службу, привязка к ядру"]
    st1 -->|"меняет"| shr1["как делится CPU-время между передним планом и фоном"]

Рис. 1: Не переключатель ускорения, а параметр, который переключает правила распределения процессорного времени.

Дальше разберём, что меняется между Программы и Фоновые службы, и свяжем это с основами планировщика Windows, квантом (time slice), предпочтением foreground и поведением CPU с P- и E-ядрами.

1. Сначала вывод

Сначала только суть.

• Напрямую параметр меняет не «мощность» CPU, а то, как распределяют процессорное время.
• Программы чаще предпочитают приложение на переднем плане, Фоновые службы ближе к равному отношению к переднему плану и фону.
• Поэтому в нагрузках, где дедлайн непрерывной фоновой работы важнее UI на переднем плане, Фоновые службы иногда помогают.
• Но на CPU с P- и E-ядрами то, на каком ядре окажется поток, сегодня сильнее определяют 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 в тексте всплывают слова, смысл которых полностью проясняется только позже. Поэтому сводим их здесь.

Карта знаний этой статьи

Параметр «Планирование работы процессора» внутри связан со значением реестра Win32PrioritySeparation и лишь переключает длину quantum и степень предпочтения между foreground и background — напрямую частоту ЦП или привязку к ядру он не меняет. Сторона фоновых служб ослабляет предпочтение переднего плана, поэтому иногда снижает underrun, например в обработке звука, которая гонится за дедлайном, — но это другой механизм, чем повышение приоритета, которое делает MMCSS. В современной Windows, особенно на hybrid CPU с P-ядрами и E-ядрами, фактическое размещение на ядро сильнее определяют Windows QoS и политика heterogeneous scheduling вроде Intel Thread Director; одно только сворачивание окна или работа от батареи могут снизить QoS и сместить размещение в сторону efficient cores. Чтобы отделить причину, полезно наблюдать задержку DPC/ISR через Windows Performance Recorder и Analyzer.

flowchart LR
    accTitle: Карта знаний: параметр планирования процессора и QoS
    accDescr: Схема показывает, что параметр планирования процессора — старый механизм, который через Win32PrioritySeparation переключает распределение quantum и предпочтение foreground; что MMCSS и Windows QoS влияют на underrun и размещение на P-ядрах и E-ядрах; что Intel Thread Director и политика heterogeneous scheduling определяют выбор ядра на hybrid CPU; и средства проверки задержки DPC/ISR
    processor_scheduling_setting["параметр «Планирование использования процессора»"]
    windows_qos["классификация QoS Windows (Quality of Service)"]
    win32priorityseparation["Win32PrioritySeparation"]
    quantum["quantum (квант времени)"]
    foreground_boost["Foreground Boost"]
    audio_underrun["аудио underrun"]
    mmcss["MMCSS (Multimedia Class Scheduler Service)"]
    efficient_core_placement["размещение ближе к efficient cores"]
    ecoqos["EcoQoS"]
    disableuserpresenceqos["DisableUserPresenceQos"]
    hybrid_scheduling_policy["политика heterogeneous scheduling (SchedulingPolicy и др.)"]
    intel_thread_director["Intel Thread Director"]
    p_core_e_core_cpu["гибридный CPU (P-core/E-core)"]
    core_parking["Core Parking"]
    dpc_isr_latency["задержка DPC/ISR"]
    wpr_wpa["WPR/WPA (Windows Performance Recorder/Analyzer)"]
    processor_scheduling_setting -->|"настраивается"| win32priorityseparation
    quantum -->|"настраивается"| win32priorityseparation
    processor_scheduling_setting -->|"использует"| quantum
    processor_scheduling_setting -->|"использует"| foreground_boost
    processor_scheduling_setting -.->|"снижает"| audio_underrun
    mmcss -->|"снижает"| audio_underrun
    mmcss -->|"использует"| windows_qos
    windows_qos -.->|"может вызвать"| efficient_core_placement
    ecoqos -->|"может вызвать"| efficient_core_placement
    disableuserpresenceqos -.->|"предотвращает"| efficient_core_placement
    hybrid_scheduling_policy -->|"использует"| windows_qos
    hybrid_scheduling_policy -.->|"использует"| intel_thread_director
    hybrid_scheduling_policy -->|"требует"| p_core_e_core_cpu
    intel_thread_director -->|"требует"| p_core_e_core_cpu
    hybrid_scheduling_policy -->|"использует"| core_parking
    dpc_isr_latency -->|"проверяется"| wpr_wpa
    p_core_e_core_cpu -->|"проверяется"| wpr_wpa
    dpc_isr_latency -.->|"может вызвать"| audio_underrun

На схеме сплошная линия обозначает отношение, которое выполняется всегда, а пунктирная — условное отношение (условия указаны в пояснении к каждому отношению на странице сведений). Полный список отношений (всего 18, с доказательствами и степенью уверенности) и определения основных понятий собраны на странице сведений карты знаний (на японском). Данные: JSON-LD / Turtle

2. Что этот параметр вообще меняет

Планирование процессора на экране настроек — одна из давних политик планирования Windows. Внутри это довольно старый параметр, связанный с Win32PrioritySeparation.

Сначала база: как Windows пользуется CPU.

• Планировщик сначала выбирает среди готовых к выполнению потоков тот, у которого приоритет выше.
• При равном приоритете они выполняются по очереди, каждый — фиксированное время.
• Это «фиксированное время» и есть quantum (time slice).

flowchart LR
    accTitle: Базовый ход планировщика Windows
    accDescr: Планировщик выбирает среди готовых потоков самый приоритетный, даёт ему один квант, и если есть ожидающий поток того же приоритета, делает переключение контекста.
    ready["Готовые к выполнению потоки"] --> pick["Планировщик выбирает поток с наивысшим приоритетом"]
    pick --> run["Выполнить на 1 квант"]
    run --> wait{"Есть ожидающий поток того же приоритета?"}
    wait -- да --> switch["Переключение контекста"]
    switch --> pick
    wait -- нет --> run

Рис. 3: Планировщик берёт самый приоритетный поток и гоняет их по одному кванту.

Планирование процессора в основном трогает как распределяют этот квант и насколько сильно предпочитают foreground.

Foreground здесь — приложение на переднем плане, с которым сейчас работает пользователь. Наоборот, ушедшая в фон работа, worker в другом процессе, службы Windows, вспомогательные процессы и постоянно живущая обработка легче оказываются на стороне background.

Важно: выбор Фоновые службы не делает ваше приложение службой Windows. Меняется не вид процесса с названием «служба», а правила распределения CPU между foreground и background. Название здесь сильно путает.

flowchart TB
    accTitle: Путаница в названии «Фоновые службы»
    accDescr: Выбор «Фоновые службы» не превращает приложение в службу Windows; меняются только правила распределения CPU между foreground и background.
    sel2["Выбираем «Фоновые службы»"] -.->|"так не бывает"| svcx["приложение становится службой Windows"]
    sel2 -->|"меняется"| rule1["правила распределения CPU между передним планом и фоном"]

Рис. 4: Вопреки названию, меняются не тип процесса, а правила распределения.

2.1 Как дойти до экрана настройки

Параметр спрятан довольно глубоко в панели управления. Путей два.

• 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 бита (AABBCC).

• Старшие 2 бита: квант длиннее или короче
• Средние 2 бита: квант переменный или фиксированный
• Младшие 2 бита: во сколько раз foreground предпочитают background (работают только при переменном кванте)

Дальше сказано, что выбор в UI пишет такие значения (тогда в UI было Applications и Background services; сейчас это Программы и Фоновые службы).

Если копнуть в числа, в статье Microsoft при 0x26 квант foreground равен 18, background — 6, при 0x18 оба равны 36. Квант считают в третях clock tick, поэтому в тиках это передний план 6 tick / фон 2 tick против оба по 12 tick. В той же статье для x86-мультипроцессорной машины clock tick приведён как 15,625 мс; тогда разница выглядит как «передний план может выполняться подряд примерно 94 мс» против «и передний план, и фон выполняются примерно по 188 мс».

То есть вариант Фоновые службы — это распределение «за один раз выполняемся дольше, но переднему плану не отдаём предпочтение». Фоновой работе труднее оказаться в состоянии, когда очередь до неё так и не доходит.

flowchart TB
    accTitle: Как два значения распределяют квант
    accDescr: При «Программах» передний план получает 6 tick, фон — 2, поэтому передний план выполняется дольше; при «Фоновых службах» оба получают по 12 tick: непрерывное выполнение длиннее, но переднему плану не отдают предпочтение.
    pg1["Настройка «Программы»"] --> fg6["передний план 6 tick, фон 2 tick"]
    bg2["Настройка «Фоновые службы»"] --> eq12["и передний план, и фон по 12 tick"]
    eq12 --> nofam1["фону труднее не дождаться своей очереди"]

Рис. 6: Одно значение даёт переднему плану длинный отрезок, другое длинное время делит поровну.

У толкования значений по умолчанию тоже есть разница между ОС. В описании Win32_OperatingSystem Microsoft пишет, что клиентская Windows по умолчанию даёт переменный квант, и у приложения на переднем плане он длиннее, а Windows Server — фиксированный квант. В разборе реестра то же значение по умолчанию 0x2 на клиенте значит «короткий, переменный, передний план в 3 раза», на сервере — «длинный, фиксированный, поровну». Поэтому сервер с самого начала ближе к Фоновые службы.

flowchart TB
    accTitle: Одно значение по умолчанию, разное чтение на клиенте и сервере
    accDescr: Одно и то же значение по умолчанию клиентская Windows читает как короткий переменный квант с тройным предпочтением переднего плана, Windows Server — как длинный фиксированный и равный; поэтому сервер сразу ближе к «Фоновым службам».
    dv1["Одно и то же значение по умолчанию"] -->|"клиент"| cl2["короткий, переменный, передний план ×3"]
    dv1 -->|"сервер"| sv4["длинный, фиксированный, поровну"]
    sv4 -.-> lean1["с самого начала ближе к «Фоновым службам»"]

Рис. 7: Разницу задаёт не само значение, а то, как ОС его читает по умолчанию.

Конкретные числа выше опираются на документы и статьи Microsoft поколения Windows 2000 / XP. Соответствие значений реестра и UI до сих пор то же, но фактическое обращение с квантом может меняться от версии ОС, поэтому цифры лучше читать как порядок величины, а не как гарантию текущего такта.

3. Что меняется между Программы и Фоновые службы

Разницу проще увидеть в таблице.

Клиентская Windows в целом заточена так, чтобы приложению на переднем плане было комфортно. Поэтому для обычной работы за рабочим столом Программы — естественный выбор.

Но есть случаи, когда расклад другой.

• Обработка звука, которая в фоне всё время заполняет буфер
• Лёгкий UI, а захват или разбор идут непрерывно в другом потоке / процессе
• Браузер или IDE на переднем плане, но дедлайн фоновой работы всё равно нужно держать
• Нагрузка ближе к серверной, к службам, к постоянно живущим процессам

Тогда стабильнее не выделять только foreground, а дать фоновой работе легче возвращать себе CPU. В этом смысле Фоновые службы иногда логичны.

flowchart TB
    accTitle: Какое распределение подходит
    accDescr: Для интерактивной работы за рабочим столом естественны «Программы» с предпочтением переднего плана; для нагрузок, где важен дедлайн фоновой работы, разумный кандидат — «Фоновые службы», потому что фон легче возвращает себе CPU.
    wl1["Характер нагрузки"] -->|"интерактивная работа"| pgn1["естественны «Программы»"]
    wl1 -->|"важен дедлайн фона"| bgn1["кандидат — «Фоновые службы»"]
    bgn1 --> back2["фоновая работа легче возвращает себе CPU"]

Рис. 8: Выбор зависит от того, что бережём: отзывчивость переднего плана или дедлайн фона.

4. Почему это иногда помогает звуку и непрерывной обработке

Проще всего на щелчках и dropout в аудио.

Обработке звука мало быть «быстрой в среднем». Каждые несколько миллисекунд, а то и чаще, нужно к нужному моменту заполнить буфер. Даже при низкой средней загрузке CPU, если поток не смог выполниться именно в этот момент, звук рвётся.

Возьмём конкретную ситуацию.

• На переднем плане браузер, UI DAW или другое приложение
• В фоне с заданным периодом работает поток обработки звука и кормит буфер
• У потока обработки звука приоритет не завышен, 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. Принцип — квант и предпочтение foreground

Чуть ниже по слоям цепочка такая.

5.1 Чем длиннее квант, тем дольше ждут конкуренты того же приоритета

Когда за CPU спорят несколько потоков одного диапазона приоритетов, чем больший квант получает один поток, тем легче остальным ждать.

В настройке, которая предпочитает приложение на переднем плане, сторона foreground чаще выполняется подряд дольше. Background того же приоритета чаще получает «сейчас не твоя очередь».

Для работы, которую нужно по чуть-чуть, но регулярно — звук, видео, периодические измерения, polling, мониторинг — эта разница заметна.

flowchart TB
    accTitle: Длинный квант заставляет ждать равных по приоритету
    accDescr: Когда потоки одного приоритета спорят за CPU, чем длиннее квант у одного, тем легче остальным ждать; для работы, которую нужно выполнять регулярно по чуть-чуть, эта разница ощутима.
    comp1["Спор в одном диапазоне приоритетов"] --> long1["один получает длинный квант"]
    long1 --> wt2["остальным легче ждать"]
    wt2 -.-> perio1["чем регулярнее нужна работа, тем заметнее разница"]

Рис. 10: Длина кванта сразу становится временем ожидания для равного конкурента.

5.2 Windows бережёт foreground несколькими способами

Windows изначально довольно внимательна к foreground. Типичные механизмы такие.

• Предпочтение процессу, который вышел на передний план
• Предпочтение потоку, которому принадлежит окно, принимающее ввод
• Динамический подъём приоритета потока после завершения I/O

То есть уже сам уход приложения с переднего плана обычно меняет то, как его трактует планировщик. Фоновые службы проще понимать как параметр, который из всех этих предпочтений foreground уменьшает именно перекос в распределении процессорного времени.

flowchart TB
    accTitle: Как Windows бережёт foreground
    accDescr: Windows бережёт foreground несколькими способами: предпочтение процессу на переднем плане, потоку окна ввода и динамический подъём после I/O; поэтому уже уход с переднего плана меняет обращение.
    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: Точный смысл «не давать простаивать»
    accDescr: Параметр меняет не управление простоем и частотой CPU, а порядок и длительность выполнения потоков; это не настройка turbo, C-state, core parking и не привязка к P-ядрам.
    sabo1["Ощущение «не давать CPU простаивать»"] -->|"реально меняется"| ord2["порядок и длина непрерывного выполнения"]
    sabo1 -.->|"не меняется"| pw2["turbo, C-state, core parking, привязка к ядру"]

Рис. 12: «Не давать простаивать» — это не управление питанием, а смена очереди и длительности непрерывного выполнения.

6. Как это работает на CPU с P- и E-ядрами

Здесь чаще всего путают.

Выбор Фоновые службы не заставляет Windows просто решить: «это фон — значит E-ядро», «это foreground — значит P-ядро». В современной Windows, особенно в Windows 11 на hybrid CPU, выбор между P- и E-ядрами устроен многослойнее.

6.1 Похожие названия, разные вещи

Сначала две разные сущности с похожими именами.

1. Фоновые службы в Планирование процессора
   • Параметр в старом UI
   • В основном влияет на распределение процессорного времени между foreground и background
   • Линия кванта и foreground boost
2. Классы QoS вроде Utility / Eco / Low
   • Современная классификация Windows по питанию / производительности
   • Влияет и на выбор ядра, и на управление частотой
   • Прямее связана с поведением P- и E-ядер

Это не одно и то же.

flowchart TB
    accTitle: Похожие имена, разные сущности
    accDescr: Параметр планирования процессора — старый UI, линия кванта и предпочтения foreground; QoS — современная классификация питания и производительности, линия выбора ядра и частоты.
    old2["Параметр «Планирование процессора»"] --> qt1["линия кванта и предпочтения foreground"]
    newq1["Классификация QoS"] --> cs2["линия выбора ядра и частоты"]
    old2 -.->|"это не одно и то же"| newq1

Рис. 13: По звучанию названия похожи, слой, на который они действуют, совсем другой.

6.2 QoS и visibility в Windows 11

В современной Windows работает не только priority, но и QoS. Особенно на heterogeneous processor, то есть на конфигурациях с P- и E-ядрами, QoS влияет на то, какой тип ядра поток предпочитает.

Грубая классификация Windows 11 такая.

Таблица собрана из двух таблиц Microsoft Learn «Quality of Service»: списка уровней QoS (High / Medium / Low / Utility / Eco / Media / Deadline) и классификации QoS (соответствие состояния окна уровню QoS). Это не классификация, выведенная из измерений. В том же документе есть правило, что процесс, который сочли воспроизводящим звук, трактуют как High, и пояснение, что потокам, которые никуда из этого не попали, класс назначают автоматически по эвристикам вроде приоритета.

Есть ещё одна формулировка, важная тем, кто измеряет. Если при питании от батареи какое-то время нет ввода пользователя, QoS приложения на переднем плане могут опустить до Medium. В документации прямо сказано: при замерах на батарее эту функцию стоит отключить, и как способ отключения указано поставить DisableUserPresenceQos (REG_DWORD) в HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Power\PowerThrottling в 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

На hybrid CPU Intel 12-го поколения и новее Intel Thread Director даёт ОС подсказки. Windows 11 использует их, чтобы умнее распределять нагрузку между P- и E-ядрами.

Плюс на стороне Windows есть политики heterogeneous scheduling:

• SchedulingPolicy
• ShortSchedulingPolicy
• ShortThreadRuntimeThreshold

Если оставить их в Automatic, решение принимает ОС, глядя на QoS и конфигурацию системы. За этим ещё работают core parking engine и performance state engine на стороне processor power management.

Общую картину удобно видеть так:

flowchart TD
    accTitle: Что сходится в выборе ядра и частоты
    accDescr: Приоритет, QoS, видимость, политика hybrid scheduling и подсказки Intel Thread Director сходятся в планировщике Windows и управлении питанием процессора, и уже там решаются P-/E-ядро и частота.
    t["Поток"] --> p["Приоритет / динамический приоритет"]
    t --> q["QoS (High / Medium / Low / Utility / Eco / Deadline)"]
    t --> v["Видимость / звук / состояние ввода"]
    t --> h["Политика hybrid scheduling<br/>SCHEDPOLICY / SHORTSCHEDPOLICY"]
    t --> td["Подсказки Intel Thread Director<br/>Windows 11 на hybrid CPU Intel"]
    v --> q
    p --> s["Планировщик Windows + Processor Power Management"]
    q --> s
    h --> s
    td --> s
    s --> c["Решаются P-ядро / E-ядро и частота"]

Рис. 15: Приоритет, QoS, видимость, политика scheduling и подсказки Thread Director сходятся, и уже там решаются ядро и частота.

7. Когда это помогает, а когда нет

На практике быстрее сразу отделить случаи, где параметр обычно помогает, от случаев, где проблема совсем другая.

7.1 Где обычно помогает

В таких ситуациях Фоновые службы могут быть здравой мерой.

• При переносе фокуса на приложение переднего плана нестабильной становится только непрерывная фоновая работа
• Загрузка CPU не упирается в потолок, но срывается именно дедлайн периодической обработки
• Критичная работа сидит в legacy-приложении, helper-процессе или worker-потоке, а 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 / питание, а не Планирование процессора.

flowchart TB
    accTitle: По симптому — что подозревать
    accDescr: Если при уходе фокуса нестабилен только фон, кандидат — этот параметр; если хуже только после сворачивания или только на батарее — QoS и питание; если DPC/ISR или драйвер — это другая проблема.
    smp2["Смотрим, как проявляется симптом"] -->|"уход на передний план, фон нестабилен"| this1["кандидат — этот параметр"]
    smp2 -->|"хуже только после сворачивания или на батарее"| qsp1["подозревать QoS / питание"]
    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-ядрами фактическое размещение по ядрам сильно определяют ещё QoS, политика питания, hybrid scheduling и Thread Director;
• поэтому в сегодняшней Windows этот параметр естественно видеть как то, что иногда помогает, но не является единственным главным действующим лицом.

Иначе говоря, это не регулятор, который поднимает мощность CPU, а регулятор, который меняет распределение работы.

Что важнее — отзывчивость приложения на переднем плане или соблюдение дедлайна непрерывной фоновой работы? Если читать параметр как настройку, которая чуть сдвигает этот баланс в сторону фона, картина складывается.

А в эпоху hybrid CPU сверху ещё лежат слои QoS и выбора между P- и E-ядрами. Если смотреть вместе, становятся видны и «почему иногда помогает», и «почему иногда нет».

flowchart TB
    accTitle: Место этого регулятора в современной Windows
    accDescr: Параметр чуть сдвигает распределение в сторону background на слое кванта и предпочтения; в эпоху hybrid CPU сверху лежат QoS и выбор P-/E-ядра, поэтому он иногда помогает, но не является единственным главным действующим лицом.
    knob1["Регулятор, который сдвигает распределение в сторону background"] --> base2["слой кванта и предпочтения"]
    base2 -.->|"сверху лежит"| upper1["слой QoS и выбора P-/E-ядра"]
    upper1 --> view1["видны и причины, почему помогает, и почему нет"]

Рис. 19: Регулятор действует на нижний слой; в современной Windows выбор ядра решает слой выше.

10. Справочные материалы

• Sawady: настройка приоритета фоновых служб (не давать CPU простаивать)
• Microsoft Learn: класс Win32_OperatingSystem
• Microsoft Learn: описание значения реестра Win32PrioritySeparation — смысл битов и значения, которые пишет выбор в UI.
• Microsoft Learn: Master Your Quantum — квант по значениям Win32PrioritySeparation.
• Microsoft Learn: Know Thy Tick — связь clock tick и кванта.
• 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
• Microsoft Learn: функция SetProcessInformation
• Microsoft Learn: Multimedia Class Scheduler Service
• Microsoft Learn: обзор параметров управления питанием процессора
• 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 и не тактовая частота, а то, как процессорное время делится между приложением на переднем плане и работой в фоне. Внутри это параметр, связанный с Win32PrioritySeparation: он влияет на распределение кванта (time slice) и на то, насколько сильно предпочитают foreground. «Программы» чаще отдают преимущество приложению на переднем плане, «Фоновые службы» обращаются с foreground и background более равномерно. Этот выбор не превращает ваше приложение в службу Windows.

Почему «Фоновые службы» иногда убирают щелчки в звуке?

Обработке звука мало быть быстрой в среднем: буфер нужно заполнять к дедлайну каждые несколько миллисекунд. При «Программах» приложение на переднем плане чаще выполняется дольше без переключения, и фоновая обработка звука, даже если в среднем всё в порядке, может именно в этот момент опоздать и дать underrun. Если переключить на «Фоновые службы», непрерывная фоновая работа легче возвращает себе CPU, и пропуски дедлайна иногда сокращаются. Задержки DPC/ISR, энергосбережение USB, сбои драйверов, thermal throttling и проблемы из EcoQoS этот параметр не устраняет.

Если выбрать «Фоновые службы», фоновая обработка начнёт идти на P-ядрах?

Нет. На каком ядре окажется поток — P или E — сильнее влияют QoS, политика питания, hybrid scheduling и Intel Thread Director, а не этот параметр. В Windows 11 QoS может снизиться уже от того, что окно свернули, и при питании от батареи поток чаще оказывается ближе к efficient core. Если тормоза только после сворачивания или только на батарее, подозревать стоит QoS или сторону питания, а не этот параметр.

Как отделить причину щелчков или dropout?

Сначала зафиксируйте условия: питание от сети или от батареи, режим питания, размер буфера, состояние переднего плана / свёрнутости. Затем сравните «Программы» и «Фоновые службы» в одинаковых условиях и запишите число dropout и задержку обработки. На hybrid CPU в Windows 11 посмотрите, ухудшается ли картина только при сворачивании или только на батарее, и проверяйте QoS. Для звука и видео сначала убедитесь, что важные потоки пользуются MMCSS; если и это не помогает — разбирайте DPC/ISR, USB и драйверы. Дальше это уже не вопрос планировщика.

Об авторе

Страница с профилем автора статьи.

Го Комура

Представитель KomuraSoft LLC

Специализируется на разработке программного обеспечения для Windows, техническом консалтинге и расследовании сбоев, особенно в проектах с унаследованными системами и трудно воспроизводимыми ошибками.