Communications performantes par passage de message entre machines virtuelles sur architecture à mémoire partagée

Transcription

1 RenPar 19 / SympA 13 / CFSE 7 Toulouse, France, du 9 au 11 septembre 2009 Communications performantes par passage de message entre machines virtuelles sur architecture à mémoire partagée François Diakhaté CEA / DAM Ile De France Bruyères-le-Châtel Arpajon Cedex diakhate@ocre.cea.fr Résumé Ces dernières années, la virtualisation du matériel a connu un important regain d intérêt et s est imposée comme une technologie majeure au sein des centres de traitement de données pour consolider des serveurs, améliorer leur sécurité ou leur tolérance aux pannes. En revanche, la flexibilité offerte par les machines virtuelles n a pas encore été mise à profit au sein des grappes destinées au calcul intensif, notamment car le surcoût d exécution induit était jusqu ici jugé prohibitif. Dans cet article, nous nous intéressons au problème de l efficacité des communications entre machines virtuelles co-hébergées qui est importante pour l exécution d application parallèles de type MPI sur une grappe de machines virtuelles. Nous introduisons un périphérique virtuel de communication entre machines virtuelles permettant de tirer pleinement parti des performances de l architecture multi-cœur à mémoire partagée de la machine physique hôte. Nous avons développé une implémentation de ce périphérique pour l hyperviseur KVM ainsi que le pilote correspondant pour Linux en tant que système d exploitation invité. Une bibliothèque MPI exploitant ce périphérique nous permet d en évaluer les performances qui sont proches des meilleures implémentations MPI natives. Mots-clés : Virtualisation, KVM, MPI, Communication, Passage de message, Multi-cœur, Mémoire partagée 1. Introduction Ces dernières années, les machines virtuelles ont été très abondamment déployées au sein des centres de traitements de données pour consolider les serveurs, faciliter leur gestion ou améliorer leur sécurité. Elles n ont en revanche pas encore été adoptées dans le contexte du calcul intensif, notamment à cause de la perte de performance qu elles induisent. Les avancées récentes dans le domaine de la virtualisation sur processeur généraliste ont cependant permis de grandement améliorer leur efficacité ce qui a conduit la communauté scientifique à étudier comment les grappes de calcul pourraient tirer profit des machines virtuelles [8]. Outre le gain de flexibilité apporté par la possibilité de migrer des machines virtuelles à chaud où de laisser aux utilisateurs un contrôle total sur leur environnement logiciel, des applications spécifiques au calcul intensif sont envisageables. Par exemple, l utilisation d un hyperviseur minimal et d un système d exploitation dédié pourrait permettre de diminuer les interférences liées au système d exploitation et de grandement améliorer les performances de certaines opérations de communication [5]. Quelle que soit l utilisation envisagée, la virtualisation ne doit pas avoir d impact négatif sur les performances de la grappe de calcul. MPI étant l interface de communication la plus répandue au sein des grappes, il est essentiel de concevoir des implémentations efficaces en contexte virtualisé. S il est possible de fournir un accès efficace à certaines cartes réseau haute performance depuis une machine virtuelle, il est aussi important que les communications entre machines virtuelles co-hébergées soient optimisées [3]. En effet pour exécuter des applications MPI, il est souhaitable d utiliser des machines virtuelles mono-processeur et une tâche MPI par machine virtuelle. Cela permet d une part d effectuer un équilibrage de charge à grain plus fin par migration de machines virtuelles et d autre part d éviter

