Groupes de processeurs

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 systèmes dotés de processeurs physiques qui ont plusieurs cœurs fournissent au système d’exploitation plusieurs processeurs logiques. Un processeur logique est un moteur de calcul logique 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 le même qu’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, 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 affecte des processeurs logiques aux groupes. Si le système est capable d’ajouter des processeurs à chaud, le système d’exploitation autorise l’espace dans les groupes pour les processeurs qui peuvent 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 affectés au même groupe, si possible. Les processeurs physiques qui sont physiquement proches les uns des autres sont affectés au même groupe. Un nœud NUMA est affecté à 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 correctement sans modification. Les applications qui n’appellent aucune fonction qui utilisent des masques d’affinité de processeur ou des numéros de processeur fonctionnent correctement sur tous les systèmes, quel que soit le nombre de processeurs. Pour fonctionner correctement 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, 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 Windows Gestionnaire des tâches, qui affiche la charge de travail de chaque processeur dans le système.
  • Les applications pour lesquelles 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 ces systèmes. Par exemple, les applications de base de données peuvent tirer parti des 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 affectés au même groupe.

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

Une application qui nécessite l’utilisation de plusieurs groupes afin qu’elle puisse 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. L’indicateur INHERIT_PARENT_AFFINITY peut être utilisé 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 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.

L’affinité d’un thread peut être spécifiée 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éé, son affinité peut être modifiée en appelant SetThreadAffinityMask ou SetThreadGroupAffinity. Si un thread est affecté à 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 ; L’affinité d’un processus multi-groupe ne peut pas être modifiée à l’aide de SetProcessAffinityMask. La fonction GetProcessGroupAffinity récupère l’ensemble des groupes auxquels un processus et ses threads sont affecté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 nombres de processeurs numériques utilisés par les fonctions héritées sont relatifs aux groupes.

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 Sur les systèmes de prise en charge de 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 commençant par Windows 11 et Windows Server 2022

Notes

À compter de Windows 11 et de Windows Server 2022, il n’est plus le cas où les applications sont 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, en commençant par 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 affecté à un groupe principal lors de la création, et par défaut, tous les groupes principaux 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 de leur groupe principal, mais ils sont en mesure d’être planifiés sur des processeurs sur n’importe quel autre groupe. Les API d’affinité qui ne sont pas prenant en charge les groupes ou qui fonctionnent sur un seul groupe utilisent implicitement le groupe principal comme groupe de processus/processeur de threads ; Pour plus d’informations sur les nouveaux comportements, consultez les sections Notes pour connaître les points suivants :

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