Réglages de planification du processeur sous Windows - Services d'arrière-plan et cœurs P/E

« Quand je sors mon appli du premier plan, l’audio se met à craquer. » « Passer Planification du processeur sur Services d'arrière-plan a stabilisé les choses. »

Ce genre de récit circule depuis longtemps sous Windows. Il compte particulièrement dans des situations comme l’audio, la vidéo, la mesure, le streaming ou les traitements résidents — des cas où le traitement continu importe plus que l’interface utilisateur.

Ce réglage n’est pourtant pas un bouton magique d’accélération. Ce n’est ni un réglage qui augmente directement la fréquence du CPU, ni un réglage qui transforme votre application en service Windows, ni un réglage qui la fixe sur un cœur P. Ce qui change principalement, c’est la façon dont le temps CPU est réparti entre l’application au premier plan et les traitements qui tournent en arrière-plan.

Cet article fait le point sur ce qui change entre Programmes et Services d'arrière-plan, en reliant les bases du planificateur Windows, le quantum (la tranche de temps), la faveur accordée au premier plan, et le comportement des CPU dotés de cœurs P / E.

1. D’abord, la conclusion

Voici d’abord les points essentiels.

• Ce que ce réglage change directement, ce n’est pas tant le « moteur » du CPU que la « répartition » du temps CPU.
• Programmes tend à favoriser l’application au premier plan, tandis que Services d'arrière-plan traite le premier plan et l’arrière-plan de façon plus équilibrée.
• C’est pourquoi, pour les charges de travail où les échéances des traitements continus en arrière-plan comptent plus que l’interface utilisateur au premier plan, Services d'arrière-plan peut aider.
• Cependant, sur un CPU à cœurs P / E, « quel cœur reçoit le thread » dépend aujourd’hui bien plus du QoS, de la politique d’alimentation, de la planification hybride et d’Intel Thread Director que de ce seul réglage.
• Autrement dit, passer à Services d'arrière-plan ne mène pas à une règle aussi simple que « le traitement en arrière-plan va sur un cœur P » ou « les services vont sur un cœur E ».
• Si les craquements audio ou les dropouts proviennent du DPC / ISR, de l’économie d’énergie USB, des pilotes, du thermal throttling ou de l’EcoQoS, ce réglage seul ne les corrigera pas.

En une phrase, ce réglage ne change pas la fréquence du CPU : il change les règles de la file d’attente.

2. Ce que ce réglage change réellement

L’option Planification du processeur de l’écran de réglages est l’une des politiques d’ordonnancement historiques de Windows. En interne, elle est liée à Win32PrioritySeparation, un réglage qui a une longue histoire.

Il faut d’abord comprendre les bases de la façon dont Windows utilise le CPU.

• Le planificateur choisit d’abord le thread le plus prioritaire parmi les threads exécutables.
• À priorité égale, il les exécute à tour de rôle, pendant un temps fixe chacun.
• Ce « temps fixe » est le quantum (la tranche de temps).

flowchart LR
    ready["Threads exécutables"] --> pick["Le planificateur choisit le thread le plus prioritaire"]
    pick --> run["Exécution pendant 1 quantum"]
    run --> wait{"Y a-t-il des threads en attente de même priorité ?"}
    wait -- yes --> switch["Changement de contexte"]
    switch --> pick
    wait -- no --> run

Ce que Planification du processeur touche principalement, c’est la façon dont ce quantum est réparti et le degré de faveur accordé au premier plan.

Ici, le premier plan désigne l’application que l’utilisateur manipule actuellement. À l’inverse, les traitements passés en arrière-plan, les workers d’autres processus, les services Windows, les processus auxiliaires et les traitements résidents tendent à se retrouver du côté de l’arrière-plan.

Le point important est que choisir Services d'arrière-plan ne transforme pas votre application en service Windows. Ce qui change n’est pas la catégorie nommée « service », mais les règles de répartition du CPU entre premier plan et arrière-plan. Le nom prête ici sérieusement à confusion.

3. Ce qui change entre Programmes et Services d'arrière-plan

La différence est plus facile à saisir sous forme de tableau.

