Changes between Version 21 and Version 22 of rpc_implementation


Ignore:
Timestamp:
Oct 6, 2017, 8:37:40 PM (5 years ago)
Author:
alain
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • rpc_implementation

    v21 v22  
    99
    1010The target architecture is clusterised: the physical address space is shared by all cores, but it is physically distributed, with one physical memory bank per cluster, with the following assumptions:
    11  * 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. ALMOS-MKH supporte les architectures cibles respectant les contraintes suivantes:
    12  * Les adresses physiques, aussi appelées adresses étendues, sont codées sur 64 bits.
    13  * La taille maximale de l'espace adressable physique accessible dans un unique cluster est définit par le paramètre global CONFIG_CLUSTER_SPAN qui est une puissance de 2. Elle vaut 4 Goctets pour TSAR, mais peut posséder une valeur plus grande pour d'autres architectures. Une adresse physique est donc divisée en deux parties: le champs '''LPA''' est l'adresse physique locale dans un cluster, et le champs '''CXY''' est le numéro identifiant un cluster particulier.
    14  * 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). Pour 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é.
    15  * Il existe une instance du noyau dans tout cluster 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.
     11 * The physical addresses - also called extended adresses - are 64 bits encoded. Therefore the global physical address space cannot be larger than 2**64 bytes.
     12 * The max size of the physical address space in a single cluster is defined by the CONFIG_CLUSTER_SPAN configuration parameter, that must be a power of 2. It is  4 Gbytes for the TSAR architecture, but it can be larger for Intel based architectures.
     13 * For a given architecture, the physical address is therefore split in two fixed size fields : The '''LPA''' field (Local Physical Adress) contains the LSB bits, and defines the physical address inside a given cluster. The '''CXY''' field (Cluster Identifier Index) contains the MSB bits, and directly identifies the cluster.
     14 * Each cluster can contain several cores (including 0), several peripherals, and a physical memory bank of any size (including 0 bytes). This is defined in the ''arch_info'' file.
     15 * There is one kernel instance in each cluster containing at least one core, one interrupt contrôler, and one physical memory bank.
    1616
     17== 2) Unique access point in cluster ==
    1718
    18 == 2) Point d'accès unique dans chaque cluster ==
     19ALMOS-MKH replicates the KDATA segment (containing the kernel global variables) in all segments, using the same LPA (Local Physical Address) for the KDATA segment base.
     20Therefore, in two different clusters, a given global variable, identified by its LPA can have different values. This feature is used by by ALMOS-MKH to allow a kernel instance in a cluster K to access the global variables of another kernel instance in cluster K', building a physical address by concatenation of a given LPA with the CXY cluster identifier for the target cluster K'.
    1921
    20 Dans ALMOS_MKH, 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 LPA 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 LPA (commune à tous les clusters) et de l'identifiant CXY du cluster cible.
     22ALMOS-MKH defines a software RPC_FIFO, implemented as a global variable. This RPC_FIFO, is a member of the "cluster_manager" structure, that is replicated in all clusters containing a kernel instance. It is used by client threads to register RPC requests to a given target cluster K.
    2123
    22 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 cluster serveur, identifié par son index CXY.
     24This RPC_FIFO has a large number (N) of writers, an a small number (M) of readers:
     25 * N is the number of client threads (practically unbounded), running in any cluster, that can send a RPC request to a given target cluster K. To synchronize these multiple client threads, the RPC FIFO implements a "ticket based" policy, defining a ''first arrived / first served'' priority to register a new request into FIFO.
     26 * M is the number of server threads, (bounded by the CONFIG_RPC_THREAD_MAX parameter), created in cluster K to handle the RPC requests. To synchronize these multiple  server threads (called RPC threads), the RPC FIFO implements a "light lock", that is a non blocking lock: only one RPC thread at a given time can take the lock and become the FIFO owner. This FIFO owner is in charge of handling pending RPC requests. When the light lock is taken by RPC thread T, another RPC thread T' failing to take the lock simply deschedules.
     27 
     28== 3) Client blocking policy ==
    2329
    24 Il existe dans chaque cluster une FIFO logicielle, appelée "rpc_fifo", qui est une variable globale, membre de la structure "cluster_manager" définie dans chaque cluster.
    25 Cette FIFO possède 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 défini par le paramètre de configuration CONFIG_RPC_THREAD_MAX.
    26  * 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.
    27  * 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. Ce verrou est non bloquant, puisque tout échec signifie qu'un autre lecteur a gagné, et que le gagnant se charge d'effectuer le traitement. 
     30All RPCs are blocking for the client thread. ALMOS-MKH implements a descheduling policy: the client thread blocks on the specific RPC_WAIT condition, and deschedules.
     31It is unblocked by the RPC thread, when the RPC is completed.
    2832
    29 == 3) Traitement parallèle des RPCs ==
     33In order to reduce the RPC latency for the client thread, the RPC thread completing an RPC request send an IPI to force a scheduling on the core running the client thread.
     34If there is no other thread with an higher priority, the client thread can be immediately rescheduled
    3035
    31 Dans chaque cluster, les threads serveurs chargés de traiter les RPCs  appartiennent à un ''pool'' de  threads spécialisés appelés RPC_THREAD. Un RPC_THREAD du cluster serveur est activé chaque fois que l'O.S. s'exécutant sur un coeur quelconque du cluster détecte que la RPC_FIFO est non-vide, et qu'il parvient à acquérir la propriété de la FIFO grâce au mécanisme de ''light-lock''. Si la liste des RPC_THREADs oisifs est vide, un nouveau RPC thread est dynamiquement créé. Le RPC_THREAD s'exécute alors 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 libérer la FIFO. Si un RPC_THREAD doit attendre la disponibilité d'une ressource, il se bloque sur la condition particulière associée à cette ressource, et déclenche une opération d'ordonnancement, après avoir libéré la RPC_FIFO, pour permettre le traitement d'autres RPCs. Il y a donc à tout instant au plus un RPC_THREAD propriétaire  de la RPC_FIFO, et possédant le droit de consommer une nouvelle RPC. Mais il peut exister plusieurs RPC_THREAD actifs, traitant chacun une RPC en cours de traitement. Lorsqu'un RPC thread a terminé l'exécution d'un service, il le signale au thread client, et cesse son exécution: Si le nombre courant de RPC_THREADs est inférieur au paramètre CONFIG_RPC_THREAD_MAX, il s'enregistre dans la liste des RPC_THREADs oisifs et se désactive; sinon, il se suicide.
     36== 3) Parallel RPC requests handling ==
    3237
    33 L'activation/désactivation d'un RPC_THREAD est implémentée par un bit particulier du vecteur de bit représentant les causes de blocages d'un thread.
     38Each cluster contains a pool of RPC threads, in charge of RPC requests handling. As the scheduler takes into account the thread type, it can take into account the RPC_FIFO state for the RPC threads. AN RPC thread is not runnable when the RPC_FIFO is empty. When the RPC_FIFO is not empty, only one RPC thread has the FIFO ownership and can consume RPC requests from the FIFO.
    3439
    35 == 4) Format d'une RPC ==
     40Nevertheless, ALMOS-MKH supports several RPC threads (up to CONFIG_RPC_THREAD_MAX per cluster), because a given RPC thread T handling a given request can block, waiting for a shared resource, such as a peripheral. In that case, the blocked RPC thread T releases the FIFO ownership before blocking and descheduling. This RPC thread T will complete the current RPC request when the blocking condition is solved, and the thread T is rescheduled. If the RPC FIFO is not empty, another RPC thread T' will be scheduled to handle the pending RPC requests. If all existing RPC threads are blocked, a new RPC thread is dynamically created.
    3641
    37 Il existe différents types de RPC :
    38  * Une RPC ''simple bloquante'' est envoyée à un seul serveur, et et le thread client se bloque en attendant une seule réponse.
    39  * Une RPC ''multicast bloquante'' est envoyée à N serveurs, et le thread client se bloque en attendant N réponses.
    40  * Une RPC ''simple non bloquante'' est envoyée à un seul serveur et n'attend pas de réponse.
    41  * Une RPC ''multicast non bloquante'' est envoyée à N serveurs et n'attend pas de réponse.
     42Therefore, it can exist N simultaneously active RPC threads: the running one is the FIFO owner, and the (N-1) others are blocked on a wait condition.
    4243
    43 Chaque case d'une RPC_FIFO contient un pointeur étendu (xptr_t) sur un descripteur de RPC (rpc_desc_t), qui est stocké dans la mémoire du cluster client. 
    44 Un descripteur de RPC possède un format fixe comportant les informations suivantes:
    45  * Le champs '''index''' définit le type de service demandé (de façon similaire à un index d'appel système).
    46  * Le champs '''response''' est un entier qui défini le nombre de réponses attendues.
    47  * Le champs '''args''' est un tableau de 10 uint64_t contenant les arguments d'entrée et de sortie.
    48 Pour une RPC bloquante, le client initialise le champs '''response''' avec le nombre de réponses attendus, et chaque serveur concerné le décrémente au moyen d'un accès ''remote_atomique_add()'', pour signaler qu'il a terminé le traitement demandé.
    49 L'utilisation et l'interprétation du tableau '''args''' dépend de chaque type de RPC.
     44== 4) Placement of RPC threads on cores ==
    5045
    51 Les RPC non-bloquantes ne sont pas implémentées actuellement (juin 2016).
     46The client thread, after registering the RPC request in the target cluster FIFO, and before descheduling, send an IPI to a specific core in the client thread, and force this core to make a scheduling. The RPC threads being kernel threads, have an higher priority than the client threads that are generally user threads. Therefore this IPI will contribute to reduce the RPC latency for the client thread.
    5247
    53 == 5) Introduction d'une nouvelle RPC ==
     48To distribute the load associated to RPC handling on all cores in a given target cluster, ALMOS-MHH implement the following policy: The client thread select in target cluster the core that has the same local  index as the core running the client thread in the client cluster. 
    5449
    55 L'introduction d'une nouvelle RPC nécessite de modifier le code de ALMOS-MKH de la façon suivante:
    56  * Il faut définir ou identifier la fonction système ''my_kernel_service()'' qu'on souhaite exécuter à distance. Le nombre de paramètres d'entrée ou de sortie ne doit pas être supérieur à 8.
    57  * La nouvelle RPC doit être enregistrée dans l'enum ''rpc_index_t'' (fichier rpc.h) et dans le tableau ''rpc_server[]'' (fichier rpc.c).
    58  * Il faut écrire explicitement la fonction de marshaling ''rpc_my_kernel_service_client()'' qui est exécutée du côté client pour (1) enregistrer les arguments d'entrée dans le descripteur de RPC, (2) poster la RPC dans la RPC_FIFO, (3) récupérer les arguments de sortie dans le descripteur de RPC.
    59  * Il faut écrire explicitement a fonction de marshaling ''rpc_my_kernel_service_server()'' qui est exécutée du côté serveur pour (1) récupérer les arguments d'entrée dans le descripteur de RPC, (2) appeler la fonction ''my_kernel_service()'', (3)  écrire les arguments de sortie dans le descripteur de RPC, (4) signaler la terminaison.
     50== 5) RPC request format ==
     51
     52ALMOS-MKH implement two types of RPCs :
     53 * '''simple RPC''' : the client thread send the RPC request to one single server waiting one single response.
     54 * '''multicast RPC''' : the client thread send the same RPC request to several servers, expecting several responses.
     55
     56Each entry in the RPC_FIFO contains a remote pointer (xptr_t) on a RPC descriptor (''rpc_desc_t''), that is stored on the client side (in the client thread stack). This RPC descriptor has a fixed format, and contains the following informations:
     57 * The '''index''' field defines the required service type.
     58 * The '''args''' field is an array of 10 uint64_t, containing the service arguments (both input & output).
     59 * The '''thread''' field defines the client thread (used by the server thread to unblock the client thread).
     60 * The '''lid''' field defines the client core local index (used by the server thread to send the completion IPI).
     61 * The '''response'''field defines the number of expected responses.
     62
     63The semantic of the '''args''' array depends on the RPC '''index''' field.
     64
     65This format supports both simple and multicast RPCs: The clientt thread initializes the '''response''' field with the number of expected responses, and each server thread atomically decrement this counter when the RPC request has been satisfied.
     66
     67== 6) How to define a new RPC ==
     68
     69To introduce a new RPC service ''rpc_new_service'' in ALMOS-MKH, you need to modify the ''rpc.c'' and ''rpc.h'' files:
     70 * You must identify (or possibly implement if it does not exist) the kernel function ''kernel_service()'' that you want to execute remotely. This function should not use more than 10 arguments.
     71 * You must register the new RPC in the enum ''rpc_index_t'' (in ''rpc.h'' file), and in the ''rpc_server [ ]'' array (in the ''rpc.c'' file).
     72 * You must implement the marshaling function ''rpc_kernel_service_client()'', that is executed on the client side by the client thread, in the ''rpc.c'' and ''rpc.c'' files. This function (1) register the input arguments in the RPC descriptor, (2) register the RPC request in the target cluster RPC_FIFO, (3) extract the output arguments from the RPC descriptor.
     73 * You must implement the marshaling function ''rpc_kernel_service_server()'', that is executed on the server side by the RPC thread, in the ''rpc.c'' and ''rpc.c'' files. This function (1) extract the input arguments from the RPC descriptor, (2) call the ''kernel_service()'' function, (3) register the outputs arguments in the RPC descriptor.
     74