Comment les applications seront-elles planifiées sur des machines multi-core activées par l'hyper-threading?

Question

J'essaie de mieux comprendre comment fonctionnent les processeurs multi-core compatibles avec le threading. Disons que j'ai une application qui peut être compilée avec MPI ou OpenMP ou MPI + OpenMP. Je me demande comment il sera programmé sur une boîte CentOS 5.3 avec quatre processeurs Xeon X7560 @ 2.27GHz et chaque cœur de processeur a Hyper-Threading activé.

Le processeur est numéroté de 0 à 63 dans/proc/cpuinfo. Pour ma compréhension, il y a quatre 8 noyaux processeurs physiques, les CŒURS totaux physiques sont 32, chaque cœur de processeur a Hyper-Threading activé, les processeurs totaux LOGIQUES sont 64.

1. Compilé avec MPICH2 Combien de physique les cœurs seront utilisés si je cours avec mpirun -np 16? Est-il divisé entre les 16 cœurs PHYSIQUES ou les 16 processeurs logiques disponibles (8 cœurs PHYSIQUES utilisant l'hyper-threading)?

2. compilé avec OpenMP Combien de cœurs physiques seront utilisés si je mets OMP_NUM_THREADS = 16? Est-ce qu'il utilisera 16 processeurs LOGICAL?

3. Compilé avec MPICH2 + OpenMP Combien de cœurs physiques seront utilisés si je mets OMP_NUM_THREADS = 16 et que je cours avec mpirun -np 16?

4. compilé avec OpenMPI

OpenMPI dispose de deux options d'exécution

-CPU-ensemble qui spécifie les processeurs logiques alloués à l'emploi, -CPU-per-proc qui spécifie le numéro du processeur à utiliser pour chaque processus.

S'il est exécuté avec mpirun -np 16 -cpu-set 0-15, n'utilisera-t-il que 8 cœurs PHYSIQUES?
Si elle est exécutée avec mpirun -np 16 -cpu-set 0-31 -cpu-per-proc 2, comment sera-t-elle planifiée?

Merci

Jerry

Answer 1

Je hasarder une hypothèse que le planificateur va essayer de garder les discussions en un seul processus sur les mêmes noyaux physiques. Donc, si vous aviez seize threads, ils seraient sur le plus petit nombre de cœurs physiques. La raison de ceci serait la localité de cache; il serait considéré que les threads du même processus seraient plus susceptibles de toucher la même mémoire que les threads provenant de différents processus. (Par exemple, les coûts de l'invalidation de la ligne de cache entre les cœurs sont élevés, mais ce coût ne se produit pas pour les processeurs logiques dans le même cœur).

Answer 2

Je m'attendrais à ce que n'importe quel planificateur sensible préfère si possible exécuter des threads sur différents processeurs physiques. Ensuite, je m'attendrais à ce qu'il préfère différents cœurs physiques. Enfin, s'il le faut, il commencera à utiliser le second thread hyperthreadé sur chaque noyau physique.

Fondamentalement, lorsque les threads doivent partager les ressources du processeur, ils ralentissent. La stratégie optimale consiste donc généralement à minimiser la quantité de partage de ressources processeur. C'est la bonne stratégie pour les processus liés au CPU et c'est normalement ce qu'un système d'exploitation suppose qu'il traite.

Answer 3

Comme vous pouvez le voir dans les deux autres réponses, la politique d'ordonnancement idéale varie en fonction de l'activité des threads.

Les threads travaillant sur des données complètement différentes bénéficient d'une plus grande séparation. Ces threads seraient idéalement programmés dans des domaines NUMA séparés et des cœurs physiques.

Les threads travaillant sur les mêmes données bénéficieront de la localisation de la mémoire cache, de sorte que la stratégie de l'idée consiste à les programmer étroitement afin qu'ils partagent le cache. Les threads qui travaillent sur les mêmes données et rencontrent une grande quantité d'incidents de pipeline bénéficient du partage d'un cœur hyperthread. Chaque thread peut fonctionner jusqu'à ce qu'il se bloque, à quel point l'autre thread peut s'exécuter. Les threads qui s'exécutent sans décrochage ne sont blessés que par hyperthreading et doivent être exécutés sur des noyaux différents. Faire la décision de planification idéale repose sur beaucoup de collecte de données et beaucoup de prise de décision. Un grand danger dans la conception de l'OS est de rendre la planification des threads trop intelligente. Si le système d'exploitation passe beaucoup de temps à essayer de trouver l'emplacement idéal pour exécuter un thread, il perdra du temps à utiliser le thread.

Il est souvent plus efficace d'utiliser un planificateur de threads simplifié et, si nécessaire, de laisser le programme spécifier sa propre politique. C'est le paramètre d'affinité du fil.