ALMOS-MKH Specification

Ce document décrit les principes généraux de ALMOS-MK, qui est un système d'exploitation visant des architectures manycore à espace d'adressage partagé de type CC-NUMA (Cache Cohérent, Non Uniforme Memory Access), telles que l'architecture TSAR, qui peut supporter jusqu'à 1024 coeurs MIPS 32 bits. ALMOS-MK vise également des architectures multi-coeurs INTEL/AMD utilisant des coeurs I86 64 bits.

Les architectures visées sont supposées clusterisées, avec un ou plusieurs coeur et un banc mémoire physique par cluster. On vise tout particulièrement des applications parallèles multi-thread respectant la norme POSIX.

Le système ALMOS-MK est l'héritier du système ALMOS, développé par Ghassan Almaless, et les principes généraux du système ALMOS sont décrits dans sa thèse.

La première version de ALMOS-MK, et en particulier le système de fichiers distribué et le mécanisme de communication par RPC ont été développés par Mohamed Karaoui, et les principes généraux de l'approche "Multi-Kernel proposée sont décrits dans sa thèse.

Pour garantir le passage à l'échelle, et favoriser la distribution des services système, ALMOS-MK repose sur l'approche Multi-Kernel, dans laquelle il existe une instance du noyau dans chaque cluster de l'architecture. Celle-ci contrôle les ressources locales (mémoire et coeurs de calcul). Ces multiples instances coopèrent entre elles pour donner aux applications l'image d'un unique système contrôlant l'ensemble des ressources. Elles communiquent entre elles sur le modèle client /serveur en utilisant des RPCs (Remote Procédure Call).

Pour réduire la consommation énergétique, ALMOS-MK supporte des architectures utilisant des processeurs 32 bits. Dans ce cas, chaque cluster possède un espace d'adressage physique 32 bits, et les adresses physiques locales (internes à un cluster) sont donc codées sur 32 bits. Pour accéder à l'espace adressage physique des autres clusters, ALMOS-MK utilise des adresses physiques globales codées sur 64 bits. A titre d'exemple l'espace physique de l'architecture TSAR utilise 40 bits, et les 8 bits de poids fort définissent donc le numéro du cluster cible. ALMOS-MK distingue donc explicitement deux types d'accès:

• les accès locaux (internes à un cluster) utilisent des adresses 32 bits.
• les accès distants (vers un autre cluster) utilisent des adresses 64 bits.

Sur une plate-forme matérielle contenant des processeurs 32 bits, ALMOS-MK s'exécute entièrement en adressage physique : la MMU paginée des coeurs n'est utilisée que par le code des applications. Elle est désactivée dès qu'on entre dans le noyau, et elle est réactivée quand on en sort. Les addresses physique 32 bits permettent à l'instance du noyau d'un cluster K d'accéder directement à toutes les ressource (mémoire ou périphériques) locales. Pour accéder directement à l'espace adressage d'un autre cluster, ALMOS-MK utilise des primitives remote_read et remote_write utilisant des adresses physiques étendues (CXY / PTR) sur 64 bits. CXY est l'identifiant du cluster cible, sur 32 bits, et PTR est l'adresse physique locale dans le cluster cible sur 32 bits. Ces primitives sont utilisées pour implémenter le mécanisme RPC, mais sont aussi utilisées pour accélérer certains accès aux structures de données distribuées du noyau, qui sont critiques en performance.

Sur une plate-forme matérielle contenant des processeurs 64 bits, il n'est plus nécessaire d'exécuter le noyau en adressage physique, puisque l'ensemble de l'espace physique peut être mappé dans l'espace virtuel 64 bits. Néanmoins pour renforcer la localité des accès tout en minimisant les points de contention, ALMOS-MK continue à distinguer entre accès locaux et accès distants, et le modèle de communication entre instances du noyau n'est pas modifié.

Dans les deux cas, les communications entre instances du noyau sont donc implémentées par un mélange de RPCs (sur le modèle client/serveur), et d'accès directs en mémoire distante (quand cela est utile pour les performances). C'est cette approche hybride qui constitue la principale originalité de ALMOS-MK.

A) Hardware Platform Definition

This section describes the general assumptions made by ALMOS-MK regarding the hardware architecture, and the mechanism to configure ALMOS-MK for a given target architecture.

B) Process & threads creation/destruction

ALMOS-MK supports the POSIX threads API. In order to avoid contention in massively multi-threaded applications, ALMOS-MK replicates the user process descriptors in all clusters containing threads of this process. This section describes the mechanisms for process and thread creation / destruction.

C) Data replication & distribution policy

This section describes the general policy for replication/distribution of the informations on the various physical memory banks. We have two main goals: enforce memory access locality, and avoid contention when several threads access simultaneously the same information. To control the placement and the replication of the physical memory banks, the kernel uses the paged virtual memory.

D) GPT & VSL implementation

To avoid contention when several threads access the same page table to handle TLB miss, ALMOS-MK replicates the page tables. For each multi-threaded user application P, the Generic Page Table (GPT), and the Virtual Segments List (VSL) are replicated in each cluster K containing at least one thread of the application. According to the "on-demand paging" principle, these replicated structures GPT(K,P) and VSL(K,P) are dynamically updated when page faults are detected. This section describes this building mechanism and the coherence protocol required by these multiple copies.

E) Trans-Cluster lists of threads

ALMOS_MK uses double linked list to represent a set of threads. For example ALMOS-MK must build the set of all threads waiting to access a given resource, such as a given peripheral device. As these threads can be running on any cluster, these linked lists are trans-cluster, and requires specifictechnics in a multi kernel OS, where each kernel instance is handling only resources localized in a single cluster.

F) Communication par RPC

G) Input/Output Operations

H) Boot procedure

This section describes the ALMOS-MK boot procedure.

I) Ordonnanceur