Windows pour poste client est fondamentalement conçu pour que l’application au premier plan reste agréable à utiliser. C’est pourquoi, pour un usage bureautique ordinaire, Programmes est le choix naturel.

Il existe cependant des cas où la donne change.

• Un traitement audio qui remplit continuellement un tampon en arrière-plan
• Une capture ou une analyse qui s’exécute en continu sur un autre thread / processus pendant que l’UI reste légère
• Le cas où l’on veut respecter les échéances du traitement en arrière-plan même avec un navigateur ou un IDE au premier plan
• Des charges de travail plutôt orientées serveur, service ou résident

Dans ces cas, la stabilité est meilleure quand le traitement en arrière-plan peut facilement reprendre la main sur le CPU, plutôt que de fortement favoriser uniquement le premier plan. En ce sens, Services d'arrière-plan peut être un choix pertinent.

4. Pourquoi cela peut aider pour l’audio et les traitements continus

Prendre l’exemple des craquements et des dropouts audio permet d’y voir plus clair.

Pour le traitement audio, « être rapide en moyenne » ne suffit pas. Toutes les quelques millisecondes, voire à une échelle encore plus courte, il faut remplir le tampon avant l’instant requis. Même avec une utilisation CPU moyenne faible, si le thread ne peut pas s’exécuter précisément à cet instant, l’audio se coupe.

Voici une situation concrète.

• Un navigateur, l’UI d’un DAW ou une autre application occupe le premier plan
• En arrière-plan, un thread de traitement audio tourne à cycle fixe et alimente le tampon
• Ce thread audio n’a pas une priorité très élevée, et n’exploite pas pleinement MMCSS ni le QoS
• Le CPU est raisonnablement chargé

Dans ce contexte, avec Programmes, l’application au premier plan tend à s’exécuter en tranches plus longues, et le traitement audio en arrière-plan peut se retrouver « correct en moyenne, mais en retard précisément à cet instant ». Si cela se répète, il en résulte un underrun, qui se traduit par des craquements.

À l’inverse, en basculant sur Services d'arrière-plan, le traitement continu en arrière-plan reprend plus facilement la main sur le CPU, ce qui peut réduire le risque de manquer les échéances.

Autrement dit, quand ce réglage aide, ce qui se produit n’est pas « le CPU est devenu plus rapide », mais plutôt :

• la faveur accordée à l’application au premier plan s’affaiblit légèrement
• le nombre et le moment des occasions pour le traitement continu en arrière-plan de s’intercaler s’améliorent
• il en résulte moins d’échéances manquées

voilà l’enchaînement.

5. Les principes - quantum et faveur au premier plan

En regardant un peu plus bas niveau, voici la logique de son fonctionnement.

5.1 Avec un quantum plus long, les threads de même priorité attendent davantage

Lorsque plusieurs threads sont en concurrence dans la même bande de priorité, plus l’un d’eux reçoit un quantum long, plus les autres ont tendance à attendre.

Avec un réglage qui favorise l’application au premier plan, le côté premier plan a tendance à s’exécuter en continu plus longtemps. Le côté arrière-plan, à priorité comparable, se voit alors plus souvent répondre « pas maintenant ».

Pour les traitements qui veulent tourner un peu à la fois, mais régulièrement — audio, vidéo, mesure périodique, polling, surveillance — cette différence se fait sentir.

5.2 Windows prend soin du premier plan de plusieurs façons

Windows accorde depuis toujours une attention considérable au premier plan. En voici les mécanismes représentatifs.

• La faveur accordée au processus passé au premier plan
• La faveur accordée au thread propriétaire de la fenêtre qui reçoit les entrées
• Le boost dynamique de priorité accordé au thread après la fin d’une E/S

Autrement dit, le simple fait de sortir une application du premier plan change bel et bien son traitement par le planificateur. Il est plus facile de comprendre Services d'arrière-plan en le voyant comme un réglage qui réduit, parmi ces faveurs accordées au premier plan, spécifiquement le déséquilibre dans la répartition du temps CPU.