2 Tampon d émission Tampon de réception Coeur 0 en lecture en écriture Coeur 1 (a) Caches partagés 0011 Tampon partagé 0011(Dans le cache partagé) 0011 Tampon d émission Tampon de réception Coeur 0 en lecture en écriture Coeur 1 (b) Caches séparés Tampon partagé 0011(Dans le cache du coeur 0) 0011 en lecture FIG. 1: Impact du partage de cache sur l efficacité de la copie intermédiaire les surcoûts liés aux interférences entre les ordonnanceurs de l hôte et de l invité [10, 11]. Sur les architectures multi-cœur actuelles et futures, il sera donc fréquent d héberger plusieurs machines virtuelles sur un nœud de calcul. Dans cet article, nous présentons un nouveau mécanisme pour échanger efficacement des messages entre processus exécutés dans des machines virtuelles distinctes, sur architecture à mémoire partagée. L idée principale est de fournir aux machines virtuelles un périphérique dédié aux communications par passage de messages qui propose une interface à la fois simple et performante pouvant être exploitée par une bibliothèque MPI pour machine virtuelle. Cette approche s intègre facilement aux systèmes d exploitation et hyperviseurs existants tout en permettant de tirer profit des pleines performances des architectures à mémoire partagée modernes. 2. Communication par passage de message en mémoire partagée Ces dernières années, les architectures à mémoire partagée se sont progressivement complexifiées tout en s imposant comme la technologie dominante au sein des grappes de calcul. En effet, l arrivée de puces multi-cœur a grandement augmenté le nombre d unités de calcul pouvant être embarquées sur une même carte mère. L annonce par Intel d un prototype de puce contenant 80 cœurs [6], suivie de l arrivée prochaine des puces Larrabee confirme que cette tendance va s intensifier dans les années à venir. En outre, l augmentation du nombre de processeurs par carte mère s est faite au prix de l introduction d effets NUMA qui doivent être pris en compte. De ce fait, la communauté scientifique s est beaucoup intéressée aux techniques permettant de transférer efficacement des données sur ces architectures nouvelles. Dans cette section, nous commençons par passer en revue les principales techniques permettant d échanger efficacement des messages entre processus exécutés au sein d un système d exploitation traditionnel, puis nous nous intéressons aux spécificités à prendre en compte pour les appliquer dans un environnement virtualisé, c est à dire entre processus exécutés dans des machines virtuelles distinctes hébergées sur un même hôte Passage de message en mémoire partagée sur architecture multi-cœur En fonction de la taille du message à échanger, un large éventail de techniques peuvent être mises en œuvre. Néanmoins, toutes ces solutions s appuient sur deux mécanismes de base : une copie en deux étapes en passant par un tampon de communication partagé pré-alloué, ou une copie directe en place de l émetteur au récepteur. Utilisation d un tampon de communication intermédiaire Bien que les processus soient exécutés dans des espaces d adressage distincts, les systèmes d exploitations offrent généralement différents mécanismes pour leur faire partager un segment de mémoire (par ex. mmap, ou les segments de mémoire partagés system V). De nombreuses implémentations MPI exploitent ces mécanismes pour créer des tampons de communication partagés. Les transferts de données entre processus se déroulent alors entièrement en espace utilisateur en écrivant et en lisant dans ces tampons de communication. Différents protocoles ont été proposés. Une possibilité est de doter chaque processus d un tampon de réception dédie à chaque autre processus [2]. Cela permet d éviter à deux processus envoyant simultanément un message au même destinataire de se synchroniser mais cela im- 2

