SlideShare une entreprise Scribd logo
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é
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
É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
É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
É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
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
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

Contenu connexe

Similaire à Osis18_Cloud : Virtualisation efficace d’architectures NUMA

INTRO TO VIRTUALISATION TECHNOLOGIE ET CLOUD
INTRO TO VIRTUALISATION TECHNOLOGIE ET CLOUDINTRO TO VIRTUALISATION TECHNOLOGIE ET CLOUD
INTRO TO VIRTUALISATION TECHNOLOGIE ET CLOUD
DALLELKHEZZANE2
 
cours-ADMINISTRATION DUN RESEAU INFORMATIQUE.pdf
cours-ADMINISTRATION DUN RESEAU INFORMATIQUE.pdfcours-ADMINISTRATION DUN RESEAU INFORMATIQUE.pdf
cours-ADMINISTRATION DUN RESEAU INFORMATIQUE.pdf
GodefroyCheumaniTche1
 
Systeme embarque
Systeme embarqueSysteme embarque
Systeme embarque
Mohammed TIGHREMT
 
Composantes hardware du mainframe
Composantes hardware du mainframeComposantes hardware du mainframe
Composantes hardware du mainframe
smiste
 
Embarqués temps réel
Embarqués temps réelEmbarqués temps réel
Embarqués temps réelmikhailether
 
ch1_introduction_aux_systemes_embarques.pdf
ch1_introduction_aux_systemes_embarques.pdfch1_introduction_aux_systemes_embarques.pdf
ch1_introduction_aux_systemes_embarques.pdf
HoudaBezziane
 
MariaDB Paris Workshop 2023 - DARVA presentation
MariaDB Paris Workshop 2023 - DARVA presentationMariaDB Paris Workshop 2023 - DARVA presentation
MariaDB Paris Workshop 2023 - DARVA presentation
MariaDB plc
 
Structure_Des_Ordinateurs
Structure_Des_OrdinateursStructure_Des_Ordinateurs
Structure_Des_Ordinateurs
Abderrahman ZIANI
 
Présentation de notre offre TeraBackup
Présentation de notre offre TeraBackupPrésentation de notre offre TeraBackup
Présentation de notre offre TeraBackup
Ozitem
 
Architecture ordinateur-2-architecture-de-base
Architecture ordinateur-2-architecture-de-baseArchitecture ordinateur-2-architecture-de-base
Architecture ordinateur-2-architecture-de-base
Abdoulaye Dieng
 
Es82 g formation-ibm-system-z-presentation-technique-de-l-evolution-du-materi...
Es82 g formation-ibm-system-z-presentation-technique-de-l-evolution-du-materi...Es82 g formation-ibm-system-z-presentation-technique-de-l-evolution-du-materi...
Es82 g formation-ibm-system-z-presentation-technique-de-l-evolution-du-materi...CERTyou Formation
 
.NET Microframework: du code, de l’électronique, de la robotique
.NET Microframework: du code, de l’électronique, de la robotique.NET Microframework: du code, de l’électronique, de la robotique
.NET Microframework: du code, de l’électronique, de la robotique
Microsoft
 
Propostion un Iaas
Propostion un IaasPropostion un Iaas
Propostion un Iaas
yacine sebihi
 
MapReduce: Traitement de données distribué à grande échelle simplifié
MapReduce: Traitement de données distribué à grande échelle simplifiéMapReduce: Traitement de données distribué à grande échelle simplifié
MapReduce: Traitement de données distribué à grande échelle simplifié
Mathieu Dumoulin
 
Cahier des charges
Cahier des charges Cahier des charges
Cahier des charges
Anwar Youssef
 
BigData_Technologies_PL.pdf
BigData_Technologies_PL.pdfBigData_Technologies_PL.pdf
BigData_Technologies_PL.pdf
MissaouiWissal
 
Ccna1
Ccna1Ccna1
Alphorm.com Formation Microsoft Hyperconvergence
Alphorm.com Formation Microsoft HyperconvergenceAlphorm.com Formation Microsoft Hyperconvergence
Alphorm.com Formation Microsoft Hyperconvergence
Alphorm
 
BreizhCamp 2019 - IoT et open source hardware pour la collecte de timeseries
BreizhCamp 2019 - IoT et open source hardware pour la collecte de timeseriesBreizhCamp 2019 - IoT et open source hardware pour la collecte de timeseries
BreizhCamp 2019 - IoT et open source hardware pour la collecte de timeseries
Xavier MARIN
 

Similaire à Osis18_Cloud : Virtualisation efficace d’architectures NUMA (20)