5.3 « Empêcher le CPU de se relâcher » : une idée à moitié juste, à moitié à côté

L’expression « empêcher le CPU de se relâcher » se comprend intuitivement. Dans le sens où le traitement en arrière-plan est moins facilement remis à plus tard, c’est effectivement vrai.

Mais techniquement, il vaut mieux être plus précis : ce qui change réellement, ce n’est pas tant le contrôle d’inactivité du CPU ou sa fréquence elle-même, que l’ordre et la durée d’exécution des threads.

C’est pourquoi ce réglage :

• n’augmente pas le turbo boost
• ne désactive pas les C-states
• ne modifie pas directement le core parking
• ne fixe rien sur un cœur P

6. Comment cela se traduit sur un CPU à cœurs P / E

C’est le point le plus souvent mal compris.

Passer à Services d'arrière-plan ne fait pas simplement décider à Windows « c’est un traitement en arrière-plan, donc un cœur E » ou « c’est le premier plan, donc un cœur P ». Sur le Windows actuel, en particulier Windows 11 sur un CPU hybride, le choix entre cœur P et cœur E se fait à travers bien plus d’étapes.

6.1 Des noms similaires, mais des choses différentes

Il existe d’abord deux choses distinctes portant des noms similaires.

1. Services d'arrière-plan de Planification du processeur
   • Un réglage de l’ancienne interface
   • Agit principalement sur la répartition du temps CPU entre premier plan et arrière-plan
   • Relève de la famille du quantum et du boost du premier plan
2. Les niveaux de QoS tels que Utility / Eco / Low
   • La classification power / performance du Windows moderne
   • Agit aussi sur la sélection des cœurs et le contrôle de la fréquence
   • Directement liée au comportement des cœurs P / E

Ces deux choses ne sont pas identiques.

6.2 QoS et visibilité sous Windows 11

Sur le Windows actuel, le QoS entre en jeu en plus de la priorité. En particulier sur un processeur hétérogène — c’est-à-dire une configuration à cœurs P / E — le QoS influence le type de cœur qui sera préféré.

Voici, à grands traits, la classification de Windows 11.

Ce qui importe ici, c’est que le simple fait de réduire une fenêtre peut suffire à changer son QoS. Autrement dit, sur un ordinateur portable à CPU hybride :

• l’application a quitté le premier plan
• puis elle a été réduite
• son QoS a baissé en conséquence
• elle est devenue plus susceptible d’être placée sur un cœur E
• le ressenti ou les échéances se sont dégradés

— ce scénario se produit tout à fait couramment.

6.3 Thread Director et la planification hybride

Sur les CPU hybrides Intel de 12e génération et suivantes, Intel Thread Director fournit des indications à l’OS. Windows 11 les utilise pour décider plus intelligemment de l’attribution des cœurs P / E.

Windows dispose en outre de politiques de planification hétérogène.

• SchedulingPolicy
• ShortSchedulingPolicy
• ShortThreadRuntimeThreshold

Réglées sur Automatic, ces politiques signifient que c’est l’OS qui décide en fonction du QoS et de la configuration du système. En coulisses, le moteur de core parking et le moteur d’état de performance de la gestion de l’alimentation du processeur sont eux aussi à l’œuvre.

Voici, dans les grandes lignes, une façon simple de se représenter l’ensemble.

flowchart TD
    t["Thread"] --> p["Priorité / priorité dynamique"]
    t --> q["QoS (High / Medium / Low / Utility / Eco / Deadline)"]
    t --> v["Visibilité / état audible / état de saisie"]
    t --> h["Politique de planification hybride<br/>SCHEDPOLICY / SHORTSCHEDPOLICY"]
    t --> td["Indications d'Intel Thread Director<br/>Windows 11 sur CPU hybride Intel"]
    v --> q
    p --> s["Planificateur Windows + Processor Power Management"]
    q --> s
    h --> s
    td --> s
    s --> c["Le cœur P / E et la fréquence sont déterminés"]

7. Dans quels cas cela aide, et dans quels cas non

En pratique, il est plus rapide de distinguer les cas où ce réglage a tendance à aider des cas qui relèvent d’un tout autre problème.

