Adaptation multicoeur du modèle de partitionnement spatial

Les modèles de programmation parallèle à mémoire partagée utilisent des variables partagées entre les coeurs pour communiquer. Ces variables partagées sont accédées par les fils d’exé- cutions à la même adresse physique, en alternance. Des protocoles de synchronisation sont utilisés pour éviter l’accès non atomique à ces zones de mémoire partagée.

Par définition, il est interdit de partager des zones de mémoire entre les différentes partitions exploitées par un noyau de partitionnement robuste. Cette restriction améliore la sûreté dans

109

les systèmes monocoeurs, mais elle va directement à l’encontre des modèles de programma- tion parallèle à mémoire partagée. Nous avons adapté le modèle de partitionnement spatial de XtratuM de manière à ne permettre le partage de mémoire qu’à des partitions faisant par- tie d’un même groupe. Dans notre modèle, on considère les partages de mémoire entre les groupes au lieu d’entre les partitions.

Nous préciserons maintenant la construction et l’utilisation des groupes de partitions que nous avons mentionnées à quelques reprises dans les derniers chapitres. Le groupe de partitions est le mécanisme principal développé pour permettre l’exploitation du parallélisme tout en respectant l’esprit des contraintes d’isolation spatiale entre les partitions dans un noyau de partitionnement robuste.

Un groupe de partitions est un ensemble logique de partitions qui partagent des zones de mémoire et qui s’exécutent sur des coeurs mutuellement exclusifs. Les partitions membres d’un groupe parallèle sont définies de la même manière que les partitions séquentielles. En fait, les partitions séquentielles sont chacune allouées à un groupe ne contenant qu’une seule partition. L’image d’une partition contient le code (segment « .text ») ainsi que les données globales (segments « .bss » et « .data ») du binaire de la partition. Toutes les partitions d’un groupe doivent partager la même image de partition, qui est chargée dans un espace d’adresse physique commun. Cependant, chaque partition possède sa propre pile locale. En plus de l’image de partition, des zones de données partagées additionnelles peuvent être définies pour permettre la création de tampons alloués lors de l’initialisation des partitions.

Les groupes sont détectés implicitement à partir d’un ensemble de règles mises en oeuvre dans l’outil xmcparser. Lors de la compilation du PCS, xmcparser crée des groupes en fonc- tion des assignations de zones de mémoire des partitions. Si les règles de regroupement sont respectées par plusieurs partitions assignées à des coeurs différents, les règles proscrivant les partages de mémoire entre les partitions sont relaxées pour les membres d’un même groupe.

Chacune des partitions doit être composée de zones de mémoire virtuelle appartenant à des zones de mémoire physique dans le PCS. Les attributs d’une zone de mémoire virtuelle déter- minent son type et ses permissions d’accès. Les adresses virtuelles et réelles (physiques) de toutes les zones de mémoire virtuelle doivent être identiques. Ces restrictions sont imposées afin de faciliter la validation du PCS et de simplifier le débogage des applications.

Tableau 4.1 Types de zones de mémoire virtuelle dans XtratuM-PPC

Type Caractéristiques

« code » Utilisé pour le code exécutable en lecture seule.

« io » Utilisé pour les zones d’entrées/sorties avec dérivation des caches. « data » Utilisé pour les données en lecture/écriture.

« stack » Utilisé pour les piles.

Nous avons développé quatre types de zones de mémoire virtuelle, dont les caractéristiques sont présentées au tableau 4.1. Chaque type correspond à une configuration différente du PTD ou du BTD associé dans le MMU. Ces types de zones de mémoire sont utilisés pour la dé- tection des groupes de partitions parallèles dans xmcparser. Ils sont aussi utilisés dans le noyau pour la configuration du MMU lors du chargement des partitions.

Une image de partition, peu importe qu’elle fasse partie d’un groupe parallèle, doit respecter les règles suivantes :

1. Elle doit posséder au moins une zone « code », une zone « data » et une zone « stack ». 2. Ses zones virtuelles doivent être assignées à une même région de mémoire physique. 3. Les zones de type « code », « data » et « stack » doivent se succéder respectivement dans