INTRO TO VIRTUALISATION TECHNOLOGIE ET CLOUD
INTRO TO VIRTUALISATION TECHNOLOGIE ET CLOUDINTRO TO VIRTUALISATION TECHNOLOGIE ET CLOUD
INTRO TO VIRTUALISATION TECHNOLOGIE ET CLOUD
 
cours-ADMINISTRATION DUN RESEAU INFORMATIQUE.pdf
cours-ADMINISTRATION DUN RESEAU INFORMATIQUE.pdfcours-ADMINISTRATION DUN RESEAU INFORMATIQUE.pdf
cours-ADMINISTRATION DUN RESEAU INFORMATIQUE.pdf
 
Systeme embarque
Systeme embarqueSysteme embarque
Systeme embarque
 
Composantes hardware du mainframe
Composantes hardware du mainframeComposantes hardware du mainframe
Composantes hardware du mainframe
 
Embarqués temps réel
Embarqués temps réelEmbarqués temps réel
Embarqués temps réel
 
ch1_introduction_aux_systemes_embarques.pdf
ch1_introduction_aux_systemes_embarques.pdfch1_introduction_aux_systemes_embarques.pdf
ch1_introduction_aux_systemes_embarques.pdf
 
MariaDB Paris Workshop 2023 - DARVA presentation
MariaDB Paris Workshop 2023 - DARVA presentationMariaDB Paris Workshop 2023 - DARVA presentation
MariaDB Paris Workshop 2023 - DARVA presentation
 
Structure_Des_Ordinateurs
Structure_Des_OrdinateursStructure_Des_Ordinateurs
Structure_Des_Ordinateurs
 
Présentation de notre offre TeraBackup
Présentation de notre offre TeraBackupPrésentation de notre offre TeraBackup
Présentation de notre offre TeraBackup
 
Architecture ordinateur-2-architecture-de-base
Architecture ordinateur-2-architecture-de-baseArchitecture ordinateur-2-architecture-de-base
Architecture ordinateur-2-architecture-de-base
 
Es82 g formation-ibm-system-z-presentation-technique-de-l-evolution-du-materi...
Es82 g formation-ibm-system-z-presentation-technique-de-l-evolution-du-materi...Es82 g formation-ibm-system-z-presentation-technique-de-l-evolution-du-materi...
Es82 g formation-ibm-system-z-presentation-technique-de-l-evolution-du-materi...
 
.NET Microframework: du code, de l’électronique, de la robotique
.NET Microframework: du code, de l’électronique, de la robotique.NET Microframework: du code, de l’électronique, de la robotique
.NET Microframework: du code, de l’électronique, de la robotique
 
Propostion un Iaas
Propostion un IaasPropostion un Iaas
Propostion un Iaas
 
MapReduce: Traitement de données distribué à grande échelle simplifié
MapReduce: Traitement de données distribué à grande échelle simplifiéMapReduce: Traitement de données distribué à grande échelle simplifié
MapReduce: Traitement de données distribué à grande échelle simplifié
 
Cahier des charges
Cahier des charges Cahier des charges
Cahier des charges
 
BigData_Technologies_PL.pdf
BigData_Technologies_PL.pdfBigData_Technologies_PL.pdf
BigData_Technologies_PL.pdf
 
Ccna1
Ccna1Ccna1
Ccna1
 
Grid computing
Grid computingGrid computing
Grid computing
 
Alphorm.com Formation Microsoft Hyperconvergence
Alphorm.com Formation Microsoft HyperconvergenceAlphorm.com Formation Microsoft Hyperconvergence
Alphorm.com Formation Microsoft Hyperconvergence
 
BreizhCamp 2019 - IoT et open source hardware pour la collecte de timeseries
BreizhCamp 2019 - IoT et open source hardware pour la collecte de timeseriesBreizhCamp 2019 - IoT et open source hardware pour la collecte de timeseries
BreizhCamp 2019 - IoT et open source hardware pour la collecte de timeseries
 

Plus de Pôle Systematic Paris-Region

OSIS19_IoT :Transparent remote connectivity to short-range IoT devices, by Na...
OSIS19_IoT :Transparent remote connectivity to short-range IoT devices, by Na...OSIS19_IoT :Transparent remote connectivity to short-range IoT devices, by Na...
OSIS19_IoT :Transparent remote connectivity to short-range IoT devices, by Na...
Pôle Systematic Paris-Region
 
OSIS19_Cloud : SAFC: Scheduling and Allocation Framework for Containers in a ...
OSIS19_Cloud : SAFC: Scheduling and Allocation Framework for Containers in a ...OSIS19_Cloud : SAFC: Scheduling and Allocation Framework for Containers in a ...
OSIS19_Cloud : SAFC: Scheduling and Allocation Framework for Containers in a ...
Pôle Systematic Paris-Region
 