7.1 Les cas où cela a tendance à aider

Dans les situations suivantes, Services d'arrière-plan peut être une mesure bien ciblée.

• Le fait de donner le focus à une application au premier plan déstabilise seulement le traitement continu en arrière-plan
• L’utilisation du CPU n’est pas saturée, et pourtant seul le traitement périodique manque ses échéances
• Le traitement critique se trouve dans une application legacy, un processus auxiliaire ou un worker thread, sans usage suffisant de MMCSS ou du QoS
• Un service ou un traitement résident est l’élément central, et la stabilité du traitement en arrière-plan compte plus que le confort de l’UI au premier plan

7.2 Les cas où cela aide peu, ou où le problème est ailleurs

À l’inverse, certains problèmes ne se résolvent pas avec ce seul réglage.

• Une latence DPC / ISR importante
• Un défaut du contrôleur USB ou du pilote audio
• Les effets de l’USB selective suspend ou de l’économie d’énergie des périphériques
• Le thermal throttling
• Les effets de l’économiseur de batterie, du power throttling ou de l’EcoQoS
• Une taille de tampon trop petite
• Le cas où l’application utilise déjà correctement MMCSS / Deadline, et où le problème se situe ailleurs

En particulier sur un ordinateur portable Windows 11 à CPU hybride, les changements de visibilité et de QoS pèsent lourd. Si le ralentissement n’apparaît qu’à la réduction de la fenêtre ou seulement sur batterie, il est plus efficace de soupçonner le QoS ou l’alimentation plutôt que Planification du processeur.

8. Comment aborder cela en pratique

Pour l’isolation concrète du problème, l’ordre suivant est le plus clair.

1. Fixer les conditions
   • Alimentation secteur ou batterie
   • Mode d’alimentation
   • Taille du tampon
   • État premier plan / visible / réduit
2. Comparer Programmes et Services d'arrière-plan dans les mêmes conditions
   • Noter non seulement le ressenti, mais aussi le nombre de dropouts, le nombre de glitches et le retard de traitement
3. Sur Windows 11 / CPU hybride, soupçonner le QoS
   • Le problème ne s’aggrave-t-il qu’à la réduction de la fenêtre ?
   • Change-t-il selon l’état audible ?
   • Ne s’aggrave-t-il que sur batterie ?
4. Pour l’audio ou la vidéo, regarder d’abord MMCSS
   • Les threads critiques indiquent-ils bien à Windows « ceci a une échéance importante » ?
5. Si le problème persiste, creuser du côté DPC / ISR / USB / pilotes
   • À ce stade, le sujet dépasse déjà la planification du processeur

En pratique, « l’échéance a-t-elle été respectée » compte plus que l’utilisation moyenne du CPU. C’est un point tout à fait essentiel.

9. Résumé

Pour résumer très brièvement ce qui se produit en passant Planification du processeur sur Services d'arrière-plan :

• Ce qui change n’est pas la vitesse du CPU elle-même, mais la répartition du temps CPU entre le premier plan et l’arrière-plan
• Programmes a tendance à rendre l’application au premier plan agréable à utiliser
• Services d'arrière-plan rend le traitement continu en arrière-plan moins facile à évincer
• C’est pourquoi, dans des cas où les échéances en arrière-plan comptent — audio, vidéo, capture, surveillance, traitement résident — cela peut aider
• Cependant, sur un CPU à cœurs P / E, le placement réel des cœurs est aussi fortement piloté par le QoS, la politique d’alimentation, la planification hybride et Thread Director
• C’est pourquoi, sur le Windows d’aujourd’hui, il est naturel de considérer que ce réglage peut aider, mais n’est pas le seul acteur principal

En somme, ce n’est pas un bouton qui augmente la puissance du CPU, mais un bouton qui change la répartition du travail.

Faut-il privilégier la réactivité de l’application au premier plan, ou faciliter le respect des échéances du traitement continu en arrière-plan ? Considérer ce réglage comme un moyen de déplacer légèrement cet équilibre vers l’arrière-plan permet de bien saisir son fonctionnement.

