Filip Novotny - Implémentation d'un HAL pour processeur Cell - resultats

De Ensiwiki
Aller à : navigation, rechercher


Implémentation d'un HAL pour processeur Cell

Labo SLS
Equipe TIMA
Encadrants Paul.Amblard@imag.fr,Frederic.Petrot@imag.fr

Etudiant

Filip Novotny

Introduction

Notre époque n'est plus autant celle de l'augmentation du nombre de transistors que celle de la croissance du nombre de processeurs. Le processeur Cell s'inscrit particulièrement bien dans cette optique grâce à sa structure à neuf coeurs.

Il s'agit d'une architecture assez méconnue du grand public mais pourtant largement utilisée: c'est entre autres le processeur de la playstation 3. Il est entretenu par IBM, Sony et Toshiba.

Comme pour tout processeur, il est intéressant d'y faire tourner un système d'exploitation. Classiquement, ce dernier n'interagit pas directement avec le processeur mais l'exploite grâce à une couche d'abstraction appelée le HAL. C'est pour cette raison qu'un système d'exploitation (comme Linux) peut fonctionner sur diverses architectures (Intel, MIPS, SPARC, PowerPC,...) sans que l'on ait pour autant besoin de changer son code.

A l'heure actuelle, il n'existe pas d'interface entre un système d'exploitation et le processeur Cell qui permette de tirer profit de ses particularités.

Le but de ce TER sera d'implémenter une couche d'abstraction du matériel permettant de faire tourner un système général sur le processeur Cell.

Éléments de pré requis

Le Cell

Le processeur Cell est hybride: il est composé d'un processeur classique le PPE, et de 8 processeurs spécialisés pour le calcul: les SPEs. Cell.png

Le PPE est un PowerPC 64bit classique permettant de faire fonctionner un système d'exploitation (gestion des interruptions, de la mémoire paginée...). Contrairement aux architectures intel, le PPE possède une architecture RISC avec 32 registres de 64 bits chacun.

L'accès à la mémoire centrale se fait de manière directe comme c'est le cas pour un Pentium. Le PPE possède évidemment des caches de niveau 1 et 2.

Les SPEs sont avant tout des unités de calcul. Possédant 128 registres de 128 bits chacun, ils peuvent effectuer des opérations vectorielles au niveau assembleur. Ils ne sont pas prévus pour supporter un système d'exploitation. Ils ne possèdent avant tout pas d'accès direct à la mémoire. Pour ce faire, ils doivent passer par des requêtes DMA. De plus, il n'y a aucune notion de cache mais un Local Store (ou LS, mémoire rapide de 256Ko accessible uniquement par le SPE).

Vocabulaire

Architecture: Il s'agit de la description matérielle du processeur. Ici le Cell avec son jeu d'instructions.

Environnement hardware: Il s'agit de l'ensemble des conventions de branchement du processeur dans une machine avec les périphériques extérieurs. Dans ce TER cet l'environnement hardware est décrit dans le simulateur d'IBM utilisé tout au long du stage.

Travail réalisé

Xavier Guérin de l'équipe TIMA-SLS a développé un système d'exploitation (nommé DNA) fonctionnant entièrement au-dessus d'une API entièrement spécifiée. Cette API a ensuite été implémentée pour plusieurs processeurs. Mon travail a consisté à implanter cette API pour le Cell. La spécification complète de l'API est disponible en annexe.

La sortie graphique

Un système d'exploitation étant interractif, la sortie graphique est un élément vital pour communiquer avec l'utilisateur.

Dans cette étape il s'agissait de prendre en compte l'environnement hardware du Cell et trouver un moyen de l'abstraire. De cette manière, le HAL permet une sortie vers un contrôleur graphique (à condition que celui-ci existe) sur n'importe quelle machine.

Il fallait également trouver une solution pour faire ceci tout en restant conforme à l'API (les fonctions d'entrée sortie étant de la forme CPU_READ(adresse), CPU_WRITE(adresse)). La solution proposée a été de maper la sortie en mémoire.

Le context-switch

Dans le cas de plusieurs threads, il est important de pouvoir changer de contexte.

L'API fournit certaines primitives qu'il s'agit d'implanter. Il s'agit de CPU_CONTEXT_LOAD(contexte) et CPU_CONTEXT_SAVE(context). Classiquement, CPU_CONTEXT_LOAD est la première procédure appelée lors d'un changement de contexte et CPU_CONTEXT_SAVE la dernière.

Cependant, la spécification mène à un problème sans issue: Dans certains cas, le passage du paramètre contexte mène à la perte du contexte d'exécution et donc compromet entièrement l'aspect multitâche.

Ce problème disparaît lorsqu'on change la spécification (appel de CPU_CONTEXT_LOAD sans passage de paramètre) mais ceci impliquerait une modification du système DNA. Une solution temporaire est explicitée dans le rapport.

La gestion multiprocesseur

Pour gérer l'interaction PPE/SPE au niveau du HAL, j'ai proposée une solution mettant en place une plage mémoire partagée entre ces processeurs afin d'abstraire les différences d'accès à la mémoire (direct pour PPE et DMA pour SPE). A titre de démonstration, voici un programme de ping/pong entre le PPE et les 8 SPE.

Son fonctionnement est le suivant:

- Le PPE effectue un ping vers chacun des 8 SPE et attend.

- A la réception d'un ping chacun des SPE répond par un pong.

- A la réception d'un pong d'un SPE donné, le PPE réexpédie un ping à ce SPE.

Voici le résultat dans le simulateur d'un Cell:

Pingpong.png

Conclusion

La couche d'abstraction implémentée dans ce TER permet effectivement de lancer des applications au dessus du HAL. Cependant des améliorations sont envisageable notemment:

  • Une solution plus élégante pour la communication PPE/SPE que la mémoire partagée (utiliser un système de mailbox par exemple)
  • Trouver un meilleur compromis pour le problème du context-switch
  • Songer à abstraire une partie des traitants d'interruptions dans le HAL (ce qui ouvrirait d'autres possibilités pour la résolution du problème du context-switch).

Ce travail a également mis en évidence que le HAL Cell est très proche du HAL PPE (adapté pour lancer un système). Je pense cependant que les différences entre les deux sont suffisamment conséquentes pour justifier son développement.

Références

  • Michael Gschwind,David Erb, Sid Manning, Mark Nutter : An Open Source Environment for Cell Broadband Engine System Software, 2007
  • P. Bohrer : Mambo, A Full System Simulator for the PowerPC Architecture, 2004
  • Mendel Rosenblum, Edouard Bugnion, Scott Devine, Stephen A. Herrod : Using the SimOS Machine Simulator to Study Complex Computer Systems, 1997
  • Cédric augonnet : An introduction to IBM Cell Processor, 2007
  • Guillaume Rincé : Microprocesseur powerPC 750
  • Documentation IBM :
    • IBM Full-System Simulator User's Guide, 2007
    • Cell Broadband Engine Registers, 2007
    • Software Development Kit 2.1 Programmer’s Guide, 2007

Documents additionnels

Rapport: Media:novotny_rapport.pdf

Annexes: Media:novotny_annexes.pdf