Groupes de processeurs

  • Article

Les versions 64 bits de Windows 7 et Windows Server 2008 R2 et versions ultérieures de Windows prennent en charge plus de 64 processeurs logiques sur un seul ordinateur. Cette fonctionnalité n’est pas disponible sur les versions 32 bits de Windows.

Les systèmes avec plusieurs processeurs physiques ou avec des processeurs physiques qui possèdent plusieurs cœurs fournissent au système d’exploitation plusieurs processeurs logiques. Un processeur logique est un moteur de calcul logique unique du point de vue du système d’exploitation, de l’application ou du pilote. Un cœur est une unité de processeur, qui peut se composer d’un ou plusieurs processeurs logiques. Un processeur physique peut se composer d’un ou plusieurs cœurs. Un processeur physique est identique à un package de processeur, à un socket ou à un processeur.

La prise en charge des systèmes qui ont plus de 64 processeurs logiques est basée sur le concept d’un groupe de processeurs, qui est un ensemble statique allant jusqu’à 64 processeurs logiques traités comme une entité de planification unique. Les groupes de processeurs sont numérotés à partir de 0. Les systèmes avec moins de 64 processeurs logiques ont toujours un seul groupe, le groupe 0.

Windows Server 2008, Windows Vista, Windows Server 2003 et Windows XP : les groupes de processeurs ne sont pas pris en charge.

Au démarrage du système, le système d’exploitation crée des groupes de processeurs et attribue des processeurs logiques aux groupes. Si le système est capable d’ajouter des processeurs à chaud, le système d’exploitation autorise de l’espace dans les groupes pour les processeurs susceptibles d’arriver pendant l’exécution du système. Le système d’exploitation réduit le nombre de groupes dans un système. Par exemple, un système avec 128 processeurs logiques aurait deux groupes de processeurs avec 64 processeurs dans chaque groupe, et non quatre groupes avec 32 processeurs logiques dans chaque groupe.

Pour de meilleures performances, le système d’exploitation prend en compte la localité physique lors de l’attribution de processeurs logiques à des groupes. Tous les processeurs logiques d’un cœur et tous les cœurs d’un processeur physique sont attribués au même groupe, si possible. Les processeurs physiques qui sont physiquement proches les uns des autres sont attribués au même groupe. Un nœud NUMA est attribué à un seul groupe, sauf si la capacité du nœud dépasse la taille maximale du groupe. Pour plus d’informations, consultez Prise en charge de NUMA.

Sur les systèmes avec 64 processeurs ou moins, les applications existantes fonctionnent sans modification. Les applications qui n’appellent pas de fonctions qui utilisent des masques d’affinité processeur ou des numéros de processeur fonctionnent sur tous les systèmes, quel que soit le nombre de processeurs. Pour fonctionner sur des systèmes avec plus de 64 processeurs logiques, les types d’applications suivants peuvent nécessiter une modification :

  • Les applications qui gèrent ou affichent des informations par processeur pour l’ensemble du système doivent être modifiées pour prendre en charge plus de 64 processeurs logiques. Par exemple, une telle application est le Gestionnaire des tâches Windows, qui affiche la charge de travail de chaque processeur dans le système.
  • Les applications dont les performances sont critiques et qui peuvent être mises à l’échelle efficacement au-delà de 64 processeurs logiques doivent être modifiées pour s’exécuter sur de tels systèmes. Par exemple, les applications de base de données peuvent tirer parti de modifications.
  • Si une application utilise une DLL qui a des structures de données par processeur et que la DLL n’a pas été modifiée pour prendre en charge plus de 64 processeurs logiques, tous les threads de l’application qui appellent des fonctions exportées par la DLL doivent être attribués au même groupe.

Par défaut, une application est limitée à un seul groupe, qui doit fournir une capacité de traitement suffisante pour l’application classique. Le système d’exploitation attribue initialement chaque processus à un seul groupe en tourniquet (round robin) entre les groupes du système. Un processus commence son exécution attribuée à un groupe. Le premier thread d’un processus s’exécute initialement dans le groupe auquel le processus est attribué. Chaque thread créé est attribué au même groupe que le thread qui l’a créé.

