Le choix d’une ou plusieurs plateformes matérielles cibles, supportées par un noyau détermine en partie son degré de portabilité. La conception du noyau dont il est question ici le destine à supporter divers types de plateformes :
3.3. PLATES-FORMES MATÉRIELLES CIBLES 53 – Des plateformes multiprocesseurs classiques et hétérogènes.
– Des plateformes massivement parallèles many-core hétérogènes.
On peut estimer que, si le noyau capable d’hétérogénéité est également capable de remplir la tâche d’un noyau classique avec le même niveau de performances, il pourra apporter le même niveau de services lorsqu’il s’exécutera sur une plateforme hétérogène. Le projet consiste donc bien à élaborer un système d’exploitation utilisable dans des conditions réelles d’applications parallèles qui s’exé-cutent sur des architectures multiprocesseurs, et non seulement un noyau capable de mener à bien les expérimentations propres au support natif de l’hétérogénéité.
Le choix de portage sur des plateformes matérielles bien différentes doit garantir la robustesse de l’abstraction du matériel mise en place, permettant ainsi de traiter le problème du développement du noyau avec toutes les contraintes réelles, sans se contenter d’un sous-ensemble matériel plus simple. La couche d’abstraction du matériel dans le code du noyau va plus loin que celle que l’on rencontre habituellement dans les autres noyaux : le code spécifique à la plateforme est séparé du code spéci-fique au microprocesseur.
Si les plateformes multiprocesseurs homogènes classiques sont disponibles facilement (PC à base de multiprocesseurs x86), ce n’est pas le cas des plateformes multiprocesseurs hétérogènes à mémoire partagée.
Les plateformes hétérogènes utilisées pour les expérimentations sont mises en place grâce au projet SoCLib, bibliothèque de composants en SystemC permettant l’élaboration d’architectures multi-core et many-core proposant de nombreux types de coeurs de processeurs, de périphériques et de compo-sants d’interconnexion. Cette bibliothèque permet de créer des simulateurs de toutes sortes dont les caractéristiques sont paramétrables finement, elle dispose de modules permettant le debug logiciel et matériel. Elle reste modifiable au besoin, comme tout logiciel libre.
SoCLibest une bibliothèque de simulation utilisée en microélectronique, la modélisation de la plu-part des composants reflète leur comportement au niveau électronique. La simulation est donc beau-coup plus fine que celle proposée par les solutions d’émulation et de virtualisation telles que QEmu, qui favorisent les performances au détriment de la précision. Certains composants SoCLib sont éga-lement disponibles en description matérielle Vhdl pour l’exécution sur puce FPGA.
54 CHAPITRE 3. SOLUTIONS DE PRINCIPE La figure 3.4 expose une plateforme multiprocesseur hétérogène simple utilisée pour la mise au point du noyau. Les processeurs d’architecture différente s’interfacent sur l’interconnect qui relie tous les composants de la plateforme. Les composants de RAM et de ROM permettent respectivement de stocker les données et le code du système.
On remarquera que les plateformes SoCLib utilisent une architecture moderne et des processeurs RISC. Du point de vue logiciel, elles sont très différentes des plateformes Ibm-Pc, basées sur une architecture rétrocompatible de plusieurs décennies et sur des processeurs CISC. Cette grande diffé-rence a été volontairement choisie pour contraindre la latitude de conception et mettre en défaut tout problème de non-généricité de la couche d’abstraction du matériel du noyau.
Pour garantir la portabilité, la mise au point du noyau s’est effectuée en premier lieu sur des pla-teformes non hétérogènes comme des stations de travail multiprocesseurs, des prototypes virtuels SoCLibà architecture homogène ou encore des cartes à base de microcontrôleurs.
3.3.1 Accès atomiques
Les accès atomiques à la mémoire sont généralement implémentés par des mécanismes relevant à la fois du processeur et de la plateforme. Au niveau processeur, il existe différents mécanismes liés à différentes approches :
– Les instructions de type Read/Modify/Write réalisent un accès atomique. Elles se basent sur la possibilité d’obtenir un accès exclusif à la mémoire. Seules les opérations prévues par le jeu d’instructions du processeur peuvent être réalisées.
– Les paires d’instructions de type Linked Load et Store Conditional (LL/SC) tentent une paire d’accès mémoire et testent l’atomicité effective de l’opération. Lorsque l’accès n’a pas pu être réalisé de manière atomique, l’écriture échoue et il faut relancer la séquence complète. Cette approche permet de réaliser n’importe quelle opération de manière atomique.
La première approche fonctionne sur les plateformes matérielles où les processeurs sont proches de la mémoire et où il est envisageable de bloquer l’accès à la mémoire à la demande d’un seul proces-seur. La seconde permet une plus grande souplesse car elle n’impose pas d’obtenir une exclusivité totale des accès à la mémoire en bloquant le reste de la plateforme.
La seconde approche, plus générique, est implémentée dans les processeurs RISC récents. Dans un système hétérogène, le même comportement est attendu par les différents processeurs vis-à-vis de la mémoire. C’est donc ce mécanisme plus souple et plus générique qui convient le mieux et qui est retenu pour le développement du noyau.
Les plateformes matérielles basées sur SoCLib permettent d’obtenir ce comportement unifié de type LL/SC.
On peut remarquer que certains processeurs ne proposant pas les instructions de lecture et écriture conditionnelles appropriées peuvent tout de même être exploités grâce à l’adjonction d’un automate câblé qui émule le comportement de cette approche pour les instructions d’accès atomiques.