Changes between Version 6 and Version 7 of WikiStart

Timestamp:

May 20, 2016, 2:57:58 PM (8 years ago)

Author:

alain

Comment:

--

WikiStart

@@ -1 +1 @@
 = ALMOS-MK Specification =
-
-ALMOS-MK est un système d'exploitation visant des architectures manycore de type CC-NUMA.
-On vise tout particulièrement des applications parallèles multi-thread respectant la norme POSIX.
 
 [[PageOutline]]
 
+ALMOS-MK est un système d'exploitation visant des architectures manycore à espace d'adressage partagé de type CC-NUMA telles que l'architecture TSAR,
+pouvant supporter jusqu'à 1024 coeurs. Ces architectures sont clusterisées, avec un banc mémoire physique par cluster. On vise tout particulièrement des applications parallèles multi-thread respectant la norme POSIX.
+
+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, qui contrôle les ressources locales (mémoire et périphériques). 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. Pour accéder à l'ensemble de l'espace adressage physique des architectures cibles (40 bits dans le cas de TSAR), ALMOS-MK s'exécute entièrement en adressage physique (la MMU paginée des coeurs est désactivée dès qu'on entre dans le noyau. Pour permettre  au noyau d'un cluster K d'accéder directement à la mémoire de n'importe quel autre cluster, ALMOS-MK suppose l'existence de primitives  ''remote_read'' et ''remote_write'' utilisant des adresses physiques étendues (CID / PTR) sur 64 bits (où CID  est l'index du cluster sur 32 bits, et PTR est l'adresse physique locale dans le cluster sur 32 bits). Ces primitives sont en particulier utilisées pour implémenter le mécanisme RPC, mais peuvent aussi être utilisées pour accélérer certains mécanismes critiques en performance.
+
 == 1) [wiki:replication_distribution Politique de réplication et distribution] ==
 
-Cette section définit les principes de la politique de réplication / distribution des informations sur les différents bancs mémoire de l'architecture. Cette politique vise deux objectifs : renforcer la localité, et SURTOUT minimiser la contention.
+Cette section définit les principes de la politique de réplication / distribution des informations sur les différents bancs mémoire physiques. Cette politique vise deux objectifs : renforcer la localité, et SURTOUT minimiser la contention.
  * Pour les informations read-only (segments de type CODE), on les réplique dans tous les clusters de l'architecture pour renforcer la localité des accès.
  * Pour les données non partagées (segments de type STACK) on cherche à les distribuer dans tous les clusters de l’architecture pour les rapprocher des thread utilisateurs.
@@ -17 +21 @@
 Pour minimiser la contention lors du traitement des MISS TLB, ALMOS-MK réplique les tables de page d'une application parallèle  multi-thread dans tous les clusters de l'architecture contenant au moins un thread de cette application. Cette section analyse le mécanisme de construction dynamique de ces tables de pages distribuées et partiellement répliquées, et le protocole permettant de garantir la cohérence de ces tables de pages.
  
-== 3) [wiki:processus_thread Création dynamique des processus et des thread] ==
+== 3) [wiki:processus_thread Création/destruction des processus et des thread] ==
+
+Cette section d'
 
 == 4) [wiki:thead_scheduling Ordonnancement des threads] ==
+
+Dans ALMOS, on utilise des listes doublement chaînées ''internes'' pour représenter l'ensemble des thread en attente d'une même ressource.
+Ces listes doivent être  modifiées à chaque opération d'ordonnancement qui modifie l'état d'un thread. Puisque les thread d'une même application parallèle multi-thread peuvent être distribués sur tous les clusters de l'architecture, ces files d'attentes sont donc ''trans-cluster'', ce qui est contradictoire avec la politique multi-kernel d'ALMOS-MK. Cette section analyse le problème et propose différentes solutions.