OSIS19_Cloud : Qu’apporte l’observabilité à la gestion de configuration? par ...
OSIS19_Cloud : Qu’apporte l’observabilité à la gestion de configuration? par ...OSIS19_Cloud : Qu’apporte l’observabilité à la gestion de configuration? par ...
OSIS19_Cloud : Qu’apporte l’observabilité à la gestion de configuration? par ...
Pôle Systematic Paris-Region
 
OSIS19_Cloud : Performance and power management in virtualized data centers, ...
OSIS19_Cloud : Performance and power management in virtualized data centers, ...OSIS19_Cloud : Performance and power management in virtualized data centers, ...
OSIS19_Cloud : Performance and power management in virtualized data centers, ...
Pôle Systematic Paris-Region
 
OSIS19_Cloud : Des objets dans le cloud, et qui y restent -- L'expérience du ...
OSIS19_Cloud : Des objets dans le cloud, et qui y restent -- L'expérience du ...OSIS19_Cloud : Des objets dans le cloud, et qui y restent -- L'expérience du ...
OSIS19_Cloud : Des objets dans le cloud, et qui y restent -- L'expérience du ...
Pôle Systematic Paris-Region
 
OSIS19_Cloud : Attribution automatique de ressources pour micro-services, Alt...
OSIS19_Cloud : Attribution automatique de ressources pour micro-services, Alt...OSIS19_Cloud : Attribution automatique de ressources pour micro-services, Alt...
OSIS19_Cloud : Attribution automatique de ressources pour micro-services, Alt...
Pôle Systematic Paris-Region
 
OSIS19_IoT : State of the art in security for embedded systems and IoT, by Pi...
OSIS19_IoT : State of the art in security for embedded systems and IoT, by Pi...OSIS19_IoT : State of the art in security for embedded systems and IoT, by Pi...
OSIS19_IoT : State of the art in security for embedded systems and IoT, by Pi...
Pôle Systematic Paris-Region
 
Osis19_IoT: Proof of Pointer Programs with Ownership in SPARK, by Yannick Moy
Osis19_IoT: Proof of Pointer Programs with Ownership in SPARK, by Yannick MoyOsis19_IoT: Proof of Pointer Programs with Ownership in SPARK, by Yannick Moy
Osis19_IoT: Proof of Pointer Programs with Ownership in SPARK, by Yannick Moy
Pôle Systematic Paris-Region
 
Osis18_Cloud : Pas de commun sans communauté ?
Osis18_Cloud : Pas de commun sans communauté ?Osis18_Cloud : Pas de commun sans communauté ?
Osis18_Cloud : Pas de commun sans communauté ?
Pôle Systematic Paris-Region
 
Osis18_Cloud : Projet Wolphin
Osis18_Cloud : Projet Wolphin Osis18_Cloud : Projet Wolphin
Osis18_Cloud : Projet Wolphin
Pôle Systematic Paris-Region
 
Osis18_Cloud : DeepTorrent Stockage distribué perenne basé sur Bittorrent
Osis18_Cloud : DeepTorrent Stockage distribué perenne basé sur BittorrentOsis18_Cloud : DeepTorrent Stockage distribué perenne basé sur Bittorrent
Osis18_Cloud : DeepTorrent Stockage distribué perenne basé sur Bittorrent
Pôle Systematic Paris-Region
 
Osis18_Cloud : Software-heritage
Osis18_Cloud : Software-heritageOsis18_Cloud : Software-heritage
Osis18_Cloud : Software-heritage
Pôle Systematic Paris-Region
 
OSIS18_IoT: L'approche machine virtuelle pour les microcontrôleurs, le projet...
OSIS18_IoT: L'approche machine virtuelle pour les microcontrôleurs, le projet...OSIS18_IoT: L'approche machine virtuelle pour les microcontrôleurs, le projet...
OSIS18_IoT: L'approche machine virtuelle pour les microcontrôleurs, le projet...
Pôle Systematic Paris-Region
 
OSIS18_IoT: La securite des objets connectes a bas cout avec l'os et riot
OSIS18_IoT: La securite des objets connectes a bas cout avec l'os et riotOSIS18_IoT: La securite des objets connectes a bas cout avec l'os et riot
OSIS18_IoT: La securite des objets connectes a bas cout avec l'os et riot
Pôle Systematic Paris-Region
 