3 plique un coût en mémoire quadratique par rapport au nombre de processus. Par ailleurs, le temps de scrutation pour l arrivée d un nouveau message augmente linéairement avec le nombre de processus. Afin de s affranchir de ces deux inconvénients, il est aussi possible de n allouer qu un seul tampon de réception par processus et de limiter ainsi la consommation de ressources lorsque le nombre de processus augmente. La synchronisation entre écrivains concurrents est par contre plus complexe mais peut être réalisée efficacement à l aide de files de messages sans verrous [1]. L utilisation d un tampon de communication intermédiaire est particulièrement adaptée aux architectures multi-cœur disposant de caches partagés, puisque si ce tampon est suffisamment petit pour tenir dans le cache, la copie intermédiaire s effectuera en cache et aura un coût négligeable par rapport au coût de lecture et d écriture respectivement dans la mémoire de l émetteur et du récepteur. En revanche lorsque les caches ne sont pas partagés, un fraction importante de la bande passante mémoire est gaspillée par cette copie (voir Fig. 1). Pour les petits messages cette technique reste néanmoins optimale car elle n impose pas de coût particulier de démarrage ce qui permet d atteindre de très faibles latences. Lorsque la taille des messages augmente, la copie intermédiaire devient par contre pénalisante si les cœurs ne partagent pas de cache. Copie directe Afin d éviter le surcoût induit par la copie intermédiaire, il est aussi possible de réaliser une copie directe de l émetteur au récepteur de manière à obtenir une bande passante maximale pour les gros messages. Cela demande que la copie soit effectuée dans un contexte mémoire où le tampon d émission et de réception sont tous deux accessibles. Pour cela, une première approche consiste à effectuer la copie au sein du noyau du système d exploitation [7]. Cette approche requiert un module noyau dédie ce qui la rend moins portable. De plus, chaque communication est sujette au coût d un appel système ainsi qu à celui du punaisage des pages mémoire (memory pinning) ce qui restreint cette technique aux messages suffisamment gros pour que le gain de bande passante la rende rentable. Pour contourner ce problème, certaines approches emploient des threads au lieu de processus pour exécuter les tâches MPI [9]. Cela permet de fournir une implémentation portable fonctionnant uniquement en espace utilisateur mais nécessite que le code de l application parallèle soit thread-safe. Les variables globales sont par exemple proscrites Défis à relever en contexte virtualisé Il est possible d établir une analogie entre la problématique du passage de message entre machines virtuelles sur architecture à mémoire partagée et celle du passage de message entre processus natifs, vue précédemment. En effet, tout comme les processus d un système d exploitation, les machines virtuelles sont exécutées dans des espaces d adressage distincts. De ce fait, pour permettre des communications efficaces entre machines virtuelles en mémoire partagée, deux possibilités s offrent à nous : Mettre en place un ensemble de pages physiques partagées par les machines virtuelles devant communiquer, de manière à ce qu elles puissent mettre en œuvre, sans coût additionnel, les techniques utilisant un tampon de communication intermédiaire vues précédemment. Cette approche a été étudiée sur l hyperviseur Xen en tirant partie de ses capacités de partage de pages pour mettre en œuvre des communications par socket [12] ou par MPI [3] efficaces. Effectuer les copies dans un espace d adressage où à la fois les tampons d émission et de réception sont accessibles. Deux techniques peuvent être mises en œuvre. On peut accorder à l une des deux machines virtuelles un droit de lecture ou d écriture sur les pages mémoires contenant le message [4] ou laisser effectuer l opération par l hyperviseur, de la même manière que cela est fait par le noyau dans le cas natif. Dans tous les cas, cela permet de n effectuer qu une seule copie et de profiter d une bande passante maximale, mais impose des coûts de démarrage de communication importants, soit parce qu il faut modifier une table des pages pour avoir accès aux tampons d émission et de réception dans le même espace d adressage, soit parcequ il faut effectuer un hypercall. Cette technique sera donc réservée aux gros messages. Nous sommes une fois de plus en présence d un compromis entre latence et bande passante. Pour obtenir des performances optimales, il nous faut choisir la méthode la plus appropriée dynamiquement en fonction de la taille du message à transmettre. En outre l isolation entre machines virtuelles doit être prise en considération. Une machine virtuelle ne doit pas pouvoir lire ou écrire dans la mémoire d une 3

4 Espace utilisateur invité b copie c copie Espace utilisateur invité Noyau invité a projection mémoire 2 demande d émission Périphérique virtuel de communication 3 copie directe a projection mémoire 1 demande de réception Noyau invité Machine virtuelle émettrice Machine virtuelle réceptrice FIG. 2: Périphérique virtuel de communication autre machine virtuelle sans que cela lui ait été autorisé. 3. Un périphérique virtuel de communication Afin que les systèmes d exploitation invités aient accès à un moyen de communication efficace en mémoire partagée, nous introduisons un périphérique virtuel de communication disposant d une interface bas niveau bien adaptée à la sémantique des communications MPI. Les systèmes d exploitation traditionnels étant prévus pour piloter des interfaces matérielles, ils fournissent des moyens adaptés pour les exploiter efficacement et les exporter aux applications en espace utilisateur. De ce fait, pour qu un système d exploitation puisse tirer parti d un nouveau périphérique, il suffit généralement d écrire un pilote sous forme d un module noyau. De plus la plupart des hyperviseurs émulent déjà un grand nombre de périphériques et il est en général assez simple d en ajouter un nouveau. Un périphérique virtuel est donc une manière simple et portable d introduire une interface entre un hyperviseur et des systèmes d exploitation invités. Ce périphérique virtuel propose deux canaux de communication afin de rendre efficace les échanges de type MPI entre machines virtuelles co-hébergées, conformément à ce qui a été vu précédemment : un canal à faible latence basé sur des tampons partagés accessibles directement depuis l espace utilisateur des machines virtuelles et un canal à bande passante élevée pour les gros messages basé sur une copie directe. La figure 2 résume le fonctionnement du périphérique virtuel dont nous décrivons les principales caractéristiques ci-dessous. Ports Toutes les extrémités de communication sur une machine physique sont identifiées de manière unique par un numéro de port. Cela permet à plusieurs canaux de communication indépendants d être ouverts sur chaque machine virtuelle pour convenir à tous les usages. Par exemple, plusieurs processus MPI sur une même machine virtuelle pourraient vouloir utiliser le périphérique pour communiquer avec des processus MPI exécutés dans d autres machines virtuelles. L utilisation de numéros de ports au lieu d identifiants de machines virtuelles permet de traiter ces cas uniformément. Lorsqu une machine virtuelle souhaite ouvrir une extrémité de communication, elle se voit attribuer un numéro de port correspondant. Ce numéro peut ensuite être utilisé par d autres utilisateurs du périphérique virtuel pour échanger des messages avec cette nouvelle extrémité de communication. Mémoire partagée Le périphérique virtuel possède de la mémoire embarquée correspondant à un tampon de communication partagé auquel l espace utilisateur invité peut accéder directement après avoir demandé au pilote de mettre en place les projections mémoire nécessaires. Ainsi, une fois cette étape d initialisation ef- 4

