Comment les priorités fonctionnent-elles sur le gestionnaire de tâches et quand ne dois-je pas définir cela?
J'ai défini des processus prioritaires afin de voir ce qui se passe réellement, mais devinez quoi ... Rien; tout se passe de la même façon ...
J'ai trouvé sur Google que les priorités ne sont pas vraiment liées à la vitesse de traitement, est-ce vrai? Pourquoi pas alors? si un processus a la plus haute priorité, ne devrait-il pas aller plus vite ??
Supposons que vous ayez une carte "aller au bout de la ligne" pour l'épicerie. Vous allez au magasin, remplissez votre panier, allez aux caisses et constatez qu'il n'y a personne en ligne. Votre carte vous aide-t-elle à vérifier plus rapidement? Nan.
Les priorités n'affectent pas la vitesse de traitement, en ce sens qu'un processus de priorité supérieure ne peut pas s'exécuter plus rapidement, ni même utiliser plus de temps processeur ... pas si c'est la seule chose qui veuille utiliser le processeur
Pour vraiment parler de cela, nous devons mentionner les discussions. Les processus ne "fonctionnent" pas dans Windows. Les threads, qui font partie des processus, sont ce qui est exécuté. (Bien que si un processus ne comporte qu'un seul thread, la distinction est plutôt floue de l'extérieur.)
(Au fait: la terminologie marketing selon laquelle un processeur a, par exemple, "quatre cœurs et huit threads", est trompeuse. Les processeurs ont des cœurs, mais les processeurs n'ont pas "de" threads. Les threads font partie de processus. Un cœur de processeur sans hyperthreading activé , vous pouvez exécuter un fil; avec l'hyperthreading activé, un cœur peut exécuter deux threads. Mais les processeurs ne disposent pas de "threads".)
Chaque thread est toujours dans l'un des états de planification. Les états les plus fréquemment observés sont: Waiting (* nix appelle cela "bloqué"; dans les deux systèmes d'exploitation, cela signifie attendre une entrée/sortie ou similaire, ne pas utiliser de temps processeur et n'en vouloir aucun ) Ready (veut utiliser le temps processeur, mais aucun processeur n'est disponible pour le moment); et en cours d'exécution . Seuls les threads en cours d'exécution consomment du temps CPU; Autrement dit, si un processus ne comporte pas de threads en cours d'exécution, on constatera qu'il utilise zéro% de temps CPU dans des outils tels que le Gestionnaire des tâches.
Un thread ne peut être exécuté que sur un seul cœur à la fois (ou, si l'hyperthreading est activé, "processeur logique"), de sorte qu'un processus ne peut utiliser que le nombre de cœurs de processeur (ou de 33) qu'il a de threads à exécuter à l'heure actuelle . (La même déclaration peut être faite du système dans son ensemble.)
La plupart des threads sur la plupart des systèmes passent le plus clair de leur temps en état d'attente. (C'est pourquoi votre processus inactif devrait dépasser 95% du temps CPU lorsque votre système ne fait rien.) Les exceptions sont les threads "en fonctionnement", tels que la vidéo ou le rendu 3D, les jeux, etc. Très peu de threads pourrait vraiment utiliser 100% de la CPU, car ils doivent généralement travailler sur des données d'entrée qu'ils doivent lire quelque part, et ils créent généralement des données de sortie qui doivent être écrites quelque part. Et ils peuvent faire référence à de nombreuses données différentes en mémoire au fil du temps, ce qui peut les obliger à attendre que les défauts de page matériels soient résolus.
Mais les threads effectuant quelque chose comme le rendu vidéo ou le rendu d'image 3D pourraient bien passer presque tout leur temps à "calculer" dans la CPU, et très peu d'attentes pour les E/S. Ces threads sont souvent appelés "liés au calcul", ce qui signifie que leurs performances globales sont principalement limitées par la vitesse du processeur.
Le paramètre que vous définissez dans le Gestionnaire des tâches établit la "priorité de base" pour tous les threads du processus. La priorité réelle ou "actuelle" du thread peut être supérieure (mais jamais inférieure à la base). Plus sur cela dans un instant. Les décisions de planification ("qui exécute et sur quel processeur") sont toujours prises en utilisant la priorité actuelle du thread. La priorité n'a de sens que pour les threads Prêt et En cours d'exécution (ou, inversement, la priorité n'a pas de sens pour les threads En attente).
Windows utilise un algorithme de planification préemptif . Si un seul thread du système veut utiliser le temps processeur, peu importe sa priorité; il obtient 100% de la CPU. Ce n'est pas comme si le planificateur "retenait" une partie des capacités de la CPU lorsqu'un thread à faible priorité était en cours d'exécution, juste au cas où quelque chose de plus élevé se présenterait.
Si deux threads souhaitent utiliser un processeur et qu'ils ont la même priorité, ils sont planifiés via ce que l'on appelle "découpage temporel" et, avec le temps, chacun récupère environ 50% du temps du processeur. Alors que s'ils ont des priorités différentes, le thread de priorité plus élevée obtient 100% et les plus faibles rien .
(En pratique, il n’obtiendra rien, car il subira périodiquement une "augmentation prioritaire de la prévention de la famine" qui peut lui donner quelques dizaines de ms toutes les 4 ou 5 secondes environ. Mais ce n’est pas vraiment une exception à la "priorité supérieure" gagne ", car cela se fait en ajustant la priorité du thread affamé.)
Si vous avez plus d'un cœur de processeur, les choses deviennent plus intéressantes et les priorités en général ont un effet inférieur . Supposons que vous ayez deux threads à exécuter. Et supposez que vous ayez deux cœurs de processeur ou plus qui ne font rien d'autre de priorité égale ou supérieure à ces threads. Ensuite, vos deux threads recevront chacun 100% d'un noyau quelles que soient leurs priorités respectives .
(Deux personnes se présentent au supermarché et il y a deux contrôleurs gratuits. Un des clients a une carte "aller au bout de la ligne". Peu importe.)
tl; dr version (jusqu'à présent): les priorités ne sont pas de savoir "qui obtient quelle proportion de temps CPU", mais plutôt "qui exécute en premier".
Je ne vais pas entrer beaucoup dans l'hyperthreading ici, sauf pour dire que Windows traite chacun des deux "processeurs logiques" dans un noyau à peu près de la même manière qu'il traiterait un noyau si HT était désactivé. c'est-à-dire qu'ils sont traités comme de "vrais" processeurs, à cette exception près: Windows fera de son mieux pour ne pas utiliser plus d'un LP à la fois. c'est-à-dire que vous ne commencez normalement pas à voir les deux disques d'un noyau en cours d'utilisation tant que vous n'avez pas plus de threads à nombre de cœurs essayant de tout exécuter en même temps. En effet, les deux "processeurs logiques" ne vous offrent pas deux fois les performances d'un noyau non hyperthreadé.
À propos de la "priorité de base": Windows ajustera ("boost" et "decay") la priorité actuelle des threads en fonction de ce qu’ils ont fait récemment. Les threads qui ont récemment effectué des opérations d'E/S auront normalement une encoche ou deux au-dessus de la base; Les threads d'interface utilisateur (les threads qui exécutent une fenêtre) seront souvent beaucoup plus élevés; Les threads liés au CPU seront généralement à leur base. Le but de cela est de maintenir la réactivité dans l'interface utilisateur du programme, ainsi que de garder IO requêtes circulant dans des éléments tels que les disques.
Un programme (processus) peut également modifier la priorité de base de chacun de ses threads, dans une plage déterminée par la priorité du processus (l'élément défini dans le Gestionnaire de tâches). Mais la grande majorité des programmes ne dérange pas. (Plusieurs devraient le faire.)
Il y a d'autres choses qui se passent. En raison de la priorité boost/decay, et parce que les systèmes multitraitement (multicoeur, ou hyperthread, ou les deux) sont si courants de nos jours, et parce qu'il y a toujours des choses qui fonctionnent en arrière-plan dans Windows (mais, espérons-le, n'utilisant pas beaucoup de temps processeur), et en raison des effets d'une "affinité" dure et douce, il est difficile d'exécuter des cas de test et d'obtenir les résultats exacts qui seraient prédits ici. Mais cela devrait vous donner presque une image correcte.
En conclusion...
Il est raisonnable de laisser la plupart des choses à "Normal". Si vous ne le faites pas, vous risquez facilement de vous priver de quelque chose que vous aimeriez vraiment voir fonctionner (même si vous ignorez peut-être qu'il existe), comme les fonctions de vidage du cache disque du système d'exploitation. En effet, de nombreux processus du système d’exploitation ne seront pas normaux et ils devraient être laissés où que Windows les mette.
Un cas raisonnable pour utiliser le Gestionnaire des tâches pour modifier les priorités consiste à effectuer une tâche fastidieuse (comme le rendu vidéo ou 3D) et à ralentir votre utilisation du système en cours d'exécution. Croyez-le ou non, le mieux est d’abaisser sa priorité d’un cran ou deux. Il utilisera avec plaisir tous les cycles de la CPU, ce que rien ne veut, mais restera à l'écart de votre utilisation interactive du système. Son travail peut prendre un peu plus de temps, mais il le fera avec un minimum d'interférences dans votre utilisation interactive d'autres programmes. Si vous n'aimez pas ce compromis, ne le faites pas! Mais essayez de lui donner une priorité élevée pour tenter de "l'accélérer" et votre interface utilisateur restera suspendue jusqu'à la fin.
Ne définissez jamais rien sur la soi-disant classe de priorité Realtime.
(Édition - ce paragraphe ajouté) Ok, c'est une déclaration extrême. ("Aucune affirmation universelle n’est vraie - à l’exception de celle-ci.") Du moins, pas sans un examen très attentif. Si votre objectif est de faire fonctionner quelque chose plus rapidement, cela ne vous aidera probablement pas. Mais cela pourrait "verrouiller durement" votre système (nécessitant une réinitialisation ou, sur la plupart des machines modernes, un cycle d'alimentation). Ou rendez-le si insensible qu'il pourrait tout aussi bien rester bloqué.
n.b .: Toute application de lecteur vidéo doit choisir la fonctionnalité "Planification de classe multimédia" de Vista et versions ultérieures. Cela lui donnera automatiquement jusqu'à 80% d'un processeur, calculé sur des intervalles relativement courts. Si vous ne pouvez pas obtenir une lecture sans problème avec ce que quelque chose est très faux.
Pour plus de détails, voir les chapitres sur les threads et la planification dans Windows Internals 6th Edition de Solomon, Russinovich et Ionescu.
Voir aussi ma réponse ici pour plus d'informations sur la définition des priorités de processus et de threads, ainsi que sur la signification de la colonne "Priorité" dans le Gestionnaire des tâches.
La modification des priorités modifie la manière dont le système d'exploitation attribue le temps processeur aux applications en cours d'exécution. Il ne produit d'effets visibles que si l'utilisation globale du processeur est élevée.
Par exemple, vous encodez une vidéo et regardez une vidéo différente en même temps. Probablement, l’application de codage utilisera 100% de la puissance de calcul de tous vos cœurs de processeur. En conséquence, d'autres applications peuvent bégayer.
Windows donnera par défaut la même priorité "normale" aux deux applications. À ce stade, vous souhaiterez peut-être augmenter la priorité de votre logiciel de lecture de film. De cette manière, la lecture de votre vidéo sera fluide au détriment d’un codage vidéo plus lent car le logiciel de codage sera dégradé en un processus en arrière-plan par rapport au lecteur vidéo.