Changes between Version 2 and Version 3 of page_tables
- Timestamp:
- May 20, 2016, 5:59:11 PM (8 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
page_tables
v2 v3 1 1 = Réplication des tables de pages et des listes de vseg = 2 2 3 == 1) Descripteur de vseg==3 == __1) Descripteur de vseg__ == 4 4 5 5 Puisque 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. … … 14 14 * MAPPER : radix-tree contenant les pages physiques allouées à ce vseg (seulement pour les types CODE, DATA, FILE). 15 15 16 == 2) Tables de pages et listes de vsegs=16 == __2) Tables de pages et listes de vsegs__ == 17 17 18 18 Les 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. … … 51 51 Pour 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. 52 52 53 == 3) Enregistrement et destruction des vsegs dans les VSL(P,K)==53 == __3) Enregistrement et destruction des vsegs dans les VSL(P,K)__ == 54 54 55 55 La politique d’enregistrement et de destruction des vsegs dans les VSL(P,X) dépend du type de vseg: … … 109 109 Ce 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. 110 110 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)__ == 112 112 113 113 L’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 … … 181 181 Le traitement d’un défaut de page est le même que pour un vseg HEAP. 182 182 183 == 5) Invalidation d’une entrée dans la table des pages==183 == __5) Invalidation d’une entrée de la table des pages__ == 184 184 185 185 Dans un cluster Z, propriétaire d’un processus P, le noyau peut décider d’invalider une entrée d’une PT(P,Z). … … 189 189 Pour ce faire, le noyau du cluster Z doit broadcaster une PT_INVAL_BCRPC vers tous les autres clusters actifs de P. 190 190 191 == 6) Optimisation des RPC broadcast==191 == __6) Optimisation des RPC broadcast__ == 192 192 193 193 Dans 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. … … 198 198 Ces variables sont mises à jour à chaque création de thread. 199 199 200 == 7 ) Optimisation du traitement des défauts de page==200 == __7 ) Optimisation du traitement des défauts de page__ == 201 201 202 202 Pour 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.
