Administration de Windows

Dans le noyau de Windows Vista : Partie 1

Mark Russinovich

Vue d'ensemble:

• Priorité et planification des threads
• Liens symboliques basés sur des fichiers
• Annulation d'opérations E/S

Ce document est le premier d'une série s'intéressant aux nouveautés du noyau de Windows Vista. Dans ce numéro, j'aborderai les modifications des zones de processus, des threads et des E/S. Les articles futurs couvriront la gestion de mémoire, le démarrage et l'arrêt, la fiabilité et la récupération ainsi que la sécurité.

La portée de cet article s'étend uniquement aux modifications apportées au noyau de Windows Vista™, et plus particulièrement à Ntoskrnl.exe et aux composants qui lui sont étroitement associés. N'oubliez pas que beaucoup d'autres modifications significatives apportées à Windows Vista ne concernent pas le noyau lui-même et ne seront donc pas abordées. Ceci concerne les améliorations apportées à l'interpréteur de commandes (comme l'intégration de desktop search), la mise en réseau (comme la nouvelle pile IPv6 et le pare-feu bidirectionnel) et les modèles de graphiques de prochaine génération (tels qu'Aero™ Glass, Windows® Presentation Foundation, le Gestionnaire de fenêtres du Bureau et le nouveau modèle de pilote d'affichage graphique). Les nouvelles infrastructures de pilote en mode utilisateur et en mode noyau de Windows (UMDF et KMDF) ne sont pas non plus couvertes puisqu'elles sont rétro-installables sur les versions précédentes de Windows.

Comptage des cycles microprocesseur

Windows Vista intègre plusieurs améliorations des processus et des threads parmi lesquelles l'utilisation du compteur de cycles microprocesseur pour une meilleure allocation processeur et le nouveau Service Planificateur de classes multimédias (MMCSS) qui aide les applications multimédias à offrir une lecture dépourvue de problème.

Toutes les versions de Windows NT® jusqu'à, et y compris, Windows Vista programment une routine d'interruption du temporisateur d'intervalles qui s'exécute environ toutes les 10 à 15 ms (millisecondes), selon la plate-forme matérielle. La routine examine le thread qu'elle a interrompu et met à jour les statistiques d'utilisation du processeur du thread comme si ce thread s'était exécuté pendant tout l'intervalle alors qu'il se pourrait en fait que le thread ait commencé à s'exécuter juste avant la fin de l'intervalle. De plus, il se pourrait que le processeur ait été techniquement attribué au thread mais que celui-ci n'ait pas eu l'occasion de s'exécuter parce que les routines d'interruption logicielle et matérielle se sont exécutées à la place.

Alors que la gestion du temps basée sur horloge convient à des outils de diagnostic qui signalent l'utilisation du processeur de thread et de processus, l'utilisation de cette méthode par le planificateur de threads peut causer une allocation processeur injustifiée. Par défaut, sur les versions client de Windows, les threads sont autorisés à s'exécuter pendant deux tic-tac d'horloge au maximum (6 s'ils sont au premier plan). Cependant, le thread peut ne pratiquement pas obtenir de temps sur le processeur ou jusqu'à 6 tics tacs (18 s'il est au premier plan) en fonction de son comportement et du reste de l'activité sur le système.

La figure 1 illustre les situations injustifiées qui peuvent survenir lorsque deux threads dotés de la même priorité sont prêts à s'exécuter en même temps. Le thread A s'exécute jusqu'à l'expiration du prochain intervalle de tranche horaire alors que le planificateur suppose qu'il s'est exécuté pendant tout l'intervalle et décide que son tour est fini. En outre, le thread A se voit attribuer à tort la responsabilité de l'interruption survenue pendant son tour. À l'intervalle suivant, le planificateur choisit le thread B pour prendre la relève et celui-ci s'exécute pendant tout l'intervalle.

Figure 1** Planification injuste des threads **

Dans Windows Vista, le planificateur utilise le registre du compteur de cycles des processeurs modernes pour déterminer précisément combien des cycles microprocesseur un thread exécute. En estimant combien de cycles le processeur peut exécuter dans un intervalle d'horloge, il peut distribuer plus précisément les tours sur le processeur. De plus, le planificateur de Windows Vista ne comptabilise pas les interruptions d'exécution au détriment du tour du thread. Ceci signifie que sur Windows Vista un thread obtiendra toujours au moins son tour sur le processeur et jamais plus d'un intervalle d'horloge supplémentaire d'exécution, ce qui assure plus de justesse et un comportement plus déterministe des applications. La figure 2 illustre la façon dont Windows Vista répond au scénario présenté dans la figure 1 en donnant aux deux threads au moins un intervalle de tranche d'heure d'exécution.

Figure 2** Planification basée sur cycles de Windows Vista **

L'encadré « Observation de l'utilisation du processeur par les processus » explique comment vous pouvez vous-même surveiller l'utilisation des cycles microprocesseur grâce à l'utilitaire Process Explorer.

Service Planificateur de tâches multimédias

Les utilisateurs attendent des applications multimédias, y compris des lecteurs de musique et de vidéo, qu'ils leur assurent une expérience de lecture continue. Cependant, les demandes adressées au processeur par d'autres applications s'exécutant simultanément, par exemple l'antivirus, l'indexation de contenu ou même le client de courrier, peuvent provoquer des accrocs déplaisants. Pour assurer une meilleure expérience de lecture, Windows Vista introduit MMCSS pour gérer les priorités des threads multimédias en matière de processeur.

Une application multimédia comme le Lecteur Windows Media® 11 s'enregistre auprès de MMCSS en utilisant les nouvelles API qui indiquent ses caractéristiques multimédias, lesquelles doivent correspondre à l'une de celles répertoriées par nom sous la clé de registre suivante :

HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\Currentversion\Multimedia\SystemProfile\Tasks

Figure A** Affichage du temps processeur et des cycles Delta dans Process Explorer **(Cliquer sur l'image pour l'agrandir)

Figure 3** Définition de tâche audio du Planificateur de tâches multimédias **(Cliquer sur l'image pour l'agrandir)

MMCSS, qui est implémenté dans %SystemRoot%\System32\Mmcss.dll et qui s'exécute dans un processus Hôte de service (Svchost.exe), a un thread de gestion des priorités qui s'exécute à la priorité 27. (Dans Windows, les priorités de thread vont de 0 à 31.) Ce thread rehausse la priorité des threads multimédias inscrits dans la plage associée à la valeur Catégorie de planification de leur clé de registre de tâche telle qu'elle est présentée dans la figure 4. Dans Windows, les priorités de thread de niveau 16 et supérieur se situent dans la plage de priorité en temps réel et sont plus élevées que tous les autres threads sur un système (à l'exception des threads de travail du gestionnaire de mémoire du noyau qui s'exécutent aux priorités 28 et 29). Seuls les comptes d'administrateur, comme le compte Système local dans lequel MMCSS s'exécute, disposent du privilège de pouvoir augmenter la priorité qui est requis pour définir les priorités de thread en temps réel.

Figure 4 Priorités de threads MMCSS

Lorsque vous lisez un fichier audio, le Lecteur Windows Media enregistre des threads de tâches audio et, lorsque vous lisez une vidéo, il enregistre des threads de tâche de lecture. Le service MMCSS augmente tous threads ayant indiqué qu'ils livrent un flux en même temps lorsqu'ils s'exécutent dans le processus qui possède la fenêtre de premier plan et que leur valeur BackgroundOnly est définie sur true dans leur clé de définition de la tâche.

Mais si MMCSS veut aider les threads multimédias à obtenir le temps processeur dont ils ont besoin, il veut également s'assurer que les autres threads obtiennent au moins une certaine quantité de temps processeur pour que le système et les autres applications restent réactives. MMCSS réserve donc un pourcentage de temps processeur, spécifié dans la valeur de registre suivante, aux autres activités :

HKLM\Software\Microsoft\Windows NT\Currentversion\Multimedia\SystemProfile\SystemResponsiveness 

Par défaut, ce pourcentage est de 20 pourcent. MMCSS contrôle l'utilisation du processeur pour s'assurer que les threads multimédias ne sont pas augmentés pour plus de 8 ms sur une période de 10 ms si les autres threads ont besoin du processeur. Pour écarter les threads multimédias pendant les 2 ms restantes, le planificateur ramène leurs priorités dans la plage de 1 à 7.

Vous pouvez voir comment MMCSS augmente la priorité des threads en lisant l'encadré « Comment MMCSS augmente la priorité ».

Liens symboliques basés sur des fichiers

Parmi les modifications apportées aux E/S dans Windows Vista figurent des liens symboliques basés sur les fichiers, un traitement plus efficace de l'achèvement des E/S, une prise en charge complète de l'annulation des E/S et la hiérarchisation des E/S.

Une fonctionnalité du système de fichiers qui, de l'avis de beaucoup, manquait dans NTFS figure enfin dans Windows Vista, à savoir le lien symbolique sur fichier (ou « soft link » comme l'appelle Unix). La version Windows 2000 de NTFS avait introduit des liens symboliques sur répertoire, appelés jonctions de répertoires, qui permettent de créer un répertoire pointant vers un répertoire différent, mais jusqu'à la version Windows Vista, NTFS ne prenait en charge que les liens réels pour les fichiers.

L'une des différences majeures intervenues dans la façon dont Windows résout les liens symboliques et les jonctions de répertoires concerne le lieu où s'effectue le traitement. Windows traite les liens symboliques sur le système local, même lorsqu'ils référencent un emplacement sur un serveur de fichiers à distance. Windows traite directement les jonctions de répertoires qui référencent un serveur de fichiers à distance sur le serveur lui-même. Les liens symboliques sur un serveur peuvent donc faire référence à des emplacements seulement accessibles depuis un client, comme d'autres volumes de clients, alors que les jonctions de répertoires ne le peuvent pas. Pour répondre à ceci, Windows Vista prend en charge le nouveau type de lien symbolique pour les fichiers et les répertoires.

Beaucoup de commandes de système de fichiers ont été mises à jour pour comprendre les implications des liens symboliques. Par exemple, la commande Delete sait qu'elle ne doit pas suivre les liens, ce qui aurait pour résultat la suppression de la cible, mais qu'il faut supprimer le lien à la place. Cependant, toutes les applications n'étant pas en mesure de traiter correctement les liens symboliques, la création d'un lien symbolique requiert le nouveau privilège Créer des liens symboliques qui, par défaut, n'appartient qu'aux administrateurs.

Vous pouvez créer un lien symbolique à partir d'une invite de commande avec la commande Mklink. La commande de répertoire incorporée à l'invite de commande identifie un lien symbolique en le marquant comme <SYMLINK> et en affichant la cible entre crochets, ainsi que l'illustre la figure 5. L'explorateur Windows reconnaît également les liens symboliques et les affiche avec la flèche de raccourci. Vous pouvez voir la cible d'un lien dans l'explorateur en ajoutant la colonne Cible du lien à la fenêtre de navigation.Observation des augmentations de priorité MMCSS

Pour observer l'augmentation des threads que le service MMCSS applique aux threads du lecteur Windows Media, vous pouvez lire une vidéo ou un clip audio, exécuter l'Analyseur de performances, configurer le paramètre d'échelle de diagramme sur 31 (la priorité de thread la plus élevée de Windows) et ajouter le compteur Priorité actuelle à toutes les instances des objets de thread du lecteur Windows Media (Wmplayer.exe) à l'affichage. Un ou plusieurs threads s'exécuteront à la priorité 21.

Figure B** Augmentation de la priorité des threads pour le lecteur Windows Media **(Cliquer sur l'image pour l'agrandir)

Figure 5** Utilisation de Mklink pour créer un lien symbolique **(Cliquer sur l'image pour l'agrandir)

Terminaison et annulation des E/S

Plusieurs modifications du système E/S peuvent améliorer les performances des applications serveur. Ces applications utilisent habituellement un objet de synchronisation appelé un port de terminaison pour attendre la terminaison des requêtes E/S asynchrones. Avant Windows Vista, lorsqu'une telle E/S se terminait, le thread qui avait émis l'E/S exécutait le travail de terminaison E/S. Cela faisait commuter le processus auquel appartenait le thread et interrompait tout ce qui se passait d'autre. Ensuite le système E/S mettait à jour l'état du port de terminaison pour activer un thread qui attendait qu'il change.

Sur Windows Vista, le traitement de la terminaison E/S n'est pas nécessairement exécuté par le thread qui a émis l'E/S mais plutôt par celui qui attend que le port de terminaison l'active. Cette modification relativement mineure évite la planification de thread inutiles et les commutations de contexte qui peuvent dégrader les performances globales du système et de l'application. Pour améliorer encore plus les performances, un serveur peut récupérer les résultats d'opérations E/S multiples depuis une terminaison dans une requête, ce qui évite les transitions vers le mode noyau.

Du point de vue d'un utilisateur final, la modification la plus notable dans le système E/S est probablement la prise en charge par Windows Vista de l'annulation des opérations E/S synchrones. S'il vous est déjà arrivé d'exécuter la commande Net View ou de tenter d'accéder à un partage d'un système distant hors ligne utilisant Windows XP ou Windows Server® 2003, vous avez été confronté à des problèmes avec des opérations E/S qui ne peuvent pas être annulées : l'explorateur de commandes ou fichiers ne répondra pas avant l'expiration du délai d'attente réseau. Une application n'a pas d'autre choix qu'attendre que l'opération échoue parce quelle ne peut en aucune façon informer le pilote de périphérique exécutant l'E/S qu'elle ne s'intéresse plus à l'E/S.

Dans Windows Vista, la plupart des opérations E/S peuvent être annulées, y compris l'E/S d'ouverture de fichier qu'utilisent Net View et l'explorateur. Les applications doivent être mises à jour pour répondre aux requêtes d'annulation d'E/S de l'utilisateur final. Cependant, beaucoup des utilitaires de Windows Vista qui interagissent avec les périphériques ayant des délais disposent de la prise en charge nécessaire. Par exemple, les dialogues d'ouverture de fichier et d'enregistrement utilisés par pratiquement toutes les applications Windows, y compris les applications tierces, activent désormais leur bouton Annuler lors d'une tentative d'affichage du contenu d'un dossier. La commande Net annule également son E/S synchrone lorsque vous appuyez sur les touches Ctrl+C.

Vous pouvez consulter les avantages de l'annulation d'E/S en ouvrant une invite de commande sur Windows Vista et en saisissant :

net view (\\nonexistentmachine)

La commande attendra pendant que Windows tente de contacter le système inexistant, mais vous pouvez taper Ctrl+C pour y mettre fin. Dans Windows XP, Ctrl+C n'a pas d'effet et la commande ne réapparaît pas tant que l'opération réseau n'expire pas.

Un autre type d'E/S ayant causé des problèmes aux utilisateurs dans les versions précédentes de Windows est celui que les pilotes de périphériques n'annulaient pas convenablement parce qu'il n'y avait pas de façon facile pour eux de savoir qu'ils devaient le faire. S'il vous est arrivé de terminer un processus mais d'avoir continué à le voir dans les outils d'affichage de processus, vous avez été témoin d'une situation dans laquelle le pilote de périphérique n'a pas répondu à un arrêt de processus et à une annulation d'E/S émis par le processus qui n'était pas terminé. Windows ne peut pas procéder au nettoyage de processus final tant que toutes les E/S du processus ne se sont pas terminées ou n'ont pas été annulées. Dans Windows Vista, les pilotes de périphériques peuvent facilement s'inscrire pour recevoir des notifications d'arrêts de processus et, de ce fait, la plupart des problèmes de processus impossibles à stopper ont disparu.

Priorité d'E/S

Bien que Windows ait toujours pris en charge la définition de priorités pour l'utilisation du processeur, il n'incluait pas le concept de priorité d'E/S. Sans la priorité d'E/S, les activités d'arrière-plan telles que l'indexation de la recherche, l'analyse des virus et la défragmentation de disque peuvent fortement influer sur la réactivité des opérations de premier plan. Un utilisateur qui lance une application ou ouvre un document alors qu'un autre processus exécute une E/S de disque, par exemple, est confronté à des retards parce que la tâche de premier plan attend l'accès au disque. La même interférence affecte également la lecture en continu de contenus multimédias, comme des chansons, depuis un disque dur.

Windows Vista introduit deux nouveaux types de définitions de priorité d'E/S afin d'aider les opérations E/S de premier plan à obtenir la préférence : priorité sur les opérations E/S individuelles et les réservations de bande passante d'E/S. Le système E/S de Windows Vista inclut en interne la prise en charge de cinq priorités d'E/S, ainsi que l'illustre la figure 6, mais seules quatre de ces priorités sont utilisées (les versions futures de Windows pourront prendre en charge une priorité Élevée).

Figure 6 Priorités d'E/S dans Windows Vista

La priorité par défaut de l'E/S est Moyenne alors que le gestionnaire de mémoire utilise une priorité Critique lorsque il veut écrire des données de mémoire impropres sur le disque alors qu'il reste peu de mémoire, afin de libérer de la place dans la mémoire RAM pour d'autres données et codes. Le Planificateur de tâches de Windows attribue une priorité d'E/S Faible aux tâches ayant une priorité de tâche par défaut. La priorité spécifiée par les applications écrites pour Windows Vista qui exécutent le traitement d'arrière-plan est Très faible. Toutes les opérations d'arrière-plan de Windows Vista, y compris l'analyse de Windows Defender et l'indexation de Windows Search, utilisent une priorité d'E/S Très faible.Voir un exemple de priorité d'E/S Très faible

Le moniteur de traitement, un système de fichiers en temps réel et utilitaire de contrôle de registre de Sysinternals, recueille des informations détaillées pour les opérations de lecture et d'écriture du système de fichiers, y compris leurs priorités d'E/S dans Windows Vista. La ligne soulignée montre un exemple d'une E/S de priorité Très faible qui a été émise par SuperFetch (j'aborderai ce sujet dans mon prochain article).

Figure C** Voir une priorité d'E/S Très faible dans le moniteur de traitement **(Cliquer sur l'image pour l'agrandir)

Le pilote de périphérique de classe du système de stockage (%SystemRoot%\System32\Classpnp.sys) applique les priorités d'E/S qui s'appliquent automatiquement aux E/S dirigées vers la plupart des périphériques de stockage. Les pilotes de classe et autres pilotes de stockage insèrent les E/S Moyennes devant celles dont la priorité est Faible et Très faible dans leurs files d'attente, mais ils émettent chaque seconde au moins une E/S Faible ou Très faible en attente afin que les processus d'arrière-plan puissent progresser. Les données lues à l'aide d'E/S de priorité Très faible incitent également le gestionnaire de cache à écrire immédiatement les modifications sur le disque au lieu de le faire plus tard et à contourner sa logique de lecture anticipée pour les opérations de lecture qui, sans cela, liraient de façon prioritaire depuis le fichier en cours d'accès. Examinez l'encadré « Voir un exemple de priorité d'E/S Très faible » si vous recherchez un exemple de priorité d'E/S Très faible utilisant l'utilitaire Moniteur de traitement.

La prise en charge de la réservation de bande passante dans Windows Vista est utile pour les applications de lecteur de médias. Le lecteur Windows Media l'utilise, ainsi que les augmentations de priorité de MMCSS, pour offrir une lecture pratiquement sans accroc des contenus locaux. Une application de lecteur multimédia demande au système d'E/S de lui garantir la capacité de lire des données à un taux spécifié. Si le périphérique peut livrer des données au taux demandé et que les réservations existantes le permettent, il suggère à l'application à quelle vitesse elle doit émettre les E/S et de quelle taille les E/S doivent être. Le système E/S n'entretiendra pas autres E/S à moins qu'il soit en mesure de satisfaire les exigences d'applications qui ont fait des réservations sur le périphérique de stockage cible.

Une dernière modification apportée au système E/S et liée à la taille des opérations E/S mérite d'être évoquée. Depuis la première version de Windows NT, le gestionnaire de mémoire et le système E/S ont limité à 64 Ko la quantité de données traitées par une requête E/S de stockage individuelle. Ainsi, même si une application émet une requête E/S beaucoup plus importante, celle-ci est décomposée en requêtes individuelles d'une taille maximale de 64 Ko. Chaque E/S est soumis à un temps de traitement pour les transitions vers le mode noyau et l'établissement d'un transfert d'E/S sur le périphérique de stockage. Dans Windows Vista, les tailles de requête E/S de stockage ne sont donc plus plafonnées. Plusieurs composants du mode utilisateur de Windows Vista ont été modifiés pour profiter de la prise en charge d'E/S plus importantes, notamment la fonctionnalité de copie de l'explorateur et la commande Copy de l'invite de commande, qui émettent maintenant des E/S de 1 Mo.

À venir

Vous venez de découvrir deux domaines dans lesquels le noyau de Windows Vista a été amélioré. Vous pouvez retrouver d'autres informations détaillées dans la prochaine édition de mon livre Windows Internals (rédigé en collaboration avec David Salomon) qui devrait paraître en même temps que la prochaine version de Windows Server, nom de code « Longhorn ». Dans mon prochain article, je continuerai à vous présenter le nouveau noyau en abordant la gestion de mémoire ainsi que le démarrage et l'arrêt du système.

Mark Russinovich est technicien dans le service responsable des plateformes et services chez Microsoft. Coauteur de l'ouvrage intitulé Microsoft Windows Internals (Microsoft Press, 2004), il participe fréquemment à des conférences pour informaticiens et développeurs. Il a rejoint récemment rejoint nos équipes lorsque Microsoft a racheté Winternals Software, la société dont il était le cofondateur. Il a également créé la société Sysinternals qui a publié les utilitaires Process Explorer, Filemon et Regmon.

© 2008 Microsoft Corporation et CMP Media, LLC. Tous droits réservés. Toute reproduction, totale ou partielle, est interdite sans autorisation préalable.