Changes between Version 2 and Version 3 of page_tables


Ignore:
Timestamp:
May 20, 2016, 5:59:11 PM (6 years ago)
Author:
alain
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • page_tables

    v2 v3  
    11= Réplication des tables de pages et des listes de vseg =
    22
    3 == 1) Descripteur de vseg ==
     3== __1) Descripteur de vseg__ ==
    44
    55Puisque ALMOS-MK n'utilise pas la MMU paginée des processeurs, les table des pages ne sont utilisées que pour définir le mapping des vsegs des processus utilisateur.
     
    1414 * MAPPER : radix-tree contenant les pages physiques allouées à ce vseg (seulement pour les types CODE, DATA, FILE).
    1515
    16 == 2) Tables de pages et listes de vsegs =
     16== __2) Tables de pages et listes de vsegs__ ==
    1717
    1818Les différentes informations associées à un processus P sont regroupées dans le descripteur de processus (structure task_t). Ce descripteur de processus, ainsi que les structures qu'il contient, est - partiellement - répliqué dans tous les clusters contenant au moins un thread du processus P, appelés clusters actifs.
     
    5151Pour ce qui concerne les vsegs public, tout ajout dynamique d’un nouveau vseg public ou toute extension d'un vseg existant doit être répercuté dans tous les clusters actifs.
    5252
    53 == 3) Enregistrement et destruction des vsegs dans les VSL(P,K) ==
     53== __3) Enregistrement et destruction des vsegs dans les VSL(P,K)__ ==
    5454 
    5555La politique d’enregistrement et de destruction des vsegs dans les VSL(P,X) dépend du type de vseg:
     
    109109Ce type de vseg est  détruit lors de l’exécution du munmap(), en utilisant un mécanisme en deux RPC comme pour la création.
    110110
    111 == 4) Introduction d’une nouvelle entrée dans une PT(P,K) ==
     111== __4) Introduction d’une nouvelle entrée dans une PT(P,K)__ ==
    112112
    113113L’ajout d’une entrée dans une PT(P,K), pour un processus P dans un cluster K est la conséquence d’un défaut de page
     
    181181Le traitement d’un défaut de page est le même que pour un vseg HEAP.
    182182
    183 == 5) Invalidation d’une entrée dans la table des pages ==
     183== __5) Invalidation d’une entrée de la table des pages__ ==
    184184
    185185Dans un cluster Z, propriétaire d’un processus P, le noyau peut décider d’invalider une entrée d’une PT(P,Z).
     
    189189Pour ce faire, le noyau du cluster Z doit broadcaster une PT_INVAL_BCRPC vers tous les autres clusters actifs de P.
    190190
    191 == 6) Optimisation des RPC broadcast ==
     191== __6) Optimisation des RPC broadcast__ ==
    192192
    193193Dans une RPC broadcast, tous les clusters destinataires doivent signaler la terminaison en incrémentant de façon atomique un compteur de réponses,  qui est scruté par le cluster initiateur.
     
    198198Ces variables sont mises à jour à chaque création de thread.
    199199
    200 == 7 ) Optimisation du traitement des défauts de page ==
     200== __7 ) Optimisation du traitement des défauts de page__ ==
    201201
    202202Pour réduire le nombre de RPC causés par les défauts de page, le noyau d’un cluster X qui détecte un défaut de page peut utiliser un remote_read() dans la table PT(P,Z) du cluster de référence au lieu d’une PT_MISS_RPC. Ceci impose cependant d’utiliser un lock multi-lecteurs pour éviter un état incohérent dans le cas d’une transaction PT_INVAL_BC_RPC simultanée initiée par le cluster Z : Ce lock doit être pris systématiquement par le cluster propriétaire avant un PT_INVAL_BC_RPC, et par les autres clusters avant  un remote_read(). Il garantit que le PT_INVAL_RPC  ne sera lancé qu’après la fin de tous les remote_read() en cours. Il garantit qu’aucun nouveau remote_read() ne sera plus accepté avant la completion du PT_INVAL_RPC.