22 | | == __2) création d’un processus dans un cluster distant__ == |
23 | | |
24 | | Ce mécanisme a été implémenté dans ALMOS-MK par Pierre-Yves Péneau, il est décrit dans la thèse de Mohamed Karaoui. |
25 | | La création d’un processus distant utilise le mécanisme fork / exec. |
26 | | On suppose qu’il existe un ordonnanceur par coeur, qui a pour rôle d’ordonnancer les threads qui ont été placés sur ce coeur. |
27 | | |
28 | | === 2.1) fork() === |
29 | | |
30 | | Le processus père P s’exécute sur un coeur du cluster Z. Il fait un appel système fork() qui a principalement |
31 | | pour rôle de sélectionner un cluster cible X qui deviendra le cluster propriétaire du processus fils F, et de dupliquer |
32 | | le processus P dans le cluster Z. Le choix du cluster cible devrait en principe s’appuyer sur la DQDT, bien que |
33 | | celle-ci ne soit pas implémentée actuellement dans ALMOS-MK. |
34 | | |
35 | | L’appel system fork() crée dans le cluster Z un nouveau descripteur de processus pour le processus clone P’, ainsi qu’un descripteur de thread pour le thread principal attaché au processus P’. |
36 | | Le descripteur du processus P’ contient en particulier la VSL(P’,Z), la PT(P’,Z), la FDT(P’,Z) qui sont des copies des tables correspondantes du processus P. En revanche la TRDL(P’,Z) ne contient que le thread nouvellement créé, ce qui signifie |
37 | | que le processus P’ clone est mono-thread. |
38 | | Puis l’appel système fork() demande au cluster cible X l’allocation d’un PID au moyen d’une FORK_RPC (bloquante), en transmettant en argument l’adresse étendue du descripteur de processus P’. Cette adresse est enregistrée dans la |
39 | | table des processus du cluster, et le PID est enregistré dans le descripteur du processus P’ du cluster Z. |
40 | | Finalement, le fork() enregistre le nouveau thread dans l’ordonnanceur du coeur du cluster Z qui exécute le fork(), |
41 | | et rend la main au processus P. |
42 | | |
43 | | === 2.2) exec() === |
44 | | |
45 | | Une fois l'opération fork() terminée, le processus fils P’ peut exécuter l'appel système exec(). Cet appel système exec() effectue une EXEC_RPC vers le cluster X, avec les arguments suivants: le PID du processus fils, le nom de la fonction à exécuter, les arguments de la fonction s'il y en a, les variables d'environnement. |
46 | | Cette RPC alloue un descripteur de processus pour le processus F, ainsi qu’un descripteur de thread. Il initialise ces descripteurs et les tables PT(F,X) , VSL(F,X), TRDL(F,X) en utilisant les arguments de la RPC. Il recopie le contenu de la FDT(P’,Z) dans la FDT(F,X), en utilisant un remote_memcpy(), puisqu’il dispose de l’adresse étendue de P’. |
47 | | Quand le processus P’ sur le cluster Z reçoit une réponse positive pour cette EXEC_RPC, le processus P’ intermédiaire |
48 | | se suicide. |
49 | | |
50 | | Une fois que les structures sont initialisées, le thread principal du processus fils est attaché à l'ordonnanceur du cœur cible. |
51 | | Le code binaire (segments code et data) sera chargé dans la mémoire du cluster cible, lors du traitement des défauts de page. |
52 | | |
53 | | == __3) descripteur de thread__ == |
| 22 | == __2) descripteur de thread__ == |
| 50 | |
| 51 | == __3) création d’un processus dans un cluster distant__ == |
| 52 | |
| 53 | Ce mécanisme a été implémenté dans ALMOS-MK par Pierre-Yves Péneau, il est décrit dans la thèse de Mohamed Karaoui. |
| 54 | La création d’un processus distant utilise le mécanisme fork / exec. |
| 55 | On rappelle qu’il existe un ordonnanceur par coeur, qui a pour rôle d’ordonnancer les threads qui ont été placés sur ce coeur. |
| 56 | |
| 57 | === 3.1) fork() === |
| 58 | |
| 59 | Le processus père P s’exécute sur un coeur du cluster Z. Il fait un appel système fork() qui a principalement |
| 60 | pour rôle de sélectionner un cluster cible X qui deviendra le cluster propriétaire du processus fils F, et de dupliquer |
| 61 | le processus P dans le cluster Z. Le choix du cluster cible devrait en principe s’appuyer sur la DQDT, bien que |
| 62 | celle-ci ne soit pas implémentée actuellement dans ALMOS-MK. |
| 63 | |
| 64 | L’appel system fork() crée dans le cluster Z un nouveau descripteur de processus pour le processus clone P’, ainsi qu’un descripteur de thread pour le thread principal attaché au processus P’. |
| 65 | Le descripteur du processus P’ contient en particulier la VSL(P’,Z), la PT(P’,Z), la FDT(P’,Z) qui sont des copies des tables correspondantes du processus P. En revanche la TRDL(P’,Z) ne contient que le thread nouvellement créé, ce qui signifie |
| 66 | que le processus P’ clone est mono-thread. |
| 67 | Puis l’appel système fork() demande au cluster cible X l’allocation d’un PID au moyen d’une TASK_FORK_RPC, en transmettant en argument l’adresse étendue du descripteur de processus P’. Cette adresse est enregistrée dans la table des processus du cluster, et le PID est enregistré dans le descripteur du processus P’ du cluster Z. |
| 68 | Finalement, le fork() enregistre le nouveau thread dans l’ordonnanceur du coeur du cluster Z qui exécute le fork(), et rend la main au processus P. |
| 69 | |
| 70 | === 3.2) exec() === |
| 71 | |
| 72 | Une fois l'opération fork() terminée, le processus fils P’ peut exécuter l'appel système exec(). Cet appel système exec() effectue une TASK_EXEC_RPC vers le cluster X, avec les arguments suivants: le PID du processus fils, le nom de la fonction à exécuter, les arguments de la fonction s'il y en a, les variables d'environnement. |
| 73 | Cette RPC alloue un descripteur de processus pour le processus F, ainsi qu’un descripteur de thread. Il initialise ces descripteurs et les tables PT(F,X) , VSL(F,X), TRDL(F,X) en utilisant les arguments de la RPC. Il recopie le contenu de la FDT(P’,Z) dans la FDT(F,X), en utilisant un remote_memcpy(), puisqu’il dispose de l’adresse étendue de P’. |
| 74 | Quand le processus P’ sur le cluster Z reçoit une réponse positive pour cette EXEC_RPC, le processus P’ intermédiaire |
| 75 | se suicide. |
| 76 | |
| 77 | Une fois que les structures sont initialisées, le thread principal du processus fils est attaché à l'ordonnanceur du cœur cible. |
| 78 | Le code binaire (segments code et data) sera chargé dans la mémoire du cluster cible, lors du traitement des défauts de page. |