Une application qui nécessite l’utilisation de plusieurs groupes pour s’exécuter sur plus de 64 processeurs doit déterminer explicitement où exécuter ses threads et est responsable de la définition des affinités de processeur des threads sur les groupes souhaités. Vous pouvez utiliser l’indicateur INHERIT_PARENT_AFFINITY pour spécifier un processus parent (qui peut être différent du processus actuel) à partir duquel générer l’affinité pour un nouveau processus. Si le processus s’exécute dans un seul groupe, il peut lire et modifier son affinité à l’aide de GetProcessAffinityMask et de SetProcessAffinityMask tout en restant dans le même groupe. Si l’affinité de processus est modifiée, la nouvelle affinité est appliquée à ses threads.

Vous pouvez spécifier l’affinité d’un thread lors de la création à l’aide de l’attribut étendu PROC_THREAD_ATTRIBUTE_GROUP_AFFINITY avec la fonction CreateRemoteThreadEx. Une fois le thread créé, vous pouvez modifier son affinité en appelant SetThreadAffinityMask ou SetThreadGroupAffinity. Si un thread est attribué à un groupe différent du processus, l’affinité du processus est mise à jour pour inclure l’affinité du thread et le processus devient un processus multi-groupe. D’autres modifications d’affinité doivent être apportées pour des threads individuels. Vous ne pouvez pas modifier l’affinité d’un processus multi-groupe à l’aide de SetProcessAffinityMask. La fonction GetProcessGroupAffinity récupère l’ensemble de groupes auxquels un processus et ses threads sont attribués.

Pour spécifier l’affinité pour tous les processus associés à un objet de travail, utilisez la fonction SetInformationJobObject avec la classe d’informations JobObjectGroupInformation ou JobObjectGroupInformationEx.

Un processeur logique est identifié par son numéro de groupe et son numéro de processeur relatif au groupe. Cela est représenté par une structure PROCESSOR_NUMBER. Les numéros de processeurs utilisés par les fonctions héritées sont relatifs au groupe.

Pour une discussion sur les modifications apportées à l’architecture du système d’exploitation pour prendre en charge plus de 64 processeurs, consultez le livre blanc Prendre en charge les systèmes qui ont plus de 64 processeurs.

Pour obtenir la liste des nouvelles fonctions et structures qui prennent en charge les groupes de processeurs, consultez Nouveautés des processus et threads.

Comportement à partir de Windows 11 et Windows Server 2022

Remarque

À compter de Windows 11 et Windows Server 2022, les applications ne sont plus limitées par défaut à un seul groupe de processeurs. Au lieu de cela, les processus et leurs threads ont des affinités de processeur qui s’étendent par défaut sur tous les processeurs du système, sur plusieurs groupes sur des machines avec plus de 64 processeurs.

Pour que les applications tirent automatiquement parti de tous les processeurs d’une machine avec plus de 64 processeurs, à compter de Windows 11 et Windows Server 2022, le système d’exploitation a changé pour que les processus et leurs threads s’étendent sur tous les processeurs du système, sur tous les groupes de processeurs, par défaut. Cela signifie que les applications n’ont plus besoin de définir explicitement les affinités de leurs threads pour accéder à plusieurs groupes de processeurs.

Pour des raisons de compatibilité, le système d’exploitation utilise un nouveau concept de groupe principal pour les processus et les threads. Chaque processus est attribué à un groupe principal lors de la création, et par défaut, tous les threads du groupe principal de ses threads sont identiques. Le processeur idéal de chaque thread se trouve dans le groupe principal du thread. Par conséquent, les threads seront planifiés de manière privilégiée sur les processeurs sur leur groupe principal, mais ils sont en mesure d’être planifiés sur les processeurs sur n’importe quel autre groupe. Les API d’affinité qui ne sont pas conscientes du groupe ou qui fonctionnent sur un seul groupe utilisent implicitement le groupe principal comme groupe de processeurs de processus/threads. Pour plus d’informations sur les nouveaux comportements, consultez les sections Remarques suivantes :

Les applications peuvent utiliser des jeux d’UC pour gérer efficacement l’affinité d’un processus ou d’un thread sur plusieurs groupes de processeurs.

Plusieurs processeurs

Prise en charge de NUMA