Changes between Version 19 and Version 20 of WikiStart

Timestamp:

Jul 5, 2016, 2:18:14 PM (8 years ago)

Author:

alain

Comment:

--

WikiStart

@@ -3 +3 @@
 [[PageOutline]]
 
-Ce document vise à spécifier les principes généraux de l'introduction des thread dans 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. 
-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.
+Ce document vise à spécifier 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, mais il 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. 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, 
-Les principes généraux sont décrits dans sa thèse, mais cette première version ne supporte pas les threads.
+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.
 
-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). 
+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 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.
+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). 
 
-== A) [wiki:replication_distribution Réplication et distribution des données] ==
+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. 
+
+Sur une plate-forme matérielle contenant des processeurs 32 bits, ALMOS-MK s'exécute donc entièrement en adressage physique : la MMU paginée des coeurs n'est utilisée que par le code des applications, et elle est désactivée dès qu'on entre dans le noyau. Les addresses physique 32 bits permettent donc à l'instance du noyau d'un cluster K d'accéder directement aux ressources locales. Pour accéder directement à l'espace adressage d'un autre cluster, ALMOS-MK suppose l'existence de primitives  ''remote_read'' et ''remote_write'' utilisant des adresses physiques étendues (CXY / PTR) sur 64 bits (où CID  est l'index du cluster sur 32 bits, et PTR est l'adresse physique locale dans le cluster cible sur 32 bits). Ces primitives sont en particulier utilisées pour implémenter le mécanisme RPC, mais sont aussi utilisées pour accélérer certains mécanismes 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 happé 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 à utiliser un mélange de RPCs et d'accés directs en mémoire distante (''remote_read'' et ''remote_write'').
+
+== A) [wiki:arch_info Hardware Platform Definition] ==
+
+== B) [wiki:replication_distribution Réplication et distribution des données] ==
 
 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é des accès mémoire, et SURTOUT minimiser la contention. La technique générale permettant à l'OS de contrôler le placement et la réplication des informations sur les bancs mémoire physiques est la mémoire virtuelle paginée.
 
-== B) [wiki:page_tables Réplication des tables de pages] ==
+== C) [wiki:page_tables Réplication des tables de pages] ==
 
 Pour minimiser la contention lors du traitement des MISS TLB, ALMOS-MK réplique - partiellement - 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.
  
-== C) [wiki:processus_thread Création/destruction des processus et des thread] ==
+== D) [wiki:processus_thread Création/destruction des processus et des thread] ==
 
 Toujours pour minimiser la contention ALMOS-MK réplique - partiellement - les descripteurs de processus dans tous les clusters de l'architecture contenant au moins un thread de l'application. Cette section décrit les mécanismes de création et de destruction des processus et des thread, et précise les informations contenues dans les structures de données task_t (processus) et thread_t (thread).
 
-== D) [wiki:thead_scheduling Ordonnancement des threads] ==
+== E) [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. 
 
-== E) [wiki:rpc_implementation Communication par RPC] ==
-
-== F) [wiki:arch_info Hardware Platform Definition] ==
+== F) [wiki:rpc_implementation Communication par RPC] ==
 
 == G) [wiki:io_operations Input/Output Operations] ==