OSIS18_IoT : Solution de mise au point pour les systemes embarques, par Julio...
OSIS18_IoT : Solution de mise au point pour les systemes embarques, par Julio...OSIS18_IoT : Solution de mise au point pour les systemes embarques, par Julio...
OSIS18_IoT : Solution de mise au point pour les systemes embarques, par Julio...
Pôle Systematic Paris-Region
 
OSIS18_IoT : Securisation du reseau des objets connectes, par Nicolas LE SAUZ...
OSIS18_IoT : Securisation du reseau des objets connectes, par Nicolas LE SAUZ...OSIS18_IoT : Securisation du reseau des objets connectes, par Nicolas LE SAUZ...
OSIS18_IoT : Securisation du reseau des objets connectes, par Nicolas LE SAUZ...
Pôle Systematic Paris-Region
 
OSIS18_IoT : Ada and SPARK - Defense in Depth for Safe Micro-controller Progr...
OSIS18_IoT : Ada and SPARK - Defense in Depth for Safe Micro-controller Progr...OSIS18_IoT : Ada and SPARK - Defense in Depth for Safe Micro-controller Progr...
OSIS18_IoT : Ada and SPARK - Defense in Depth for Safe Micro-controller Progr...
Pôle Systematic Paris-Region
 
OSIS18_IoT : RTEMS pour l'IoT professionnel, par Pierre Ficheux (Smile ECS)
OSIS18_IoT : RTEMS pour l'IoT professionnel, par Pierre Ficheux (Smile ECS)OSIS18_IoT : RTEMS pour l'IoT professionnel, par Pierre Ficheux (Smile ECS)
OSIS18_IoT : RTEMS pour l'IoT professionnel, par Pierre Ficheux (Smile ECS)
Pôle Systematic Paris-Region
 
PyParis 2017 / Un mooc python, by thierry parmentelat
PyParis 2017 / Un mooc python, by thierry parmentelatPyParis 2017 / Un mooc python, by thierry parmentelat
PyParis 2017 / Un mooc python, by thierry parmentelat
Pôle Systematic Paris-Region
 
PyParis2017 / Python pour les enseignants des classes préparatoires, by Olivi...
PyParis2017 / Python pour les enseignants des classes préparatoires, by Olivi...PyParis2017 / Python pour les enseignants des classes préparatoires, by Olivi...
PyParis2017 / Python pour les enseignants des classes préparatoires, by Olivi...
Pôle Systematic Paris-Region
 

Plus de Pôle Systematic Paris-Region (20)

OSIS19_IoT :Transparent remote connectivity to short-range IoT devices, by Na...
OSIS19_IoT :Transparent remote connectivity to short-range IoT devices, by Na...OSIS19_IoT :Transparent remote connectivity to short-range IoT devices, by Na...
OSIS19_IoT :Transparent remote connectivity to short-range IoT devices, by Na...
 
OSIS19_Cloud : SAFC: Scheduling and Allocation Framework for Containers in a ...
OSIS19_Cloud : SAFC: Scheduling and Allocation Framework for Containers in a ...OSIS19_Cloud : SAFC: Scheduling and Allocation Framework for Containers in a ...
OSIS19_Cloud : SAFC: Scheduling and Allocation Framework for Containers in a ...
 
OSIS19_Cloud : Qu’apporte l’observabilité à la gestion de configuration? par ...
OSIS19_Cloud : Qu’apporte l’observabilité à la gestion de configuration? par ...OSIS19_Cloud : Qu’apporte l’observabilité à la gestion de configuration? par ...
OSIS19_Cloud : Qu’apporte l’observabilité à la gestion de configuration? par ...
 
OSIS19_Cloud : Performance and power management in virtualized data centers, ...
OSIS19_Cloud : Performance and power management in virtualized data centers, ...OSIS19_Cloud : Performance and power management in virtualized data centers, ...
OSIS19_Cloud : Performance and power management in virtualized data centers, ...
 
OSIS19_Cloud : Des objets dans le cloud, et qui y restent -- L'expérience du ...
OSIS19_Cloud : Des objets dans le cloud, et qui y restent -- L'expérience du ...OSIS19_Cloud : Des objets dans le cloud, et qui y restent -- L'expérience du ...
OSIS19_Cloud : Des objets dans le cloud, et qui y restent -- L'expérience du ...
 
OSIS19_Cloud : Attribution automatique de ressources pour micro-services, Alt...
OSIS19_Cloud : Attribution automatique de ressources pour micro-services, Alt...OSIS19_Cloud : Attribution automatique de ressources pour micro-services, Alt...
OSIS19_Cloud : Attribution automatique de ressources pour micro-services, Alt...
 
