ALMOS : Support de l'architecture TSAR-40b

Objectifs du stage

ALMOS est un système d’exploitation UNIX-like (thèse LIP6 de Ghassan Almaless) pour supporter les architectures manycores à mémoire partagée et caches cohérents. ALMOS a été conçu sur l’architecture manycore TSAR qui permet à plusieurs centaines de coeurs de processeur 32-bits à faible empreinte énergétique de se partager un espace de mémoire physique de 1 Tera-octets. Les premières versions de TSAR utilisées par ALMOS lors de sa conception ne proposaient qu'un adressage physique 32-bits (4 Go). Désormais, TSAR gère complètement l'adressage physique 40-bits (1 To). Le but de ce stage est de modifier le noyau d'ALMOS pour permettre la gestion de l'extension de la mémoire physique.

Description

Comme dans les noyaux UNIX-like, le noyau actuel d’ALMOS divise l’espace d'adressage virtuel des processus en deux parties. La première partie (1 ou 2 Go) est réservée au noyau. Cette partie est commune à tous les processus, la seconde partie (3 ou 2 Go) est propre à chaque processus. 

La partie de l'espace virtuel d'un processus réservée au noyau contient les structures de gestion des processus et des structures pour la gestion des ressources communes comme les pages de mémoire physique et le système de fichiers. Dans un manycore à plusieurs centaines de coeurs et une mémoire physique de 1 Tera-octets, la taille de ces structures communes dépasse de beaucoup 1 ou même 2 Go. 

Lorsque la taille de la mémoire physique dépasse la taille de la mémoire virtuelle, il y a trois possibilités pour agrandir la mémoire accessible : 

1. La première possibilité est assez classique, elle consiste à étendre l'espace virtuel du noyau par un mapping temporaire. Dans cette solution, les entrées de la table des pages du noyau sont divisées en deux parties. La première partie est fixe et permet de mapper les structures qui sont continuellement accédées par le noyau, tel que le code du noyau. La seconde partie est dynamique est permet d’accéder aux données qui moins fréquemment utilisées ou dont la taille est très importante, tel que les caches du système de fichiers. L’accès à ces données se fait en allouant dynamiquement et temporairement une entrée dans la table. On obtient ainsi une adresse virtuelle qui pointe temporairement vers la donnée à accéder.
    
2. La deuxième possibilité consiste à utiliser des primitives spécifiques à l'architecture TSAR permettant au noyau de court-circuiter l'adressage virtuel et d'accéder directement à l'espace physique.  Dans cette solution le noyau utilise son espace virtuel pour y stocker toutes les structures sauf les très grandes structures qui sont stockées dans l'espace physique.
    
3. La troisième possibilité est radicale, elle consiste à faire fonctionner le noyau directement en espace physique. L’architecture TSAR est composée de clusters qui sont des ensembles de coeurs (généralement 4) disposant de leur propre banc mémoire de 4 Go gérant un segment d'adresses de la mémoire physique (aspect NUMA de l’architecture). Cette troisième possibilité consiste à ce que chaque coeur accède par défaut à sa mémoire locale et utilise des primitives spécifiques à TSAR pour accéder à la mémoire des autres clusters (accès distants). Ce dernier type d’accès étant plus lent, le noyau d'ALMOS organise ces structures en les répliquant afin d’utiliser très majoritairement la mémoire locale. Dans ce cas, il faut que le noyau assure la cohérence des réplicas. Pour les structures qui ne peuvent être répliquées parce que trop grandes ou dont le maintient de  cohérence est coûteux, le noyau les distribue.

La première possibilité est coûteuse et complexe. Coûteuse car chaque mapping dynamique peut coûter plusieurs centaines de cycles. Complexe car il faut gérer finement les pointeurs qui peuvent être mappés ou non mappés. La seconde possibilité moins coûteuses mais garde la même complexité que  la première (les pointeurs peuvent être virtuels ou physiques). Même si cette seconde possibilité a été partiellement (en raison de la complexité) implémentée lors d'un stage précédent. 

L'objectif du stage consiste à expérimenter la troisième possibilité. A titre d'exemple, lorsque le noyau crée un processus, il alloue localement une structure task qui contient toutes les ressources nécessaires aux threads du processus et en particulier la table des pages de son espace virtuel. Lorsque le noyau crée un thread sur un cluster différent, il doit cloner la structure task. Le noyau doit alors gérer la cohérence de toutes les structures task d'un même processus.
Déroulement

Déroulement 

Le stage se déroulera en quatre étapes. La première est l'apprentissage de l'architecture matérielle TSAR, du système d'exploitation ALMOS et des outils de protoypage. La deuxième  est la compréhension des problèmes, la proposition des solutions de principes (entre réplication, distribution et accès direct) et des moyens de validation. Une soutenance achèvera cette étape. La troisième est l'implémentation des solutions et la quatrième est l'évaluation des performances. 

Le travail du stagiaire se fera en concertation avec Mohamed Karaoui (actuellement en thèse sur le système de fichiers scalable pour ALMOS) qui a déjà commencé à proposer des solutions pour cette troisième possibilité. 

Prérequis

Il est fortement souhaitable que le stagiaire ait de solides connaissances en C, des compétences en système d'exploitation et de bonnes notions d'architecture matérielle.

Bibliographie

 

• Projet ALMOS : http://www.almos.fr/
• Ghassan Almaless, "Operating System Design and Implementation for Single-Chip cc-NUMA Manycore", PhD Thesis, février 2014.
• TSAR : https://tmp-soc.lip6.fr/trac/tsar