| 1 | = Politique de réplication / distribution = |
| 2 | |
| 3 | La politique de réplication / distribution vise deux objectifs: renforcer la localité, et SURTOUT minimiser la contention. |
| 4 | * Pour les données non partagées ou read-only, (segments de type CODE, STACK) on cherche à les répliquer dans tous les clusters de l’architecture pour les rapprocher des thread utilisateurs. |
| 5 | * Pour les données partagées ( segments DATA, HEAP, MMAP), on cherche à les distribuer le plus uniformément possible dans tous les clusters pour éviter la contention. |
| 6 | |
| 7 | On fait l’hypothèse que - pour chaque processus P - le descripteur du processus P, et certaines structures qu’il contient |
| 8 | telles que la table des pages (PT) et la liste des vsegs (VSL) sont répliquées dans tous les cluster qui contiennent |
| 9 | au moins un thread de P. |
| 10 | |
| 11 | 1) pour un processus utilisateur P |
| 12 | |
| 13 | Un vseg désigne une zone mémoire contigüe dans l’espace virtuel d’un processus, auxquels sont attachés |
| 14 | certains attributs (droit d’accès, politique de réplication/distribution dans les différents clusters, cachabilité, etc.). |
| 15 | |
| 16 | - Un vseg est public quand il peut être accédé par n’importe quel thread du processus, |
| 17 | quel que soit le cluster dans lequel le thread s’exécute. Il est private quand il n’est accédé que par les threads |
| 18 | s”exécutant dans le même cluster que le cluster ou est mappé le vseg. |
| 19 | |
| 20 | - Un vseg private est entièrement mappé dans la mémoire physique du cluster K dans lequel il est accessible. |
| 21 | Il est enregistré dans liste des segments et dans la table des pages du cluster K, mais pas dans les autres clusters. |
| 22 | |
| 23 | - Un vseg public est enregistrés dans la liste des segments et dans la table des pages de tous les clusters actifs |
| 24 | (i.e. tous les clusters qui contiennent un thread de P). |
| 25 | Pour maintenir la cohérence entre les tables de pages, chaque vseg public possède un cluster de référence, qui est le cluster |
| 26 | propriétaire du processus (i.e. le cluster Z où a été créé le processus). |
| 27 | Les réplicas du descripteurs de processus (et surtout les tables |
| 28 | associées) autres que celui contenu dans le cluster de référence peuvent être considérées comme des caches read-only. |
| 29 | |
| 30 | - Un vseg peut être localised (toutes les pages du vseg sont mappées dans le même cluster), |
| 31 | ou distributed (différentes pages sont mappées dans différents clusters en utilisant par exemple les bits de poids |
| 32 | faibles comme clé de distribution). Les vsegs privés sont toujours localised. |
| 33 | |
| 34 | Il existe sept types de vsegs, correspondant à des politiques de réplication/distribution différentes : |
| 35 | |
| 36 | - CODE : private / plusieurs vsegs / mêmes adresses virtuelles, même contenu, un vseg par cluster actif |
| 37 | - STACK : private / plusieurs vsegs / un vseg par thread de P, mappé dans le cluster hébergeant le thread |
| 38 | - DATA : public / un seul vseg / distributed |
| 39 | - HEAP : public / un seul vseg / distributed |
| 40 | - REMOTE : public / plusieurs vsegs / chaque vseg localised (dans le cluster concerné par le remote_malloc(x,y) ) |
| 41 | - FILE : public / plusieurs vsegs / chaque vseg localised (dans le cluster contenant le fichier concerné par le mmap() ) |
| 42 | - ANON : public / plusieurs vsegs / chaque vseg distributed (associé à un mmap() anonyme ) |
| 43 | |
| 44 | 2) pour le noyau, |
| 45 | |
| 46 | Les différentes instances du noyau ne travaillant qu’en adressage physique, les segments kernel sont définis dans |
| 47 | l’espace d’adressage physique. |
| 48 | |
| 49 | - un segment kernel est private quand il ne peut être accédé que par l’instance locale du noyau. |
| 50 | il est public quand il peut être accédé par n’importe quel instance du noyau. |
| 51 | |
| 52 | Dans un segment public, le noyau peut définir des structures répliquées homologues. |
| 53 | Si N est le nombre de clusters, une structure répliquées homologue est un ensemble de N structures identiques, |
| 54 | de longueur fixe, implantées à des adresses physiques ne différant entre elles que par les bits de poids fort |
| 55 | définissant les coordonnées du cluster. |
| 56 | |
| 57 | On identifie (pour l’instant) les segments suivants |
| 58 | |
| 59 | - KDATA : private |
| 60 | - KCODE : private |
| 61 | - KSTACK : private |
| 62 | - KHEAP : private |
| 63 | - SHARED : public |
| 64 | |
| 65 | ——————————————————————————————— |
| 66 | B) Construction dynamique des tables de pages d’un processus |
| 67 | ——————————————————————————————— |
| 68 | |
| 69 | 1) Descripteur de vseg |
| 70 | |
| 71 | Un descripteur de vseg contient les informations suivantes : |
| 72 | - TYPE : définit la politique de réplication/distribution (CODE / STACK / DATA / HEAP / HEAPXY / FILE / ANON) |
| 73 | - FLAGS : définit les droits d’accès |
| 74 | - VBASE : adresse virtuelle de base |
| 75 | - LENGTH : longueur du segment |
| 76 | - BIN : pathname to the .elf file. (seulement pour les types DATA et CODE) |
| 77 | - X,Y : coordonnées du cluster où est mappé le vseg (seulement pour un vseg localised) |
| 78 | - MAPPER : radix-tree contenant les pages physiques allouées à ce vseg (seulement pour les types CODE, DATA, FILE). |
| 79 | |
| 80 | 2) Descripteur de processus |
| 81 | |
| 82 | Dans chaque cluster, les différentes informations associées à un processus P sont regroupées dans le descripteur de processus. |
| 83 | Le PID (Process Identifier) est codé sur 32 bits, et il est unique dans le système : les 8 bits de poids fort contiennent |
| 84 | les coordonnées (X,Y) du cluster propriétaire Z, les 24 bits de poids faibles (LPID) contiennent le numéro local dans le cluster Z. |
| 85 | Le descripteur d’un processus P et les tables qui lui sont associées ne sont répliqués que dans les clusters qui contiennent |
| 86 | au moins un thread de P (appelés clusters actifs de P). |
| 87 | |
| 88 | Les principale informations stockées dans le descripteur processus sont les suivantes: |
| 89 | - PID : processus identifier (contient les coordonnées du cluster propriétaire) |
| 90 | - PPID : parent processus identifier, |
| 91 | - XMIN, XMAX, YMIN, YMAX : recrangle recouvrant tous les clusters actifs |
| 92 | - PT : table des pages du processus, |
| 93 | - VSL : liste des vsegs du processus, |
| 94 | - FDT : table des fichiers ouverts du processus, |
| 95 | - TRDL : liste des threads du processus, |
| 96 | - ENV : variables d’environnement du processus, |
| 97 | |
| 98 | Le contenu des tables de pages évolue au cours du temps, et n’est pas identique dans tous les clusters. |
| 99 | En effet le contenu des tables P évolue différemment dans les clusters en fonction des |
| 100 | défauts de pages causés par les threads de P s’exécutant dans les différents clusters. |
| 101 | De plus le mapping des segments private (CODE et STACKS) varie d’un cluster à un autre. |
| 102 | Pour ce qui concerne les vsegs public, seul le cluster de référence contient l’état complet du mapping. |
| 103 | |
| 104 | De même, le contenu des listes de vsegs évolue au cours du temps, et n’est pas identique dans tous les clusters. |
| 105 | En effet chaque vseg private n’est enregistré que dans un seul cluster. |
| 106 | En revanche toutes les listes de vsegs doivent être identiques pour ce qui concerne les vsegs public. |
| 107 | Pour ce qui concerne les vsegs public, tout ajout dynamique d’un nouveau vseg public ou toute extension |
| 108 | doit être répercuté dans tous les clusters actifs. |
| 109 | |
| 110 | 3) Enregistrement et destruction des vsegs |
| 111 | |
| 112 | La politique d’enregistrement et de destruction des vsegs dans les VSL(P,X) dépend du type de vseg: |
| 113 | |
| 114 | 3.1) DATA |
| 115 | Ce type de vseg est enregistré dans la VSL(P,Z)) du cluster Z propriétaire du processus P au moment de la création de P. |
| 116 | Il est enregistré dans la VSL(P,A) d’un autre cluster A chaque fois qu’un thread de P est créé dans le cluster A, |
| 117 | si ce cluster ne contenait pas encore de thread du processus P. |
| 118 | La longueur est définie par le fichier .elf contenant le code binaire du processus. |
| 119 | Il n’y a pas de cluster de mapping pour un vseg distributed. |
| 120 | Ce type de vseg n’est détruit que lors de la destruction du processus. |
| 121 | |
| 122 | 3.2) CODE |
| 123 | Ce type de vseg est enregistré dans la VSL(P,Z) du cluster Z propriétaire du processus P au moment de la création de P. |
| 124 | Il est enregistré dans la VSL(P,A) d’un autre cluster A chaque fois qu’un thread de P est créé dans le cluster A, |
| 125 | si ce cluster ne contenait pas encore de thread du processus P. |
| 126 | La longueur est définie par le fichier .elf contenant le code binaire du processus. |
| 127 | Le cluster de mapping est toujours le cluster local pour un vseg private. |
| 128 | Ce type de vseg n’est détruit que lors de la destruction du processus. |
| 129 | |
| 130 | 3.3) STACK |
| 131 | Un vseg de type STACK est enregistré dans la VSL(P,X) du cluster X chaque fois qu’un thread est crée dans le cluster X |
| 132 | par le processus P. Les VSL(P,Y) des autres clusters Y n’ont pas besoin d’être mises a jour car un vseg STACK |
| 133 | dans un cluster X n’est ni connu ni accédé depuis un autre cluster Y. |
| 134 | La longueur est définie par un paramètre global de l’OS : MIN_STACK_SIZE. |
| 135 | Le cluster de mapping est toujours le cluster local pour un vseg private. |
| 136 | Ce type de vseg est éliminé de la VSL(P,X) lors de la destruction du thread. |
| 137 | |
| 138 | 3.4) HEAP |
| 139 | Ce type de vseg est enregistré dans la VSL(P,Z) du cluster Z propriétaire du processus P au moment de la création de P. |
| 140 | Il est enregistré dans la VSL(P,A) d’un autre cluster A chaque fois qu’un thread de P est créé dans le cluster A, |
| 141 | si celui-ci ne contenait pas encore de thread du processus P. |
| 142 | La longueur est un paramètre global de l’OS : STANDARD_MALLOC_HEAP_SIZE. |
| 143 | Il n’y a pas de cluster de mapping pour un vseg distributed. |
| 144 | Ce type de vseg n’est détruit que lors de la destruction du processus. |
| 145 | |
| 146 | 3.5) REMOTE |
| 147 | Ce type de vseg est enregistré dans la VSL(P,A) de tous les clusters A qui contiennent au moins un thread de P, |
| 148 | au moment où un thread quelconque de P exécute un remote_malloc(x,y) dans un cluster K. |
| 149 | Le noyau du cluster K envoie une VSEG_REQUEST_RPC vers le cluster Z propriétaire de P, si un vseg de type REMOTE |
| 150 | n’existe pas déjà dans la VSL(P,K). Les arguments sont le PID, le type du vseg, les coordonnées (x,y), … To Be Completed … |
| 151 | Si ce type de vseg n’existe pas déjà dans la VSL(P,Z), le noyau de Z broadcaste une VSEG_REGISTER_BCRPC vers tous les |
| 152 | clusters actifs de P. |
| 153 | La longueur est un paramètre global de l’OS : REMOTE_MALLOC_HEAP_SIZE. |
| 154 | Le cluster de mapping est défini par les arguments (x,y) du remote_malloc(). |
| 155 | Ce type de vseg n’est détruit que lors de la destruction du processus. |
| 156 | |
| 157 | 3.6) FILE |
| 158 | Ce type de vseg est enregistré dans la VSL(P,A) de tous les cluster A qui contiennent au moins un thread de P, |
| 159 | au moment où un thread quelconque de P exécute un mmap(file , size) dans un cluster K. |
| 160 | Le noyau du cluster K envoie une VSEG_REQUEST_RPC vers le cluster Z propriétaire de P. Les arguments sont le PID, |
| 161 | le type de vseg, le descripteur de fichier, la taille … To be completed … |
| 162 | Le noyau du cluster Z broadcaste une VSEG_REGISTER_BCRPC vers tous les autres clusters actifs de P. |
| 163 | La longueur du vseg est définie par l’argument size du mmap(). |
| 164 | Le cluster de mapping est défini par l’argument file, et il est quelconque puisque le cache d’un fichier peut être placé |
| 165 | sur n’importe quel cluster (répartition uniforme). |
| 166 | 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. |
| 167 | |
| 168 | 3.7) ANON |
| 169 | Ce type de vseg est enregistré dans la VSL(P,A) de tous les cluster A qui contiennent au moins un thread de P, |
| 170 | au moment où un thread quelconque de P exécute un mmap(anonyme , size) dans un cluster K. |
| 171 | Le noyau du cluster K envoie une VSEG_REQUEST_RPC vers le cluster Z propriétaire de P. Les arguments sont le PID, |
| 172 | le type de vseg, le descripteur de fichier, la taille … To be completed … |
| 173 | Le noyau du cluster Z broadcaste une VSEG_REGISTER_BCRPC vers tous les autres clusters actifs de P. |
| 174 | La longueur du vseg est définie par l’argument size du mmap(). |
| 175 | Il n’y a pas de cluster de mapping pour un vseg distributed. |
| 176 | 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. |
| 177 | |
| 178 | 4) Introduction d’une nouvelle entrée dans une Table de Pages PT(P,K) |
| 179 | |
| 180 | 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 | causé par n’importe quel thread du processus P s’exécutant dans le cluster K, sur le principe du “on-demand paging”. |
| 182 | Tous les threads d’un processus P placés dans un cluster K utilisent exclusivement la PT(P,K) locale, et reportent |
| 183 | le défaut de page à l’instance locale du noyau. Le traitement du défaut de page dépend du type du segment : |
| 184 | |
| 185 | 4.1) CODE |
| 186 | Il existe un vseg de ce type dans la VSL de tous les clusters contenant au moins un thread du processus P. |
| 187 | Si le cluster K qui détecte le défaut de page est différent du cluster propriétaire du processus Z, le noyau du cluster K doit allouer |
| 188 | une page physique dans le cluster K. Pour initialiser cette page, il envoie une PT_MISS_RPC au cluster Z propriétaire du processus. |
| 189 | Quand il obtient le PTE stocké dans la PT(P,Z), il effectue un remote_memcpy() pour copier le contenu de la page physique |
| 190 | du cluster Z vers la page physique du cluster K. Il termine en introduisant le PTE manquant dans la PT(P,K). |
| 191 | Si le cluster K est le cluster propriétaire de Z, il alloue une page physique, initialise cette page en s’adressant au système de fichier, |
| 192 | pour récupérer le contenu de la page manquante dans le cache du fichier .elf, et met à jour la PT(P,Z). |
| 193 | |
| 194 | QUESTION : dans le cluster propriétaire Z, faut-il faire une copie de la page du cache de fichier vers une autre page physique ? [AG] |
| 195 | |
| 196 | 4.2) STACK |
| 197 | Les vsegs STACK associées aux thread placées dans un cluster X sont mappées dans le cluster X, |
| 198 | et sont gérés indépendamment les uns des autres dans les différents clusters. |
| 199 | Le noyau du cluster X doit allouer une page physique, et l’enregistrer dans la PT (P,X) locale sans l’initialiser. |
| 200 | Si l’adresse demandée tombe dans la dernière page disponible pour le vseg, la longueur du vseg STACK peut être dynamiquement |
| 201 | localement augmentée dans la VSL(P,X) locale, si il y a de la place dans dans la zone de l’espace virtuel utilisée pour les piles. |
| 202 | Comme suggéré par Franck, on peut imaginer une politique d’allocation par dichotomie utilisant deux arguments : MAX_STACK_SIZE |
| 203 | définissant la longueur totale de la zone réservée aux piles, et MIN_STACK_SIZE définissant la longueur minimale d’une pile particulière. |
| 204 | |
| 205 | 4.3) DATA |
| 206 | Ce vseg étant distributed, les pages physiques sont distribuées sur tous les clusters suivant les bits de poids faible du VPN. |
| 207 | Si le cluster K qui détecte le défaut de page est différent du cluster propriétaire Z, le noyau du cluster K envoie une PT_MISS_RPC |
| 208 | au cluster Z, pour obtenir le PTE stocké dans la PT(P,Z). Les arguments sont le PID et le VPN de la page manquante. |
| 209 | Quand il reçoit la réponse, il met à jour la PT(P,K). |
| 210 | Si le cluster qui détecte le défaut de page est le cluster propriétaire Z, il sélectionne un cluster cible M à partir des bits |
| 211 | de poids faible du VPN, et envoie au cluster M une RPC_PMEM_GET_SPP pour obtenir le PPN d’une page physique du cluster M. |
| 212 | En réponse à cette RPC, le noyau du cluster M alloue une page physique et renvoie le PPN de celle-ci. |
| 213 | Le noyau du cluster Z s’adresse au système de fichier, pour récupérer le contenu de la page manquante dans le cache du fichier .elf, |
| 214 | et initialise la page physique dans M au moyen d’un remote_memcpy(). Finalement, il met à jour la PT (P,Z). |
| 215 | |
| 216 | 4.4) HEAP |
| 217 | Ce vseg étant distributed, les pages physiques sont distribuées sur tous les clusters suivant les bits de poids faible du VPN. |
| 218 | Si le cluster K qui détecte le défaut de page est différent du cluster propriétaire Z, le noyau du cluster K envoie une PT_MISS_RPC |
| 219 | au cluster Z, pour obtenir le PTE stocké dans la PT(P,Z). Les arguments sont le PID et le VPN de la page manquante. |
| 220 | Quand il reçoit la réponse, il met à jour la PT(P,K). |
| 221 | Si le cluster qui détecte le défaut de page est le cluster propriétaire Z, il sélectionne un cluster cible M à partir des bits |
| 222 | de poids faible du VPN, et envoie au cluster M RPC_PMEM_GET_SPP pour obtenir le PPN d’une page physique du cluster M. |
| 223 | En réponse à cette RPC, le noyau du cluster M alloue une page physique et renvoie le PPN de celle-ci. |
| 224 | Quand le noyau du cluster Z obtient le PPN, il met à jour la PT (P,Z). |
| 225 | |
| 226 | 4.5) REMOTE |
| 227 | Ce vseg étant localised, les coordonnées du cluster de mapping M sont enregistrées dans le descripteur de vseg. |
| 228 | Si le cluster K qui détecte le défaut de page est différent du cluster propriétaire Z, le noyau du cluster K envoie une PT_MISS_RPC |
| 229 | au cluster Z, pour obtenir le PTE stocké dans la PT(P,Z). Les arguments sont le PID et le VPN de la page manquante. |
| 230 | Quand il reçoit la réponse, il met à jour la PT(P,X). |
| 231 | Si le cluster qui détecte le défaut de page est le cluster propriétaire Z, il envoie au cluster M une RPC_PMEM_GET_SPP pour obtenir |
| 232 | le PPN d’une page physique du cluster M. |
| 233 | En réponse à cette RPC, le noyau du cluster M alloue une page physique, et renvoie le PPN de celle-ci. |
| 234 | Quand le noyau du cluster Z obtient le PPN, il met à jour la PT (P,Z). |
| 235 | |
| 236 | 4.6) FILE |
| 237 | Ce vseg étant localised, les coordonnées du cluster de mapping M sont enregistrées dans le descripteur de vseg. |
| 238 | Si le cluster qui détecte le défaut de page K est différent du cluster propriétaire Z, le noyau du cluster K envoie une PT_MISS_RPC |
| 239 | au cluster Z, pour obtenir le PTE stocké dans la PT(P,Z). Les arguments sont le PID et le VPN de la page manquante. |
| 240 | Quand il reçoit la réponse, il met à jour la PT(P,K). |
| 241 | Si le cluster qui détecte le défaut de page est le cluster propriétaire Z, il envoie au cluster M qui contient le cache du fichier |
| 242 | une GET_FILE_CACHE_RPC pour obtenir le PPN. Les arguments sont le PID, le descripteur du fichier, et l’index de la page dans le mapper. |
| 243 | En réponse à cette RPC, le noyau du cluster M accède au mapper du vseg et retourne le PPN correspondant. |
| 244 | Quand le noyau du cluster Z obtient le PPN, il met à jour la PT (P,Z). |
| 245 | |
| 246 | 4.7) ANON |
| 247 | Ce vseg étant distributed, les pages physiques sont distribuées sur tous les clusters suivant les bits de poids faible du VPN. |
| 248 | Le traitement d’un défaut de page est le même que pour un vseg HEAP. |
| 249 | |
| 250 | QUESTION : Les mécanismes décrits ci-dessus pour les types DATA, HEAP, REMOTE et ANON utilisent une RPC_PMEM_GET_SPP, |
| 251 | qui suppose que le noyau d’un cluster (M) peut “transmettre la propriété” d’une ou plusieurs pages physiques |
| 252 | à un autre cluster (Z) pour la durée de vie d’un processus. Il faut définir une politique d’allocation/libération de pages de |
| 253 | mémoire physique entre clusters… [AG] |
| 254 | |
| 255 | |
| 256 | 5) Invalidation d’une entrée dans une Table de Pages |
| 257 | |
| 258 | 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). |
| 259 | Cela peut se produire par exemple en cas de pénurie de mémoire dans le cluster Z, ou simplement en cas de munmap(). |
| 260 | Sauf si le vseg concerné est de type STACK, l’entrée invalidée dans la PT(P,Z) doit aussi être invalidée |
| 261 | dans les PT(P,K) des autre clusters. |
| 262 | Pour ce faire, le noyau du cluster Z doit broadcaster une PT_INVAL_BCRPC vers tous les autres clusters actifs de P. |
| 263 | |
| 264 | 6) Optimisation des RPC broadcast |
| 265 | |
| 266 | Dans une RPC broadcast, tous les clusters destinataires (même ceux qui ne sont pas concernés) |
| 267 | signalent la terminaison en incrémentant de façon atomique un compteur de réponses, qui est scruté par le cluster initiateur. |
| 268 | |
| 269 | Pour réduire le nombre de destinatiares, le descripteur du processus P du cluster propriétaire Z peut maintenir quatre variables |
| 270 | XMIN, XMAX, YMIN, YMAX définissant le rectangle minimal recouvrant tous les clusters actifs de P à tout instant. |
| 271 | Dans ce cas une RPC broadcast ne doit être envoyée qu’a (XMAX - XMIN + 1) * (YMAX - YMIN +1) destinataires. |
| 272 | Ces variables sont mises à jour à chaque création de thread. |
| 273 | |
| 274 | 7 ) Optimisation du traitement des PT_MISS |
| 275 | |
| 276 | 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 |
| 277 | 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 |
| 278 | 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 remore_read(). Il garantit que le PT_INVAL_BC_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_BC_RPC. |