5 Espace utilisateur hôte Contexte invité Basculement en contexte invité Processus en esp. utilisateur émulateur de périphériques 1 Exécute la VM Émule une E/S 4 Interruption logicielle 3 Temps d exécution normalisé Noyau Linux hôte 0 cg.a.8 bt.a.4 sp.a.4 Module KVM ft.a.8 ep.a.8 is.a.8 lu.a.8 Benchmarks parallèles mg.a.8 FIG. 3: KVM FIG. 4: Benchmarks NAS fectuée, les communications peuvent avoir lieu entièrement en espace utilisateur sans aucun surcoût. Chaque port dispose d une file de réception sans verrou au fonctionnement similaire à [1] permettant de recevoir efficacement des messages de multiples émetteurs. Transferts DMA Le périphérique virtuel peut réaliser des copies directes similaires à un transfert DMA entre les mémoires des machines virtuelles qui l utilisent. Pour cela, les machines virtuelles transmettent des requêtes d envoi et de réception au périphérique virtuel. Celles-ci admettent un port d origine et un port cible et ainsi qu un ensemble de données pouvant être non-contigües en mémoire. La copie n est effectuée qu en cas de concordance entre une requête d émission et une requête de réception. Une fois une requête émise, sa complétion peut être détectée depuis l invité en scrutant une valeur en mémoire ce qui permet d éviter un maximum de changements de contexte. Cette interface est similaire à celle des cartes réseaux haute performance qui disposent généralement à la fois de canaux de communication par copie dans une mémoire tampon mais aussi de canaux de communication par transfert direct avec rendez-vous préalable. Cette similarité devrait simplifier le portage de bibliothèques MPI sur ce périphérique virtuel. Bien que notre solution requière plus de travail de portage qu une solution assurant, par exemple, la compatibilité binaire avec l interface socket [12], elle est aussi plus efficace car elle permet de mettre en œuvre les même techniques de communication qu en environnement non-virtualisé. 4. Implémentation Afin d évaluer ce périphérique virtuel, nous l avons implémenté au sein de l hyperviseur KVM, puis nous avons développé un pilote pour Linux en tant que système d exploitation invité ainsi qu une bibliothèque MPI réduite permettant d exécuter des benchmarks parallèles standards Emulation depuis l hôte KVM est un module noyau permettant à Linux de jouer le rôle d hyperviseur grâce au support matériel de la virtualisation disponible dans les processeurs récents. Avec KVM, les machines virtuelles sont des processus Linux standards et peuvent ainsi être administrées simplement. Outre ce module noyau, un composant en espace utilisateur est nécessaire pour effectuer différentes tâches d initialisation, comme l allocation de la mémoire des machines virtuelles à l aide des fonctions d allocation standard du système. Par la suite, il est chargé d émuler les périphériques virtuels : lorsque qu un système d exploitation invité tente d accéder à un périphérique virtuel, l instruction correspondante est interceptée par KVM qui la transmet au composant en espace utilisateur pour qu il émule le résultat attendu (voir Fig. 3). 5

