Un problème majeur de la virtualisation est la fidélisation de la virtualisation de la topologie NUMA (Non Uniform Memory Access), permettant une utilisation efficace de la RAM.
La moindre machine bi-processeur à base d'i7 est NUMA (un banc mémoire par socket), et les AMD Opteron à 8 coeurs ou plus (Magny-Cours, Bulldozer ...) peuvent avoir 2 noeuds NUMA dans le même chip! Au boulot je travaille sur une machine Magny-cours à 4 sockets, et chaque proc est un Magny-cours à 12 coeurs (2 noeuds NUMA à 6 coeurs). Donc on a 8 noeuds NUMA sur la même machine, avec une topologie proche d'une arborescence. Les accès RAM entre 2 noeuds du même chip sont plus rapides qu'entre 2 noeuds sur des chips différents, par exemple.
On peut utiliser efficacement cette topologie en programmation multi-thread, grâce à des librairies comme Hardware Locality. Cela permet d'affecter des threads à des coeurs, d'allouer de la mémoire sur des noeuds NUMA choisis, etc, à partir d'informations très précises sur la topologie processeur et mémoire de la machine.
Tentative de virtualisation avec Xen : on se retrouve avec une topologie complètement plate, chaque coeur est vu comme un CPU indépendant des autres. Aucune info disponible non plus sur la taille des caches, sur quels procs partagent quels caches L3, etc. Résultat, les applis n'ont aucune info pour utiliser la RAM efficacement. D’ailleurs je pense que c'est la raison pour laquelle tu as une variation importante de tes résultats sur Xen. Tu peux tomber sur des cas où par chance, les accès mémoire se font de manière efficace, et d'autres non.
Sans parler de NUMA, un autre problème de Xen sur une machine qui fait de l'hyperthreading comme sur i7, tu n'as aucun moyen de savoir si 2 threads tournent sur 2 coeurs différents ou sur le même, chacun sur un thread hardware, car le noyau Linux n'a pas l'information. Si tes threads se retrouvent à tourner sur le même coeur, c'est foutu.
J'en suis arrivé à installer une Debian squeeze avec un noyau Vserver, ce qui me permet de travailler sur serveur invité en testing, avec une parfaite information sur la topologie NUMA, pour des perfs très proches d'un OS natif.
# NUMA et accès RAM
Posté par zerkman . En réponse au journal Comparaison des performances de machines virtuelles. Évalué à 10.
Un problème majeur de la virtualisation est la fidélisation de la virtualisation de la topologie NUMA (Non Uniform Memory Access), permettant une utilisation efficace de la RAM.
La moindre machine bi-processeur à base d'i7 est NUMA (un banc mémoire par socket), et les AMD Opteron à 8 coeurs ou plus (Magny-Cours, Bulldozer ...) peuvent avoir 2 noeuds NUMA dans le même chip! Au boulot je travaille sur une machine Magny-cours à 4 sockets, et chaque proc est un Magny-cours à 12 coeurs (2 noeuds NUMA à 6 coeurs). Donc on a 8 noeuds NUMA sur la même machine, avec une topologie proche d'une arborescence. Les accès RAM entre 2 noeuds du même chip sont plus rapides qu'entre 2 noeuds sur des chips différents, par exemple.
On peut utiliser efficacement cette topologie en programmation multi-thread, grâce à des librairies comme Hardware Locality. Cela permet d'affecter des threads à des coeurs, d'allouer de la mémoire sur des noeuds NUMA choisis, etc, à partir d'informations très précises sur la topologie processeur et mémoire de la machine.
Tentative de virtualisation avec Xen : on se retrouve avec une topologie complètement plate, chaque coeur est vu comme un CPU indépendant des autres. Aucune info disponible non plus sur la taille des caches, sur quels procs partagent quels caches L3, etc. Résultat, les applis n'ont aucune info pour utiliser la RAM efficacement. D’ailleurs je pense que c'est la raison pour laquelle tu as une variation importante de tes résultats sur Xen. Tu peux tomber sur des cas où par chance, les accès mémoire se font de manière efficace, et d'autres non.
Sans parler de NUMA, un autre problème de Xen sur une machine qui fait de l'hyperthreading comme sur i7, tu n'as aucun moyen de savoir si 2 threads tournent sur 2 coeurs différents ou sur le même, chacun sur un thread hardware, car le noyau Linux n'a pas l'information. Si tes threads se retrouvent à tourner sur le même coeur, c'est foutu.
J'en suis arrivé à installer une Debian squeeze avec un noyau Vserver, ce qui me permet de travailler sur serveur invité en testing, avec une parfaite information sur la topologie NUMA, pour des perfs très proches d'un OS natif.