Changes between Version 4 and Version 5 of rpc_implementation


Ignore:
Timestamp:
Jun 1, 2016, 6:18:54 PM (8 years ago)
Author:
alain
Comment:

--

Legend:

Unmodified
Added
Removed
Modified

  • rpc_implementation

    v4 v5  
    88Le code et les différentes structures de données utilisés pour les RPC sont définis dans les fichiers rpc.c et rpc.h. 
    99Ce code utilise une bibliothèque de fonctions d'accès à une FIFO logicielle définie dans les fichiers remote_fifo.c et remote_fifo.h.
    10 Les macros permettant la manipulation des pointeurs étendus sont définies dans le fichier type.h.
     10Les macros permettant la manipulation des pointeurs étendus sont définies dans le fichier type.h, qui est spécifique à l'architecture visée.
    1111
    12 Rappelons que l'architecture cible est décrite dans le fichier arch_info. Cette architecture est généralement clusterisée, et un cluster possède deux index:
    13  * CID est un index codé sur 32 bits. Il permet d'indexer de façon continue, de 0 à N-1, l'ensemble des clusters de l'architecture cible, définis dans le fichier arch_info. Chaque peut contenir un nombre quelconque de CPUs (y compris 0), un nombre quelconque de périphériques, et un banc mémoire physique de longueur quelconque (y compris 0). Il n'existe une instance du noyau que dans les clusters contenant au moins un CPU, un contrôleur d'interruptions, et un banc mémoire physique, ce qui n'est pas le cas de tous les clusters. 
    14  * CXY est un index codé sur 32 bits. Il représente l'extension d'adresse physique qu'il faut concaténer aux 32 bis de l'adresse locale pour accéder à la mémoire ou aux périphériques contenus dans un cluster. Dans le cas particulier de l'architecture TSAR, cet index CXY possède un format fixe qui permet d'extraire les coordonnées (X,Y) du cluster dans le mes 2D, mais ceci n'est pas vrai pour toutes les architectures visées par ALMOS. Je pense que cet index devrait lui aussi être explicitement défini, dans le fichier arch_info.
     12== 1) Hypothèses concernant l'architecture ==
    1513
    16 == 1) Point d'accès unique dans chaque cluster ==
     14L'architecture cible est généralement clusterisée, ce qui signifie que l'espace d'adressage physique est partagé par tous les CPUs, mais qu'il est partitionné entre les différents clusters. Le nombre de clusters, ainsi que le contenu de chaque cluster sont décrits dans le fichier ''arch-info''. ALMOS-MK supporte les architectures cibles respectant les contraintes suivantes:
     15 * Les adresses physiques, aussi appelées adresses étendues, sont codées sur 64 bits.
     16 * La taille maximale de l'espace adressable physique accessible dans un unique cluster est définit par un paramètre global CLUSTER_SIZE_MAX qui est une puissance de 2. Elle vaut 4 Goctets pour TSAR, mais peut posséder une valeur différente (plus grande) pour d'autres architectures. Une adresse physique est donc divisée en deux parties: le champs '''LPA''' est l'adresse locale dans un cluster, et le champs '''CXY''' est le numéro identifiant un cluster particulier.
     17 * Chaque cluster peut contenir un nombre quelconque de CPUs (y compris 0), un nombre quelconque de périphériques, et un banc mémoire physique de longueur quelconque (y compris 0).
     18Pour chaque périphérique et pour le banc mémoire, le fichier arch_info  définit l'adresse locale de base, et la longueur du segment associé.
     19 * Il existe une instance du noyau que dans tout clusters contenant au moins un CPU, un contrôleur d'interruptions, et un banc mémoire physique, ce qui n'est pas forcément le cas de tous les clusters.
     20 * Le fichier arch_info définit pour chaque cluster la valeur de son identifiant CXY.
    1721
    18 Rappelons que toutes les variables globales définies dans le segment KDATA du noyau sont répliquées dans tous les clusters. On fait - pour l'instant - l'hypothèse que deux variables de même nom peuvent avoir des valeurs différentes dans deux clusters différents, mais qu'elles sont rangées à des adresses locales (adresses 32 bits) identiques.
     22== 2) Point d'accès unique dans chaque cluster ==
    1923
    20 N'importe quel thread client s'exécutant sur n'importe quel CPU de n'importe quel cluster peut envoyer une RPC vers n'importe quel
    21 cluster serveur. Le serveur est identifié par son index CXY.
    22 Il existe donc dans chaque cluster une RPC_FIFO logicielle possédant à priori N écrivains et M lecteurs. N est le nombre de thread clients, M est le nombre de thread serveurs.
     24Rappelons que toutes les variables globales définies dans le segment KDATA du noyau sont répliquées dans tous les clusters. Deux variables de même nom peuvent avoir des valeurs différentes dans deux clusters différents, mais elles sont rangées à des adresses locales PLA identiques. Cette propriété est fondamentale, puisqu'elle permet à une instance du noyau dans un cluster K d'accéder directement  aux données globales des autres instance du noyau dans un cluster L, en fabricant une adresse physique à partir de l'adresse PLA (commune à tous les clusters) et de l'identifiant du cluster cible CXY.
     25
     26N'importe quel thread client s'exécutant sur n'importe quel CPU de n'importe quel cluster peut envoyer une RPC vers n'importe quel cluster serveur, identifié par son index CXY.
     27Il existe donc dans chaque cluster une FIFO logicielle, appelée RPC_FIFO, et possédant à priori N écrivains et M lecteurs. N est le nombre de thread clients, a priori non borné. M est le nombre de thread serveurs dont le nombre maximal dans un cluster est un paramètre de configuration.
    2328 * Pour synchroniser les accès concurrents entre écrivains, la RPC_FIFO imlémente un mécanisme de ticket garantissant que les clients pourront stocker leurs requêtes dans l'ordre d'attribution des tickets.
    24  * pour synchroniser les accès concurrents entre lecteurs, ALMOS-MK implémente un ''light-lock'', qui est un verrou non bloquant enregistrant l'identité du premier lecteur qui obtient  le verrou.
     29 * pour synchroniser les accès concurrents entre lecteurs, ALMOS-MK implémente un ''light-lock'', qui est un verrou non bloquant enregistrant l'identité du premier lecteur qui obtient  le verrou.  
    2530
    26 == 2) Traitement parallèle des RPCs ==
     31== 3) Traitement parallèle des RPCs ==
    2732
    28 Les threads chargé de traiter les RPCs  appartiennent à un ''pool'' de  thread spécialisés appelés RPC_THREAD. Un RPC_THREAD est activé sur un des CPUs du cluster serveur chaque fois que le noyau détecte que la FIFO est non-vide. Un RPC_THREAD s'exécute avec la priorité la plus élevée et se charge de traiter toutes les requêtes RPC présentes dans la RPC_FIFO
    29 avant de rendre le verrou. Si un RPC_THREAD doit s'endormir pour attendre la disponibilité d'une ressource, il libère le verrou pour permettre le traitement d'autres RPCs.
     33Les threads serveurs chargé de traiter les RPCs  appartiennent à un ''pool'' de  thread spécialisés appelés RPC_THREAD. Un RPC_THREAD est activé sur un des CPUs du cluster serveur chaque fois que le noyau détecte que la FIFO est non-vide. Un RPC_THREAD s'exécute avec la priorité la plus élevée et se charge de traiter toutes les requêtes RPC présentes dans la RPC_FIFO avant de rendre le verrou. Si un RPC_THREAD doit s'endormir pour attendre la disponibilité d'une ressource, il libère le verrou pour permettre le traitement d'autres RPCs.
    3034
    31 == 3) Format d'une RPC ==
     35== 4) Format d'une RPC ==
    3236
    3337Il existe différents types de RPC :
    … …  
    4751Les RPC non-bloquantes ne sont pas implémentées actuellement (juin 2016).
    4852
    49 == 4) Introduction d'une nouvelle RPC ==
     53== 5) Introduction d'une nouvelle RPC ==
    5054
    5155L'introduction d'un nouveau service nécessite de modifier le code de ALMOS-MK de la façon suivante opérations suivantes.