6 Bande passante (MiB/s) Latence (us) Ki 512Ki 4Mi Taille du message (octets) Taille du message (octets) (a) Bande passante (b) Latence FIG. 5: Ping-pong : cœurs partageant un cache De ce fait, notre périphérique virtuel peut être émulé entièrement en espace utilisateur hôte. Afin qu un processus exécutant une machine virtuelle puisse accéder à la mémoire des autres machines virtuelles, nous effectuons l allocation de la mémoire des machines depuis une zone mémoire partagée entre les processus. Lorsque le système d exploitation invité émet une requête DMA sur le périphérique virtuel, une interruption logicielle est déclenchée ce qui permet au processus hôte de prendre en compte la requête en la plaçant dans une file. Cette file de requêtes est elle aussi située dans la zone mémoire partagée entre les processus éxécutant les machines virtuelles. Lorsqu une requête d émission concorde avec une requête de réception le processus ayant posté la deuxième requête effectue une copie directe entre les mémoires des machines virtuelles. L accès aux données d une autre machine virtuelle est ainsi entièrement effectué par le processus hôte qui peut vérifier la validité des requêtes émises Accès au périphérique virtuel depuis l invité Du côté de l invité, un pilote noyau est en charge d accéder au périphérique virtuel. L interface d accès au périphérique utilise l interface standard de virtualisation Virtio ce qui simplifie l écriture de pilotes pour différents systèmes d exploitation invités. Cette interface permet de transmettre à l hôte des couples pointeur/taille grâce à des files et est donc bien adaptée à l envoi de nos requêtes DMA. Le pilote relaie l interface du périphérique virtuel vers les applications en espace utilisateur à travers les interfaces standards du sytème d exploitation. L interface de notre pilote pour Linux requiert l utilisation de l appel système ioctl pour ouvrir ou fermer un port sur la carte ainsi que pour émettre des requêtes DMA. Les files de messages de la carte peuvent quant à elles être projetées en espace utilisateur à l aide de l appel système mmap. Une bibliothèque de test disposant des principales primitives de communication point-à-point (Send, Recv, Isend, Irecv, Wait,... ) et collectives (Reduce, Scatter, Gather, Bcast, Barrier,... ) de la norme MPI, baptisée VMPI, a été implémentée à partir de cette interface. Elle utilise les files de messages du périphérique pour les petits messages et des requêtes DMA précédées d un rendez-vous pour les messages de taille supérieure à 32KiB. 5. Résultats Dans cette section, nous évaluons les performances de notre solution en comparant, pour différents benchmarks MPI, les performances obtenues lorsque les tâches MPI sont exécutées dans des machines virtuelles séparées, en utilisant VMPI et notre périphérique virtuel pour communiquer, à celles obtenues lorsque les tâches MPI sont exécutées directement sur l hôte, en utilisant les implémentations MPI standard MPICH2 1.1 et Open MPI Nous mesurons tout d abord les performances brutes de latence et de bande passante à l aide du test ping-pong de la suite Intel MPI Benchmarks puis nous évaluons leur 6

7 Bande passante (MiB/s) Latence (us) Ki 512Ki 4Mi Taille du message (octets) Taille du message (octets) (a) Bande passante (b) Latence FIG. 6: Ping-pong : cœurs situés sur des puces séparées impact sur l efficacité d applications scientifiques parallèles grâce à la suite NAS Parallel Benchmarks. La machine utilisée pour ces tests contient deux processeurs Xeon quadri-cœurs E5345 (2.33Ghz) et 4GiB de mémoire vive. Ping-pong Pour ce test on distingue le cas où les 2 processus effectuant le ping-pong sont exécutés sur deux cœurs partageant un cache, et celui où les processus sont exécutés sur des puces différentes. Pour que ce test soit plus représentatif des conditions réelles de communication, le paramètre off_cache est utilisé afin de varier les données utilisées pour chaque passage de message. Dans le cas contraire, les données restent toujours dans les caches des processeurs puisqu elles ne sont jamais modifiées et les bandes passantes atteintes (jusqu à 6 GiB/s en cas de copie directe) ne sont pas représentatives des conditions normales d utilisation. Les résultats sont présentés sur les figures 5 et 6. En terme de latence, VMPI obtient des performances similaires aux meilleures implémentations natives, à l exception des très petit messages en cache partagé où le protocole Nemesis utilisé par MPICH2 obtient une latence inférieure d environ 200 ns. Cet écart de performance s explique probablement par le fait que Nemesis a été optimisé pour minimiser le nombre d instructions sur le chemin critique et utilise par ailleurs, en plus des files de messages, des boites de réception rapides qui sont allouées pour chaque paire de processus et qui permettent de recevoir très rapidement un unique message. En ce qui concerne le débit, notre périphérique virtuel offre un avantage à VMPI pour les gros messages, car il permet d effectuer des copies directes, ce que ne peuvent faire les bibliothèques MPI usuelles qui sont implémentées en espace utilisateur. Ainsi, en comparaison aux implémentations usuelles, la bande passante est presque doublée lorsque les processus sont exécutés sur des cœurs ne partageant pas de cache, conformément à ce qui a été vu dans la section 2. NAS Parallel Benchmarks La figure 4 montre les résultats obtenus pour la classe A des tests NAS exécutés sur les 8 cœurs de la machine de test, sauf BT et SP qui ne peuvent être exécutés que sur un nombre carré de cœurs. On constate que pour tous les tests mis à part IS, l écart de performance entre l exécution virtualisée, et l exécution native est inférieure à 10%. En revanche pour IS, la version virtualisée est environ 20% plus rapide. Ceci s explique par le fait que IS est le test utilisant la plus grosse proportion de gros messages que notre périphérique virtuel permet de transférer très efficacement. 6. Conclusion Dans cet article, nous avons présenté un périphérique virtuel permettant de communiquer efficacement par passage de messages entre machines virtuelles partageant le même hôte. Cette solution devrait être 7

