LOGICIEL Virtual Machine Loader Configuration des HAT Shutdown Exécuté sur Exécuté sur Exécuté au démarrage de la machine virtuelle Réveil (WTI) Initie Initie .... LÉGENDE E(X) : X Chiffré Composant hors de la TCB Composant dans la TCB Action Transfert de Données X : X en clair E(Kernel) Bootloader E(FileSystem) SVM Controller SVM Agent Configuration des SVM Désactive soft reset Exécuté à l'arrêt de la machine virtuelle Initie Initie
FIGURE4.31 – Infrastructure Tsunamy
Chapitre
5
Évaluations et résultats
Contents
5.1 Plateforme expérimentale . . . 120
5.2 Systèmes d’exploitation NetBSD et Almos . . . 120
5.3 Choix des benchmarks . . . 121
5.4 Évaluation du surcoût matériel . . . 122
5.5 Évaluation du surcoût en performance. . . 123
5.6 Évaluation de la sécurité . . . 131
Chapitre 5. Évaluations et résultats
Ce chapitre vise à évaluer notre solution d’architecture manycore sécurisée pour l’exécution de plusieurs machines virtuelles. Cette évaluation est séparée en trois parties distinctes. Nous évalue-rons tout d’abord dans la section 5.4 le surcoût matériel de notre solution, puis dans la section 5.5 le surcoût induit en performance. Pour cette évaluation, nous estimerons tout d’abord le surcoût in-duit par les HATs, le surcoût introin-duit par le système de fichiers chiffré et celui dû à l’exécution de plusieurs machines virtuelles concurrentes. Nous évaluerons également dans cette partie le temps pris par l’exécution de la procédure de démarrage et d’arrêt des machines virtuelles. Enfin, dans la section 5.6, nous ferons une analyse de la sécurité offerte par notre solution.
5.1 Plateforme expérimentale
Toutes nos évaluations ont été effectuées sur le modèle SystemC, précis au cycle, de l’architec-ture Tsunamy détaillée dans la section 4.1. Le prototype virtuel de cette architecl’architec-ture est générique et permet de générer des plateformes avec un nombre variable de clusters. Pour nos évaluations, nous avons fait varier le nombre de clusters entre 2 et 16. Nous avons donc aussi fixé le nombre maximal de machines virtuelles pouvant s’exécuter en parallèle à 16. Les paramètres des caches de premier et de second niveau sont donnés dans la table 5.1.
Paramètres Taille
L1 Cache Sets (I & D) 64 L1 Cache Ways (I & D) 4 L1 Cache Words (I & D) 16 L2 Cache Sets (I & D) 256 L2 Cache Ways (I & D) 16 L2 Cache Words (I & D) 16 TLB Sets (I & D) 8 TLB Ways (I & D) 8
TABLE5.1 – Paramètres des caches de l’architecture
5.2 Systèmes d’exploitation NetBSD et Almos
Toutes les évaluations ont été faites en utilisant le système d’exploitation ALMOS [16], qui est dé-veloppé dans l’équipe. Celui-ci est un système d’exploitation expérimental de type UNIX dédié aux architectures manycore. Bien que le système d’exploitation NetBSD ait été porté sur notre solution, nous avons préféré utiliser ALMOS dans nos évaluations pour des raisons de temps de simulations. En effet, le temps requis pour le boot du système d’exploitation NetBSD est bien plus important que
Chapitre 5. Évaluations et résultats
celui nécessaire pour le système d’exploitation ALMOS.
Par construction, nos solutions ne sont pas dépendantes de la pile logicielle qui s’exécute au sein de la machine virtuelle. C’est pourquoi nous pensons que des résultats obtenus avec le système d’exploitation NetBSD auraient été les mêmes, en ordre de grandeur, que nos évaluations réalisées avec ALMOS.
Bien que nos évaluations ont été faites à l’aide du système d’exploitation ALMOS nous avons aussi exécuté le système d’exploitation NetBSD. Celui-ci nous a permis de valider les deux modes de traduction offerts par les HATs, à savoir les traductions pour des systèmes d’exploitation 40 et 32 bits. Par ailleurs, son portage a été très minimaliste, et a permis de montrer que la solution présentée n’est pas dépendante d’un système d’exploitation en particulier. Le portage a consisté à ajouter, au sein des drivers du contrôleur de disque de NetBSD, les instructions nécessaires pour la gestion des invalidations du cache L2. Pour cela avant chaque accès au disque nous invalidons, dans le cache L2, les adresses mémoire du buffer destination (ou source) utilisé par le driver. En effet, la version de NetBSD portée pour l’architecture TSAR ne prenait pas en compte le cluster I/O, et plus particu-lièrement la manière dont les périphériques, tel que le contrôleur de disque, communiquent avec la mémoire. Dans cette version les périphériques n’avaient pas d’accès direct aux bancs de mémoire, il n’était alors pas nécessaire de gérer la cohérence entre les caches L2 et la mémoire de façon logicielle.
Au cours de nos expérimentations nous avons également lancé simultanément des machines vir-tuelles exécutant ALMOS et NetBSD. Ceci nous a permis de montrer que notre hyperviseur et que les solutions matérielles sont vraiment indépendants des systèmes qui sont lancés et que ces deux systèmes peuvent cohabiter sur la même plateforme.
5.3 Choix des benchmarks
Les applications utilisées pour l’évaluation de nos solutions sont des applications parallèles multi-threads. Pour toutes les évaluations utilisant ces applications, nous plaçons un thread par cœur. Les applications utilisées peuvent se classifier en trois types suivant le modèle d’utilisation des données partagées :
– Les données ne sont pas partagées entre les threads.
– Les données sont partagées mais ne subissent pas de modifications par les threads. – Les données sont partagées et subissent des modifications par les threads.
Pour nos évaluations nous avons utilisé quatre applications :
– FFT (Fast Fourier Transform) de la suite Splash-2 [106]. Cette application réalise la transformée de Fourier rapide. Les données sont partagées en lecture mais les modifications sont faites localement.
Chapitre 5. Évaluations et résultats
– Histogram de la suite de benchmarks Phoenix-2 [107]. Cette application produit un histo-gramme des pixels dans les canaux rouge, vert et bleu d’une image fournie en entrée. Cette image est découpée et distribuée entre chaque thread qui en traite localement une partie. Cette application ne possède pas de données partagées.
– Kmeans de la suite de benchmarks Phoenix-2. Cette application fait un partitionnement en k-moyennes qui est une méthode de partitionnement de données. Pour un nombre de points donnés et un entier k, on cherche à diviser les points en k sous-ensembles. Les données de cette application sont partagées en lecture mais les modifications sont faites localement.
– Convol est une application qui réalise un filtrage d’images médicales à l’aide d’un noyau de convolution. Le filtre est séparable et peut donc être réalisé en deux parties : un filtrage horizontal sur les lignes puis un filtrage vertical sur les colonnes. Le découpage en threads est fait de façon à ce que les lectures de données soient locales et les modifications soient distantes. De ce fait cette application appartient au troisième type présenté précédemment.
La table 5.2 présente la configuration de chaque application utilisée.
Application Données en entrée
Histogram image de 25 Mo (3 408×2 556) Convol image de 1 024×1 024 pixels
FFT 218points complexes
Kmeans 10 000 points
TABLE5.2 – Paramètres des applications
5.4 Évaluation du surcoût matériel
Dans cette section nous cherchons à évaluer le surcoût matériel induit par l’ajout des composants HATs et des composants SVMs (Controller et Agent). Pour cela, nous comparons le nombre de bits mémorisant dans chacun des composants avec le nombre de bits mémorisant contenus dans un cache de premier niveau.
Comme précisé dans la section 4.2 les HATs possèdent 182 octets de mémoire. En comparaison, une ligne du cache de premier niveau contient 64 octets de mémoire. Sachant qu’il y a 256 lignes de caches dans un cache de premier niveau, et que le cache de premier niveau possède deux caches distincts (données et instructions), le coût total en bits mémorisant, sans compter le répertoire, est de 32Ko par cache de premier niveau. Notre plateforme comporte 4 cœurs par clusters, et donc 4 caches de premier niveau, soit un total de 128Ko. Notre solution nécessite 6 HATs par clusters : 4 au niveau des cœurs, 1 au niveau du DMA et 1 pour le HCrypt. Au total l’ajout des HATs équivaut donc à 1 092 octets de mémoire par clusters.
Chapitre 5. Évaluations et résultats
Le composant SVM Controller contient 24 octets de mémoire pour son fonctionnement interne et 5 octets de mémoire par canal, servant à stocker les informations de déploiement des machines virtuelles. Dans nos évaluations nous avons fixé le nombre de canaux à 16, puisque notre plus grande plateforme comportait 16 clusters. Dans ce cas d’étude, le composant SVM Controller possède donc 104 octets de mémoire.
Un composant SVM Agent contient 21 octets de mémoire pour son fonctionnement interne et 21 octets de mémoire pour les registres de configuration relatifs aux machines virtuelles. Au total un SVM Agent coûte donc 42 octets de mémoire. Sachant qu’il y a un SVM Agent par cluster, sauf dans le cluster hyperviseur qui contient le SVM Controller, et que nous nous plaçons dans un cas d’étude à 16 clusters, nous avons donc 15 SVM Agents soit un total de 630 octets de mémoire.
Nous pouvons en conclure que l’ajout des composants HATs, SVM Controller et SVM Agent a peu d’impact en terme de surcoût matériel. Par exemple, en considérant une plateforme à 16 clusters avec 4 cœurs par clusters, l’ensemble des caches de premier niveau représente 2Mo de mémoire alors que le cumul de nos composants sur l’ensemble de la plateforme représente 18Ko de mémoire soit moins de 1% de surcoût.
5.5 Évaluation du surcoût en performance
Dans cette section, nous visons à évaluer le surcoût en performance des solutions présentées dans le chapitre 4. Nous présenterons tout d’abord une évaluation du surcoût en performance en terme de temps d’exécution induit par l’introduction des composants HATs, puis du surcoût induit par le sys-tème de fichiers chiffré. Nous évaluerons aussi le temps nécessaire pour l’exécution des procédures de démarrage et d’arrêt d’une machine virtuelle. Enfin, nous évaluerons l’impact de l’exécution de plusieurs machines virtuelles de manière concurrentes sur une même plateforme.
5.5.1 Surcoût temporel induit par les HATs
La figure 5.1 montre le temps d’exécution sur la plateforme Tsunamy des 4 applications choisies. Ces temps sont normalisés par nombre de cœurs et par application par rapport aux temps d’exécu-tions de ces mêmes applicad’exécu-tions sur l’architecture TSAR.
Cette expérimentation vise à mesurer le surcoût en temps induit par l’ajout des HATs dans l’ar-chitecture, en particulier par la traduction supplémentaire effectuée pour toute requête sortant du L1. Chaque application a été exécutée sur des configurations à 1, 4, 8, 16 et 32 threads, où chaque thread a été déployé sur un cœur dédié. Pour toutes ces configurations, une seule machine virtuelle
Chapitre 5. Évaluations et résultats 0 0.2 0.4 0.6 0.8 1 1.2
FFT Histogram Kmeans Convol
Execution t
imes for Tsunamy normaliz
ed
w.r.t. times with TSAR
1 core 4 cores 8 cores 16 cores 32 cores
FIGURE5.1 – Temps d’exécution de la phase parallèle des applications sur la plateforme Tsunamy normalisés par rapport