Osis18_Cloud : Virtualisation efficace d’architectures NUMA
0 j'aime•210 vues
Le document se concentre sur l’efficacité de la virtualisation dans les architectures NUMA pour le cloud computing, mettant en évidence que les technologies actuelles n'exploitent pas pleinement la puissance des machines modernes. Il aborde les problèmes de latence mémoire et propose une approche de coopération entre hyperviseurs et systèmes invités pour optimiser le placement des données. Plusieurs stratégies de gestion de mémoire sont également évaluées pour améliorer la performance.
![Rendre le cloud computing efficace
• Le cloud computing : effectuer des calculs sur les machines d’un tiers
1990 2000 2010 2020
[Disco’97]
[Xen’03]
aujourd’hui
Pentium II
AMD K10
15 ans
Puissance
de calcul
• Le cloud computing repose sur des technologies vieilles de 15 ans
• La puissance des machines a augmenté
Gauthier Voron Virtualisation efficace d’architectures NUMA 2 / 32](https://image.slidesharecdn.com/osis-2018-gauthier-voron-180613161901/85/Osis18_Cloud-Virtualisation-efficace-d-architectures-NUMA-2-320.jpg)
Osis18_Cloud : Virtualisation efficace d’architectures NUMA
- 1. Virtualisation efficace d’architectures NUMA The Open Source Innovation Spring 2018 Gauthier Voron Sorbonne Université Gaël Thomas Télécom SudParis Vivien Quéma Grenoble INP / ENSIMAG Pierre Sens Sorbonne Université
- 2. Rendre le cloud computing efficace • Le cloud computing : effectuer des calculs sur les machines d’un tiers 1990 2000 2010 2020 [Disco’97] [Xen’03] aujourd’hui Pentium II AMD K10 15 ans Puissance de calcul • Le cloud computing repose sur des technologies vieilles de 15 ans • La puissance des machines a augmenté Gauthier Voron Virtualisation efficace d’architectures NUMA 2 / 32
- 3. Surcoût du cloud computing aujourd’hui 0 1 2 3 4 5 6 7 8 9 10 cg.C ft.C lu.C ua.C psearchy SurcoûtXen Machine 8 coeurs Machine 48 coeurs • Les technologies du cloud n’arrivent pas à exploiter la puissance des machines modernes Gauthier Voron Virtualisation efficace d’architectures NUMA 3 / 32
- 4. Plan 1 Contexte et concepts généraux Contexte : le cloud computing Premier concept : les technologies du cloud Second concept : les machines modernes 2 Problématique et approches existantes 3 Contribution et évaluation des résultats Gauthier Voron Virtualisation efficace d’architectures NUMA 4 / 32
- 5. Cloud computing : exécution de jobs en série • Cloud computing : modèle de gestion de ressources • Un fournisseur de ressources → des serveurs (CPU + mémoire + disque) • Plusieurs consommateurs de ressources fournisseur serveur 1 serveur 2 serveur 3 . . . job 1 job 3 . . . job 2 job 4 . . . job 1 job 2 . . . job 1 job 2 . . . job N client A job 1 job 2 . . . job N client B • Les consommateurs veulent exécuter des jobs Gauthier Voron Virtualisation efficace d’architectures NUMA 5 / 32
- 6. Cloud computing : exécution de jobs en série • Cloud computing : modèle de gestion de ressources • Un fournisseur de ressources → des serveurs (CPU + mémoire + disque) • Plusieurs consommateurs de ressources fournisseur serveur 1 serveur 2 serveur 3 . . . job 1 job 3 . . . job 2 job 4 . . . job 1 job 2 . . . job 1 job 2 . . . job N client A job 1 job 2 . . . job N client B • Les consommateurs veulent exécuter des jobs • Un consommateur peut louer des serveurs pour exécuter ses jobs • Un consommateur veut exécuter ses jobs rapidement Gauthier Voron Virtualisation efficace d’architectures NUMA 5 / 32
- 7. Cloud computing : allocation de ressources à la demande • Chaque consommateur a des besoins différents • Nombre de cœurs pour un job • Quantité de mémoire pour un job • Le fournisseur doit pouvoir satisfaire toutes ces demandes fournisseur client A client B job 1 48 threads job 2 24 threads job 3 12 threads job 2job 1 Gauthier Voron Virtualisation efficace d’architectures NUMA 6 / 32
- 8. Cloud computing : allocation de ressources à la demande • Chaque consommateur a des besoins différents • Nombre de cœurs pour un job • Quantité de mémoire pour un job • Le fournisseur doit pouvoir satisfaire toutes ces demandes fournisseur client A client B serveur 1 serveur 2 serveur 3 . . . job 1 48 cœurs job 2job 1job 2 48 cœurs job 3 48 cœurs • Le fournisseur dispose de puissantes machines multicœurs • Ce qu’un consommateur peut demander de mieux pour un job • Le fournisseur fragmente ses serveurs grâce à la virtualisation • La virtualisation est assurée par l’hyperviseur Gauthier Voron Virtualisation efficace d’architectures NUMA 6 / 32
- 9. Objectifs de l’hyperviseur : isolation et performance • Hyperviseur : couche logicielle intercalée entre le système d’exploitation et le matériel Matériel Hyperviseur Système d’exploitation A Job A-1 Système d’exploitation B Job B-7 Système hôte Système invité • Rôles de l’hyperviseur : • Isoler les systèmes invités les uns des autres • Isoler les systèmes invités du matériel • Permettre aux systèmes invités de s’exécuter rapidement Gauthier Voron Virtualisation efficace d’architectures NUMA 7 / 32
- 10. Plan 1 Contexte et concepts généraux Contexte : le cloud computing Premier concept : la virtualisation système Second concept : les machines multicœur 2 Problématique et approches existantes 3 Contribution et évaluation des résultats Gauthier Voron Virtualisation efficace d’architectures NUMA 8 / 32
- 11. Le défi des machines multicœur : l’accès à la mémoire • Les cœurs travaillent sur des données en mémoire • Tous les cœurs accèdent à la mémoire par un unique contrôleur RAM RAM RAM RAM RAM c c c c c c c c c c c c RAM RAM RAM RAM c c c c c c c c c c c c Gauthier Voron Virtualisation efficace d’architectures NUMA 9 / 32
- 12. Le défi des machines multicœur : l’accès à la mémoire • Les cœurs travaillent sur des données en mémoire • Tous les cœurs accèdent à la mémoire par un unique contrôleur • Trop de cœurs ⇒ trop d’accès concurrents ⇒ congestion mémoire RAM RAM RAM RAM RAM c c c c c c c c c c c c RAM RAM RAM RAM c c c c c c c c c c c c Gauthier Voron Virtualisation efficace d’architectures NUMA 9 / 32
- 13. Le défi des machines multicœur : l’accès à la mémoire • Les cœurs travaillent sur des données en mémoire • Tous les cœurs accèdent à la mémoire par un unique contrôleur • Trop de cœurs ⇒ trop d’accès concurrents ⇒ congestion mémoire RAM RAM RAM RAM c c c c c c c c c c c c RAM RAM RAM RAM c c c c c c c c c c c c • Solution : distribuer la charge mémoire sur plusieurs contrôleurs • Utilisation de plusieurs bancs mémoire indépendants Gauthier Voron Virtualisation efficace d’architectures NUMA 9 / 32
- 14. Architecture NUMA : problème du placement des données • Un multicœur NUMA est composé d’un ensemble de nœud NUMA • Chaque nœud est composé de cœurs et d’un contrôleur mémoire • Les nœuds sont reliés entre eux par l’interconnect • Le matériel route chaque requêtes mémoire vers le bon nœud RAM RAM RAM RAM c c c c c c c c c c c c nœud nœud nœud nœud interconnect RAM RAM RAM RAM c c c c c c c c c c c c • Fonctionellement équivalent à un multicœur classique • Exécution possible de programmes legacy • Besoin de traitements spécifiques pour être performant Gauthier Voron Virtualisation efficace d’architectures NUMA 10 / 32
- 15. Architecture NUMA : problème du placement des données • Un multicœur NUMA est composé d’un ensemble de nœud NUMA • Chaque nœud est composé de cœurs et d’un contrôleur mémoire • Les nœuds sont reliés entre eux par l’interconnect • Le matériel route chaque requêtes mémoire vers le bon nœud RAM RAM RAM RAM c c c c c c c c c c c c RAM RAM RAM RAM c c c c c c c c c c c c 100 cycles 300 cycles • La latence mémoire dépend de :du placement des tâches / données • La localité des accès → local : 100 cycles / distant : 300 cycles Gauthier Voron Virtualisation efficace d’architectures NUMA 10 / 32
- 16. Architecture NUMA : problème du placement des données • Un multicœur NUMA est composé d’un ensemble de nœud NUMA • Chaque nœud est composé de cœurs et d’un contrôleur mémoire • Les nœuds sont reliés entre eux par l’interconnect • Le matériel route chaque requêtes mémoire vers le bon nœud RAM RAM RAM RAM c c c c c c c c c c c c RAM RAM RAM RAM c c c c c c c c c c c c 700 cycles • La latence mémoire dépend de :du placement des tâches / données • La localité des accès → local : 100 cycles / distant : 300 cycles • L’absence de congestion des contrôleurs → 700 cycles Gauthier Voron Virtualisation efficace d’architectures NUMA 10 / 32
- 17. Architecture NUMA : problème du placement des données • Un multicœur NUMA est composé d’un ensemble de nœud NUMA • Chaque nœud est composé de cœurs et d’un contrôleur mémoire • Les nœuds sont reliés entre eux par l’interconnect • Le matériel route chaque requêtes mémoire vers le bon nœud RAM RAM RAM RAM c c c c c c c c c c c c RAM RAM RAM RAM c c c c c c c c c c c c 500 cycles • La latence mémoire dépend de :du placement des tâches / données • La localité des accès → local : 100 cycles / distant : 300 cycles • L’absence de congestion des contrôleurs → 700 cycles • L’absence de congestion de l’interconnect → 500 cycles Gauthier Voron Virtualisation efficace d’architectures NUMA 10 / 32
- 18. Architecture NUMA : problème du placement des données • Un multicœur NUMA est composé d’un ensemble de nœud NUMA • Chaque nœud est composé de cœurs et d’un contrôleur mémoire • Les nœuds sont reliés entre eux par l’interconnect • Le matériel route chaque requêtes mémoire vers le bon nœud RAM RAM RAM RAM c c c c c c c c c c c c RAM RAM RAM RAM c c c c c c c c c c c c • La latence mémoire dépend du placement des tâches / données • Peu d’applications savent gérer finement ce paramètre • Le système d’exploitation propose différentes politiques de placement Gauthier Voron Virtualisation efficace d’architectures NUMA 10 / 32
- 19. Besoin de multiples politiques mémoire 0 0.5 1 1.5 2 2.5 3 3.5 bt.C cg.C sp.C pca Accélération/Politique1 Politique 1 Politique 2 + Politique 1 Politique 3 Politique 2 + Politique 3 • Il n’y a pas aujourd’hui une politique meilleure que toutes les autres • La politique doit être sélectionnée en fonction de l’application • Par l’application elle-même (set_mempolicy()) • Par l’utilisateur (numactl) • Le système d’exploitation doit laisser le choix à l’utilisateur entre différentes politiques mémoire Gauthier Voron Virtualisation efficace d’architectures NUMA 11 / 32
- 20. Plan 1 Contexte et concepts généraux Contexte : le cloud computing Premier concept : la virtualisation système Second concept : les architectures NUMA 2 Problématique et approches existantes L’inefficacité des machines virtuelles NUMA Détails sur la virtualisation d’architectures NUMA Approches existantes 3 Contribution et évaluation des résultats Gauthier Voron Virtualisation efficace d’architectures NUMA 12 / 32
- 21. L’inefficacité des machines virtuelles NUMA • La virtualisation est peu performante sur des architectures NUMA • Les architectures NUMA causent des problèmes de latence mémoire • Latence mémoire d’un système invité sur une machine NUMA : 0 200 400 600 800 1000 1200 1400 1600 1800 2000 cg.C ft.C lu.C ua.C psearchy Latencemémoire (cyclesparaccès) Linux Xen • Hypothèse : la virtualisation affecte les politiques mémoire Gauthier Voron Virtualisation efficace d’architectures NUMA 13 / 32
- 22. Placement NUMA des données en mode natif • Un système travaille avec deux espaces d’adressages • L’espace d’adressage virtuel • L’espace d’adressage physique espace virtuel espace physique Gauthier Voron Virtualisation efficace d’architectures NUMA 14 / 32
- 23. Placement NUMA des données en mode natif • Un système travaille avec deux espaces d’adressages • L’espace d’adressage virtuel • L’espace d’adressage physique espace virtuel espace physique nœud 0 nœud 1 nœud 2 nœud 3 0 Gio → 2 Gio 2 Gio → 4 Gio 4 Gio → 6 Gio 6 Gio → 8 Gio • Les nœuds NUMA sont une partition de l’espace physique • Le matériel route les requêtes mémoire en fonction de l’adresse physique Gauthier Voron Virtualisation efficace d’architectures NUMA 14 / 32
- 24. Placement NUMA des données en mode natif • Un système travaille avec deux espaces d’adressages • L’espace d’adressage virtuel • L’espace d’adressage physique espace virtuel espace physique nœud 0 nœud 1 nœud 2 nœud 3 table des pages • Les nœuds NUMA sont une partition de l’espace physique • Le matériel route les requêtes mémoire en fonction de l’adresse physique • Le système d’exploitation utilise la traduction d’adresses pour choisir le placement NUMA des données Gauthier Voron Virtualisation efficace d’architectures NUMA 14 / 32
- 25. Placement NUMA à plusieurs systèmes : collisions d’adresse • Un système invité croit s’exécuter seul sur une machine espace virtuel espace virtuel espace physique job A-3 job B-7 table des pages système A table des pages système B • Plusieurs invités peuvent utiliser les mêmes adresses physiques • L’hyperviseur doit éviter les collisions d’adresses physiques Gauthier Voron Virtualisation efficace d’architectures NUMA 15 / 32
- 26. Placement NUMA des données en mode virtualisé espace virtuel espace physique espace machine job A-3 système A nœud 0 nœud 1 nœud 2 nœud 3 table des pages invité contrôlée par système A table des pages hôte contrôlée par hyperviseur • Les processeurs modernes effectuent deux traductions d’adresses • La première traduction est contrôlée exclusivement par le système invité • La seconde traduction est contrôlée exclusivement par l’hyperviseur • Le placement des données est déterminé conjointement par le système invité et l’hyperviseur Gauthier Voron Virtualisation efficace d’architectures NUMA 16 / 32
- 27. Deux approches existantes face au problème du placement • Le problème du placement NUMA virtualisé est connu • Deux approches déjà utilisées : • L’hyperviseur décide seul car c’est le plus privilégié • Systèmes invités vus comme des boîtes noires • Impossible de choisir une politique de placement adaptée • L’invité décide seul car c’est le plus proche de l’application • Pas de vision globale de la machine • Impossible de prendre en compte les accès mémoires des autres invités Gauthier Voron Virtualisation efficace d’architectures NUMA 17 / 32
- 28. Nouvelle approche : coopération pour la gestion NUMA Prise en compte des besoins de l’application Prise en compte des contraintes globales L’hyperviseur décide du placement non oui Les invités décident du placement oui non Nouvelle approche L’hyperviseur décide les invités indiquent leurs besoins oui oui • Centraliser la gestion NUMA dans l’hyperviseur • Prise en compte des contraintes globales • Permettre au système invité d’indiquer les besoins de l’application • Prise en compte des besoins de l’application Gauthier Voron Virtualisation efficace d’architectures NUMA 18 / 32
- 29. Nouvelle approche : architecture Matériel Application paravirt. politiques NUMA Linux Xen NUMA besoins besoins application ordres besoins système • On met en œuvre trois politiques NUMA dans l’hyperviseur Xen • Ces politiques observent le système invité comme une boîte noire • Le système invité transmet les besoins de l’applications à l’hyperviseur saturation contrôleurs saturation interconnect localité d’accès Round-4k First-touch Carrefour Gauthier Voron Virtualisation efficace d’architectures NUMA 19 / 32
- 30. Plan 1 Contexte et concepts généraux Contexte : le cloud computing Premier concept : la virtualisation système Second concept : les architectures NUMA 2 Problématique et approches existantes La latence mémoire des machines virtuelles NUMA Détails sur la virtualisation d’architectures NUMA Approches existantes 3 Contribution et évaluation des résultats Première stratégie : Round-4k Deuxième stratégie : First-touch Troisième stratégie : Carrefour Évaluation des stratégies Gauthier Voron Virtualisation efficace d’architectures NUMA 20 / 32
- 31. Round-4k : éviter la congestion mémoire d’un nœud • Facteur de performance : la saturation des contrôleurs mémoire • Stratégie round-4k : répartir l’espace virtuel sur les différents nœuds nœud espace virtuel espace physique . . . 4 Kio nœud 1 nœud 2 nœud 3 nœud 4 saturation contrôleurs saturation interconnect localité d’accès Round-4k Gauthier Voron Virtualisation efficace d’architectures NUMA 21 / 32
- 32. Round-4k sous Xen : répartition de l’espace physique • Mise en œuvre triviale dans un hyperviseur • Répartir l’espace physique (plat) sur les différents nœuds espace virtuel espace physique espace machine . . . . . . 4 Kio nœud 1 nœud 2 nœud 3 nœud 4 saturation contrôleurs saturation interconnect localité d’accès Round-4k Gauthier Voron Virtualisation efficace d’architectures NUMA 22 / 32
- 33. First-touch : maximiser la localité d’accès saturation contrôleurs saturation interconnect localité d’accès Round-4k First-touch • Stratégie First-touch : allouer la mémoire sur le nœud qui l’utilise • Heuristique : un thread utilise généralement la mémoire qu’il alloue • Exemple : la pile d’un thread • Stratégie : allouer la mémoire sur le nœud du thread qui alloue • Stratégie par défault sous Linux Gauthier Voron Virtualisation efficace d’architectures NUMA 23 / 32
- 34. First-touch : fonctionnement sous Linux adresses virtuelles adresses physiques nœud 0 nœud 1 alloc map thread @ nœud 0 Linux @ nœud 0 traduction d’adresses • Un thread de l’application utilise une nouvelle adresse virtuelle • Provoque une demande d’allocation mémoire • Linux alloue de la mémoire physique sur le nœud demandeur Gauthier Voron Virtualisation efficace d’architectures NUMA 24 / 32
- 35. First-touch sous Xen : allocation mémoire paravirtualisée adresses virtuelles adresses physiques adresses machines nœud 0 nœud 1 mapXen @ boot traduction invité traduction hôte • Xen associe toutes les adresses physiques de l’invité au boot Gauthier Voron Virtualisation efficace d’architectures NUMA 25 / 32
- 36. First-touch sous Xen : allocation mémoire paravirtualisée adresses virtuelles adresses physiques adresses machines nœud 0 nœud 1 alloc map thread @ nœud 0 Linux @ nœud 0 traduction invité traduction hôte • Xen associe toutes les adresses physiques de l’invité au boot • Linux alloue les premières adresses physiques libres qu’il trouve • Pas nécessairement associée au bon nœud NUMA Gauthier Voron Virtualisation efficace d’architectures NUMA 25 / 32
- 37. First-touch sous Xen : allocation mémoire paravirtualisée adresses virtuelles adresses physiques adresses machines nœud 0 nœud 1 Xen @ nœud 0 alloc map thread @ nœud 0 Linux @ nœud 0 hypercall traduction invité traduction hôte • Xen associe toutes les adresses physiques de l’invité au boot • Linux alloue les premières adresses physiques libres qu’il trouve • Pas nécessairement associée au bon nœud NUMA • On ajoute un hypercall : Linux demande à Xen de mettre à jour la traduction Gauthier Voron Virtualisation efficace d’architectures NUMA 25 / 32
- 38. First-touch sous Xen : allocation mémoire paravirtualisée adresses virtuelles adresses physiques adresses machines nœud 0 nœud 1 mapXen @ nœud 0 alloc map thread @ nœud 0 Linux @ nœud 0 traduction invité traduction hôte • Xen associe toutes les adresses physiques de l’invité au boot • Linux alloue les premières adresses physiques libres qu’il trouve • Pas nécessairement associée au bon nœud NUMA • On ajoute un hypercall : Linux demande à Xen de mettre à jour la traduction Gauthier Voron Virtualisation efficace d’architectures NUMA 25 / 32
- 39. Carrefour : corriger les défauts des autres stratégies saturation contrôleurs saturation interconnect localité d’accès Round-4k First-touch • Stratégie Carrefour → corriger les défauts des autres stratégies Gauthier Voron Virtualisation efficace d’architectures NUMA 26 / 32
- 40. Carrefour : corriger les défauts des autres stratégies saturation contrôleurs saturation interconnect localité d’accès Round-4k First-touch • Stratégie Carrefour → corriger les défauts des autres stratégies • Faible localité g Gauthier Voron Virtualisation efficace d’architectures NUMA 26 / 32
- 41. Carrefour : corriger les défauts des autres stratégies saturation contrôleurs saturation interconnect localité d’accès Round-4k First-touch • Stratégie Carrefour → corriger les défauts des autres stratégies • Faible localité → migration Gauthier Voron Virtualisation efficace d’architectures NUMA 26 / 32
- 42. Carrefour : corriger les défauts des autres stratégies saturation contrôleurs saturation interconnect localité d’accès Round-4k First-touch • Stratégie Carrefour → corriger les défauts des autres stratégies • Faible localité → migration A B • Saturation contrôleur p Gauthier Voron Virtualisation efficace d’architectures NUMA 26 / 32
- 43. Carrefour : corriger les défauts des autres stratégies saturation contrôleurs saturation interconnect localité d’accès Round-4k First-touch • Stratégie Carrefour → corriger les défauts des autres stratégies • Faible localité → migration A B • Saturation contrôleur → répartition Gauthier Voron Virtualisation efficace d’architectures NUMA 26 / 32
- 44. Carrefour sous Linux 1 Observation des accès mémoire grâce aux compteurs matériels • Construction de la liste des adresses virtuelles accédées • • 2 Prise de décision grâce aux observations 3 Migration des données en modifiant la table des pages • Changement de traduction des adresses virtuelles problématiques Gauthier Voron Virtualisation efficace d’architectures NUMA 27 / 32
- 45. Carrefour sous Xen 1 Observation des accès mémoire grâce aux compteurs matériels • Construction de la liste des adresses virtuelles accédées 2 Prise de décision grâce aux observations 3 Migration des données en modifiant la table des pages hôte • Changement de traduction des adresses physique problématiques Gauthier Voron Virtualisation efficace d’architectures NUMA 28 / 32
- 46. Carrefour sous Xen 1 Observation des accès mémoire grâce aux compteurs matériels • Construction de la liste des adresses virtuelles accédées • Observation de la table des pages invité • Traduction des adresses virtuelles en adresses physiques 2 Prise de décision grâce aux observations 3 Migration des données en modifiant la table des pages hôte • Changement de traduction des adresses physique problématiques Gauthier Voron Virtualisation efficace d’architectures NUMA 28 / 32
- 47. Évaluation : configuration logicielle et matérielle • Mise en œuvre sur Linux 3.9 / Xen 4.5 • Mesure du temps de complétion sur 29 applications de 5 benchmarks Benchmarks Type d’applications Parsec Traitement de graphes / traitement d’image NPB Calcul scientifique Mosbench MapReduce multicœur / recherche de données X-Stream Traitement de graphes sur disque YCSB Bases de données NoSQL • Exécution sur une machine AMD de 8 nœuds • Par nœud : 6 cœurs (2.2 GHz) / 16 Gio de mémoire • Bande passante contrôleur mémoire : 13 Gio/s • Bande passante interconnect : 6 Gio/s asymétriques Gauthier Voron Virtualisation efficace d’architectures NUMA 29 / 32
- 48. Évaluation : surcoût de la virtualisation • Comparaison des temps de complétion Xen / Linux • Linux utilise la meilleure politique mémoire • Xen utilise la politique round-1g • Xen + NUMA utilise la meilleure politique mémoire 0 1 2 3 4 5 6 7 8 9 bodytrack facesimfluidanim ate stream cluster sw aptions x264 bt.C cg.C dc.B ep.D ft.C lu.C m g.D sp.C ua.C w c w r w rm empca km eanspsearchy m em cached beliefbfs cc pagerank sssp cassandra m ongodb Surcoût/Linux Xen Xen + NUMA • Gain de performance jusqu’à 700% avec Xen + NUMA • Surcoût inférieur à 50% : 12/29 → 23/29 applications Gauthier Voron Virtualisation efficace d’architectures NUMA 30 / 32
- 49. Évaluation : machines virtuelles multiples • Comparaison des temps de complétion Xen + NUMA / Xen • Deux systèmes invités exécutés simultanément • exécutés sur des nœuds distincts 0 1 2 3 4 5 6 cg.C cg.C lu.C cg.C sp.C cg.C lu.C facesim sp.C km eans Speedup/Xen invité 1 invité 2 • exécutés sur les mêmes nœuds 0 0.5 1 1.5 2 2.5 3 3.5 sw aptions bodytrack cg.C cg.C lu.C cg.C sp.C cg.C sp.C km eans w rm em w c Speedup/Xen invité 1 invité 2 • Pas de dégradation des performances • Jusqu’à 400% de speedup par rapport à Xen Gauthier Voron Virtualisation efficace d’architectures NUMA 31 / 32
- 50. Conclusion • Le placement NUMA est un facteur de performance majeur pour les machines virtuelles multinœud • Une coopération entre les systèmes invités et l’hyperviseur suffit à diminuer le surcoût de la virtualisation à un niveau tolérable • Il est possible d’utiliser dans un hyperviseur les politiques mises en œuvre dans les systèmes d’exploitation Gauthier Voron Virtualisation efficace d’architectures NUMA 32 / 32
- 51. Conclusion • Le placement NUMA est un facteur de performance majeur pour les machines virtuelles multinœud • Une coopération entre les systèmes invités et l’hyperviseur suffit à diminuer le surcoût de la virtualisation à un niveau tolérable • Il est possible d’utiliser dans un hyperviseur les politiques mises en œuvre dans les systèmes d’exploitation • Merci pour votre attention Gauthier Voron Virtualisation efficace d’architectures NUMA 32 / 32