8 portable sur la majorité des systèmes d exploitation et hyperviseurs et offre de bonnes performances comme le montre nos évaluations. Ce travail illustre en outre le potentiel de la virtualisation comme source de gains de performances. Celle-ci permet en effet d intégrer des optimisations dans le noyau du système d exploitation de l invité plutôt que dans celui de l hôte ce qui permet de s affranchir de certaines contraintes de sécurité et offre de manière générale plus de flexibilité. Nous en tirons parti ici pour effectuer des copies directes de type DMA entre émetteur et récepteur, ce qui nous permet dans certains cas de doubler la bande passante disponible par rapport à une implémentation MPI en espace utilisateur. Par la suite, nous comptons intégrer un support pour notre périphérique virtuel au sein d une bibliothèque MPI existante telle que MPICH2 ou Open MPI et supporter ainsi l interface MPI complète. Nous souhaitons en outre étendre l interface de notre périphérique afin de proposer notamment un support de la migration de machines virtuelles. Cela suppose d intégrer un mécanisme de rappels pour que les applications puissent suspendre et rétablir les communications lorsqu une machine virtuelle est migrée. Par ailleurs, nous pensons étudier des politiques spécialisées d ordonnancement dynamique de machines virtuelles tenant compte des communications, afin de rendre efficace l exécution d un nombre de machines virtuelles supérieur au nombre de cœurs disponibles. References [1] D. Buntinas, G. Mercier, and W. Gropp. Implementation and Shared-Memory Evaluation of MPICH2 over the Nemesis Communication Subsystem. In Proceedings of the 13th European PVM/MPI Users Group Meeting, [2] L. Chai, A. Hartono, and D. K. Panda. Designing high performance and scalable mpi intra-node communication support for clusters. In Proceedings of the 2006 IEEE International Conference on Cluster Computing, [3] W. Huang, M. Koop, Q. Gao, and D. K. Panda. Virtual Machine Aware Communication Libraries for High Performance Computing. In Proceedings of the 2007 ACM/IEEE conference on Supercomputing, [4] W. Huang, M. Koop, and D. Panda. Efficient one-copy mpi shared memory communication in virtual machines. In Proceedings of the 2008 IEEE International Conference on Cluster Computing, [5] T. Hudson and R. Brightwell. Network performance impact of a lightweight linux for cray xt3 compute nodes. In Proceedings of the 2006 ACM/IEEE conference on Supercomputing, [6] Intel. Intel research advances era of tera. Intel News Release: [7] H.-W. Jin and D. K. Panda. Limic: Support for high-performance mpi intra-node communication on linux cluster. In Proceedings of the 2005 International Conference on Parallel Processing, [8] M. F. Mergen, V. Uhlig, O. Krieger, and J. Xenidis. Virtualization for high-performance computing. SIGOPS Operating Systems Review, 40(2), [9] M. Pérache, H. Jourdren, and R. Namyst. MPC: A Unified Parallel Runtime for Clusters of NUMA Machines. In Proceedings of the 14th International Euro-Par Conference, [10] A. Ranadive, M. Kesavan, A. Gavrilovska, and K. Schwan. Performance implications of virtualizing multicore cluster machines. In 2nd Workshop on System-level Virtualization for High Performance Computing, [11] V. Uhlig, J. LeVasseur, E. Skoglund, and U. Dannowski. Towards scalable multiprocessor virtual machines. In Proceedings of the 3rd Virtual Machine Research and Technology Symposium, [12] X. Zhang, S. McIntosh, P. Rohatgi, and J. L. Griffin. Xensocket: A high-throughput interdomain transport for virtual machines. In Proceedings of the 8th ACM/IFIP/USENIX International Middleware Conference,