Et à l’ère des CPU hybrides, une couche supplémentaire de QoS et de sélection de cœur P / E vient encore se superposer. En prenant tout cela en compte, on comprend mieux « pourquoi cela aide parfois » et « pourquoi cela n’aide pas toujours ».

10. Références

• Sawady : réglage de Windows pour privilégier les services d’arrière-plan (empêcher le CPU de se relâcher)
• 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

Articles associés

Articles récents partageant les mêmes étiquettes, pour approfondir des sujets proches.

Sujets associés

Ces pages replacent le sujet dans un contexte plus large de services et de décisions.

Services liés à ce sujet

Cet article est directement lié aux services suivants.

Questions fréquentes

Questions souvent posées lors d’une consultation sur le sujet de cet article.

Que change-t-on en réglant « Planification du processeur » sur « Services d'arrière-plan » ?

Ce qui change n'est pas la vitesse ou la fréquence du CPU, mais la façon dont le temps CPU est réparti entre l'application au premier plan et les traitements qui tournent en arrière-plan. En interne, ce réglage est lié à Win32PrioritySeparation et agit sur la répartition du quantum (tranche de temps) et sur le degré de faveur accordé au premier plan. `Programmes` a tendance à favoriser l'application au premier plan, tandis que `Services d'arrière-plan` traite le premier plan et l'arrière-plan de façon plus équilibrée. Notez que choisir ce réglage ne transforme pas pour autant votre application en un service Windows.

Pourquoi passer à « Services d'arrière-plan » peut-il corriger les craquements audio ?

Parce que le traitement audio ne se contente pas d'être rapide en moyenne : il doit remplir son tampon avant une échéance qui revient toutes les quelques millisecondes. Avec le réglage `Programmes`, l'application au premier plan a tendance à s'exécuter en tranches plus longues, et le traitement audio en arrière-plan peut, même s'il est correct en moyenne, accuser un retard précisément à cet instant-là, ce qui provoque un underrun. En basculant sur `Services d'arrière-plan`, le traitement continu en arrière-plan reprend plus facilement la main sur le CPU, ce qui peut réduire les échéances manquées. Cela dit, si le problème vient de la latence DPC/ISR, de l'économie d'énergie USB, d'un défaut de pilote, du thermal throttling ou de l'EcoQoS, ce réglage seul ne le corrigera pas.

Passer à « Services d'arrière-plan » fait-il tourner les traitements en arrière-plan sur un cœur P ?

Non. Le choix entre cœur P et cœur E dépend bien davantage du QoS, de la politique d'alimentation, de la planification hybride (hybrid scheduling) et d'Intel Thread Director que de ce seul réglage. Sous Windows 11, il est tout à fait courant que le simple fait de réduire une application fasse baisser son QoS et la rende plus susceptible d'être placée sur un cœur E lorsque l'appareil fonctionne sur batterie. Si le ralentissement n'apparaît qu'à la réduction de la fenêtre ou que sur batterie, il est plus pertinent de soupçonner le QoS ou l'alimentation plutôt que ce réglage.

Comment isoler la cause des craquements audio ou des dropouts ?

Commencez par fixer les conditions — alimentation secteur, mode d'alimentation, taille du tampon, état premier plan/réduit — puis comparez `Programmes` et `Services d'arrière-plan` dans les mêmes conditions en notant le nombre de dropouts et le retard de traitement. Sur un CPU hybride sous Windows 11, vérifiez si le problème n'apparaît qu'à la réduction de la fenêtre ou sur batterie, ce qui orienterait vers le QoS. Pour l'audio ou la vidéo, vérifiez d'abord si les threads critiques utilisent bien MMCSS ; si le problème persiste, creusez du côté DPC/ISR, USB et pilotes. Rendu à ce stade, le sujet dépasse déjà la planification du processeur.

Profil de l’auteur

Page de présentation de l’auteur de l’article.

Go Komura

Représentant de KomuraSoft LLC

Spécialisé dans le développement de logiciels Windows, le conseil technique et l’analyse de pannes, notamment pour les systèmes existants et les incidents difficiles à reproduire.