NUMA est orthogonal à multi-socket. Il y a 10 ans, on avait plusieurs processeurs par noeud NUMA sur Itanium. Maintenant c'est le contraire, les processeurs sont NUMA en interne, sans même être dans une machine multi-processeur. Par exemple, sur un bi-processeur Xeon E5v3, il peut y avoir 4 noeuds NUMA, 2 dans chaque processeur: https://pbs.twimg.com/media/Ce7r-DoWQAUlE0l.jpg:large
Les processeurs pour serveur des autres constructeurs qu'Intel suivent la même tendance.
une meilleure répartition des processus permet d'avoir plus de bande passante mémoire et donc de meilleures performances.
Ca dépend des applications... Pour les applications qui font du gros streaming mémoire, peut-être. Pour les applications qui utilisent un jeu de données relativement petit (de l'ordre de quelques megaoctets ou dizaines de mégaoctets, de nos jours), ca tient dans le cache, elles s'en fichent du débit mémoire. Et si on garde les processus proches au lieu de les répartir, le partage mémoire entre eux sera plus rapide.
C'est le genre d'info que l'ordonnanceur ignore quand il répartit les processus. D'où la nécessité de binder les tâches à la main depuis l'espace utilisateur quand on fait du HPC.
# NUMA != multi-socket
Posté par Brice Goglin . En réponse à la dépêche Sortie du noyau Linux 4.6. Évalué à 10.
NUMA est orthogonal à multi-socket. Il y a 10 ans, on avait plusieurs processeurs par noeud NUMA sur Itanium. Maintenant c'est le contraire, les processeurs sont NUMA en interne, sans même être dans une machine multi-processeur. Par exemple, sur un bi-processeur Xeon E5v3, il peut y avoir 4 noeuds NUMA, 2 dans chaque processeur:
https://pbs.twimg.com/media/Ce7r-DoWQAUlE0l.jpg:large
Les processeurs pour serveur des autres constructeurs qu'Intel suivent la même tendance.
Ca dépend des applications... Pour les applications qui font du gros streaming mémoire, peut-être. Pour les applications qui utilisent un jeu de données relativement petit (de l'ordre de quelques megaoctets ou dizaines de mégaoctets, de nos jours), ca tient dans le cache, elles s'en fichent du débit mémoire. Et si on garde les processus proches au lieu de les répartir, le partage mémoire entre eux sera plus rapide.
C'est le genre d'info que l'ordonnanceur ignore quand il répartit les processus. D'où la nécessité de binder les tâches à la main depuis l'espace utilisateur quand on fait du HPC.