cet ordre.

Lorsque l’outil xmcparser détecte plusieurs partitions sur des coeurs différents qui par- tagent la même image de partition, à l’exception des zones de pile (« stack »), ces dernières sont assignées à un même groupe. Lors de la validation des contraintes de partitionnement

111

par xmcparser, tels que le chevauchement de zones de mémoire, les partitions d’un même groupe peuvent partager des zones de type « code » et « data » librement sans produire d’erreur.

Pour mieux illustrer l’implémentation du partitionnement spatial multicoeur, nous avons construit un exemple à deux coeurs représentatif de partitions d’un groupe parallèle. Dans cet exemple, deux partitions font partie d’un groupe qui possède les caractéristiques suivantes :

• une image de partition de 512 ko, composée de :

– une zone partagée de type « code » composée d’un BTD de 256 ko ; – une zone partagée de type « data » composée d’un BTD de 128 ko ;

– une zone de pile (type « stack ») composée de deux PTD de 4 ko pour chaque coeur. • une région additionnelle de données de 512 ko composée d’un BTD de 512 ko.

La carte mémoire de cet exemple est présentée à la figure 4.8. Dans cet exemple, toutes les partitions faisant partie du groupe parallèle partagent une même région « code » et « data ». Les piles sont cependant uniques à chaque coeur et sont identifiées dans la figure par « Pile CPU0 » et « Pile CPU1 ». La zone de données additionnelles de 512 ko est aussi partagée par toutes les partitions du groupe et pourrait servir à entreposer des données de traitement. On remarque que les règles énoncées précédemment pour les groupes de partitions parallèles sont respectées.

Comme dans le cas du partitionnement temporel multicoeur, le partitionnement spatial est réalisé localement par l’instance du noyau sur chaque coeur. Les fautes d’accès mémoire sont détectées localement par le MMU de chaque coeur. Le module de partitionnement spatial du noyau ne dépend pas de caractéristiques particulières des processeurs multicoeurs. Son im- plémentation est entièrement locale et séquentielle, sans partage de données entre les coeurs. Outre la présence d’un support complet de protection mémoire par MMU, il n’y a aucune dif- férence logique au niveau du noyau entre la version originale monocoeur de XtratuM et notre

« code » « data » « stack »→ « data »

Pile CPU 0 Pile CPU 1

Code de l’image Données de l’image

Piles de

l’image Zone de données partagées

Légende Espace vide

Espace utilisé 8 ko_{8 ko}

BTD 256 ko BTD 128 ko 4× PTD 4 ko = 16 ko BTD 512 ko Région de l’image de la partition Région additionnelle

Figure 4.8 Exemple d’allocation de zones de mémoire virtuelle pour un groupe de partitions parallèles sur deux coeurs

version multicoeur. Le reste des caractéristiques qui permettent l’application d’un modèle de partitionnement spatial multicoeur découlent entièrement de conventions appliquées par l’ou- til xmcparser lors de la compilation et de la validation du plan de configuration du système. L’exécution d’une copie locale du noyau sur chaque coeur suffit pour permettre l’application de tous les types de plans d’exécution parallèles que nous désirons supporter.

Finalement, nous devons mentionner que notre version multicoeur avec support MMU de XtratuM ne permet pas l’exploitation directe de la mémoire virtuelle par le système d’ex- ploitation de partition. Puisque nous n’avons pas virtualisé le support du MMU de sorte à le rendre disponible aux partitions, les systèmes d’exploitation de partitions sont limités à l’utilisation d’un modèle de mémoire réelle. L’implémentation dans l’hyperviseur d’un MMU virtuel, comme cela est fait par exemple dans Xen [14], aurait grandement complexifié l’implé- mentation alors qu’il ne s’agissait pas d’un besoin primaire. Plusieurs des cas d’utilisation de support MMU dans les systèmes d’exploitation, incluant la protection de la mémoire, peuvent cependant être émulés avec des allocations statiques de PTD et BTD dans le plan de configu- ration du système.

113