OSIS19_IoT : State of the art in security for embedded systems and IoT, by Pi...
OSIS19_IoT : State of the art in security for embedded systems and IoT, by Pi...OSIS19_IoT : State of the art in security for embedded systems and IoT, by Pi...
OSIS19_IoT : State of the art in security for embedded systems and IoT, by Pi...
 
Osis19_IoT: Proof of Pointer Programs with Ownership in SPARK, by Yannick Moy
Osis19_IoT: Proof of Pointer Programs with Ownership in SPARK, by Yannick MoyOsis19_IoT: Proof of Pointer Programs with Ownership in SPARK, by Yannick Moy
Osis19_IoT: Proof of Pointer Programs with Ownership in SPARK, by Yannick Moy
 
Osis18_Cloud : Pas de commun sans communauté ?
Osis18_Cloud : Pas de commun sans communauté ?Osis18_Cloud : Pas de commun sans communauté ?
Osis18_Cloud : Pas de commun sans communauté ?
 
Osis18_Cloud : Projet Wolphin
Osis18_Cloud : Projet Wolphin Osis18_Cloud : Projet Wolphin
Osis18_Cloud : Projet Wolphin
 
Osis18_Cloud : DeepTorrent Stockage distribué perenne basé sur Bittorrent
Osis18_Cloud : DeepTorrent Stockage distribué perenne basé sur BittorrentOsis18_Cloud : DeepTorrent Stockage distribué perenne basé sur Bittorrent
Osis18_Cloud : DeepTorrent Stockage distribué perenne basé sur Bittorrent
 
Osis18_Cloud : Software-heritage
Osis18_Cloud : Software-heritageOsis18_Cloud : Software-heritage
Osis18_Cloud : Software-heritage
 
OSIS18_IoT: L'approche machine virtuelle pour les microcontrôleurs, le projet...
OSIS18_IoT: L'approche machine virtuelle pour les microcontrôleurs, le projet...OSIS18_IoT: L'approche machine virtuelle pour les microcontrôleurs, le projet...
OSIS18_IoT: L'approche machine virtuelle pour les microcontrôleurs, le projet...
 
OSIS18_IoT: La securite des objets connectes a bas cout avec l'os et riot
OSIS18_IoT: La securite des objets connectes a bas cout avec l'os et riotOSIS18_IoT: La securite des objets connectes a bas cout avec l'os et riot
OSIS18_IoT: La securite des objets connectes a bas cout avec l'os et riot
 
OSIS18_IoT : Solution de mise au point pour les systemes embarques, par Julio...
OSIS18_IoT : Solution de mise au point pour les systemes embarques, par Julio...OSIS18_IoT : Solution de mise au point pour les systemes embarques, par Julio...
OSIS18_IoT : Solution de mise au point pour les systemes embarques, par Julio...
 
OSIS18_IoT : Securisation du reseau des objets connectes, par Nicolas LE SAUZ...
OSIS18_IoT : Securisation du reseau des objets connectes, par Nicolas LE SAUZ...OSIS18_IoT : Securisation du reseau des objets connectes, par Nicolas LE SAUZ...
OSIS18_IoT : Securisation du reseau des objets connectes, par Nicolas LE SAUZ...
 
OSIS18_IoT : Ada and SPARK - Defense in Depth for Safe Micro-controller Progr...
OSIS18_IoT : Ada and SPARK - Defense in Depth for Safe Micro-controller Progr...OSIS18_IoT : Ada and SPARK - Defense in Depth for Safe Micro-controller Progr...
OSIS18_IoT : Ada and SPARK - Defense in Depth for Safe Micro-controller Progr...
 
OSIS18_IoT : RTEMS pour l'IoT professionnel, par Pierre Ficheux (Smile ECS)
OSIS18_IoT : RTEMS pour l'IoT professionnel, par Pierre Ficheux (Smile ECS)OSIS18_IoT : RTEMS pour l'IoT professionnel, par Pierre Ficheux (Smile ECS)
OSIS18_IoT : RTEMS pour l'IoT professionnel, par Pierre Ficheux (Smile ECS)
 
PyParis 2017 / Un mooc python, by thierry parmentelat
PyParis 2017 / Un mooc python, by thierry parmentelatPyParis 2017 / Un mooc python, by thierry parmentelat
PyParis 2017 / Un mooc python, by thierry parmentelat
 
PyParis2017 / Python pour les enseignants des classes préparatoires, by Olivi...
PyParis2017 / Python pour les enseignants des classes préparatoires, by Olivi...PyParis2017 / Python pour les enseignants des classes préparatoires, by Olivi...
PyParis2017 / Python pour les enseignants des classes préparatoires, by Olivi...
 

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