# SMC Compte Rendu TP10

## Binôme
* Guillaume VACHERIAS : 21204391
* Yann QUERIC : 28712032

## Question

### Question 1
* *Comment est construit le PID identifiant un processus ?*
PID est codé sur 32 bits dont 16 bits MSB (CXY) identifiant du cluster owner et 16 bits (LPID) l'indice du processus dans le owner cluster.

* *Quel est l'utilité de ce type d'encodage du PID ?*
Comme on peut répliquer les descripteurs du processus sur tous les cluster, il faut alors garantir la cohérence. Ainsi dans le PID les 16 bits MSB (CXY) cluster owner est fixe mais les valeurs reference cluster peuvent changer lors d'une migration du processus sir un autre cluster.

### Question 2
*Pour un processus P s'étalant sur plusieurs clusters, il existe un descripteur de processus dans chaque cluster contenant au moins un thread de P. Parmi toutes ces copies, on distingue le cluster owner, le cluster reference et des clusters copy. Quel est le rôle de chacun ?*

* Le cluster owner est le cluster qui contient la copie "original" du processus, celui qui a crée le processus avec son PID.
* Le cluster reference contient une reference du la replication du descripteur de processus
* Le cluster copy contient une liste de copie des processus appartenant au cluster.

### Question 3
* *À part le cas (non implémenté actuellement) de la migration complète d'un processus mono-thread, Almos-mkh ne supporte pas la migration des threads dans le cas général ?*
* À partir février 2018, le mécanisme de migration de tout les threads d'un processus dans un cluster peuvent être migrer par le load balancing. Celui ci nécessite de distinguer le kernel thread identifier (TRDID modifié lors de la migration) et le user thread identifier (THREAD modifié lors de la migration).
* Avant février 2018, un thread n'appartient que au core donné du cluster donné.

* *En quoi ce choix simplifie-t-il l'ordonnancement des threads ?*
L'ordonnancement des threads n'existe pas si la tâche créé reste sur le même core du même cluster.

* *En quoi la migration de thread peut-elle dégrader les performances ?*
La migration des thread nécessite de modifier TRDID et THREAD lors d'un load balancing. Sur un système many core, l'accès multiple du write pose un problème de contention et de cohérence. De plus, on doit copier le processus descripteur du thread au nouveau core du nouveau cluster ce qui peut être time consuming.

* *Dans Almos-mkh, quel problème - plus grave - interdit en pratique la migration des threads ?*
Dans l'implémentation d'almos-mkh, le *user identifier* renvoyé lors de la création d'un thread est le même que le kernel identifier. Ceci empêche alors la migration puisque nous pouvons plus distinguer les instance du noyau dans les différents cluster et le thread en migration.

### Question 4
*Combien y a-t-il de types de thread ? A quoi correspondent ces différents types ?*

Il existe 4 types de thread :
* USER : thread crée par l'appel système *pthread_create()*
* DEV : thread créé pour le kernel pour des opérations I/O d'un channel device
* IDLE : thread exécuté lorsque le core est en état IDLE
* RPC : thread activé par le kernel pour exécuter des RPC (remote procedure call thread) request dans le local FIFO RPC.

### Question 5
* *Qu'est-ce que la VSL ?*
Virtual Segment List contient une list de segment virtuels

* *Quels sont les différents types de VSEG d'un processus utilisateur (autres que les VSEGS permettant l'accès au code et aux données du noyau lors des appels système) ?*
* utils zone contenant args vseg (DATA type des argument du processus main()) et envs vseg (DATA type contenant les variables d'environnement du processus).
* elf zone contenant text vseg et data vseg définissant le code binaire du processus utilisateur et ses global data
* heap zone contenant les vseg file, anon et remote
* stack zone contenant le stack vseg.

* *Qu'y a-t-il dans une GPT ?*
Global Page Table contient l'adress physique associé à l'adresse virtuel d'une entrée de la VSL.

### Question 6
*Quand un process est sur plusieurs clusters, pourquoi chaque copie de La VSL, dans chaque cluster, n'est-il pas une simple copie (éventuellement incomplète) du contenu de la VSL du cluster de référence ?*

La copie de la VSL dépend de vseg data en question. En effet, on copie selon le type du vseg :
* DATA, ANON, REMOTE vsegs : tout les vseg du père est enregistré au vseg du fils. Tout les entrées valide du GPT parent est copié au GPT fils. Mis-à-jours des entrées GPT du parent des cluster autre que cluster reference.
* STACK vsegs : copie de la vseg du user stack parent contenant la requête fork au fils.
* FILE vsegs : copie vseg parent au vseg fils. Toutes les entrées valide GPT du parent est enregistré au GPT fils. Le COW flag est pas set pour les données partagé.

### Question 7
*Pourquoi a-t-on un problème de cohérence entre les différentes copies de la VSL d'un même processus dans différents clusters ?*

D'apres la question 6 on ne fait pas une simple copie de la VSL; par consequant chaque copie d'un même processus ne sont pas forcement identique et par concesquant cela créé des problème de coherence.

### Question 8
*Dans la création d'un nouveau process, quel est le rôle de fork() et quel est le rôle d'exec() ?*
* fork() : créé un nouveau process. Un thread parent du processus P exécutant dans le cluster X fait l'appel système fork() pour créer un processus fils C sur un remote cluster Y. Fork() alloue un nouveau PID au cluster Y et effectue une copie partiel du VSL selon le type de vseg. De plus, fork() alloue un nouvveau TRDID au thread descripteur du cluster Y.
* exec() : après l'appel système fork(), tout les thread du processus P peuvent faire appel à exec(). Cet appel système force le processus P d'executer une nouvelle application contenant le même PID que le process parent, même file descriptors, même variable d'environnements. Le process descripteur sera nettoyé et tous les user threads seront supprimés. Un nouveau main thread descripteur sera créé dans le cluster référence. Ce thread peut être exécuter par n'importe quel cluster.

### Question 9
* *Où se trouve le bit COW (Copy On Write) ?*
Le bit COW (Copy On Write) est présent dans les adresses des entrées de la GPT.

* *A quoi sert-il ?*
Une page COW est une page partagé et non répliqué. Ils sont copiés à l'identique mais les pages référebcées sont no-writale. Cette page est donc taguée COW pour le père et le fils.

* *Est-il toujours utilisé ?*
Le flag COW est utilisé pour les vseg de type DATA, ANON, REMOTE, STACK, CODE et FILE.

* *A quel moment est-il modifié ?*
Le flag COW est modifié lors du fork(), plus précisément lors du copie partiel des vseg.

### Question 10
*Soit un process P avec 3 threads T0, T1 et T2. T1 exécute fork() mais pas exec(). Combien aura-t-on de process et de threads par process ?*

On aura 2 process puisque T1 a fait appel à fork() créant un nouveau process fils de process P. Puisqu'on a pas fait appel à exec les threads dupliqué du process P sont encore en exécution, ainsi il existe 3 threads dans le nouveau process créé.

### Question 11
*Qu'est-ce qu'une RPC ?*

Remote Procedure Call permet d'accéder aux structures distantes depuis un cluster X à un cluster distant Y.

### Question 12
*Quelle différence y a-t-il entre une RPC simple et une RPC parallèle ?*

RPC simple est bloquant pour le thread client. Celui ci doit exécuter les tâches :
* Allouer en mémoire un RPC descripteur
* Allouer un expected response counter
* Initialiser RPC descripteur
* Enregistre pointeur au RPC descripteur sur le FIFO du serveur
* Envoi IPI au core séléctionné au serveur cluster
* bloque et réordonnance du thread client par le server thread.

Rpc parallèle le thread client n'est pas bloquant. En effet, celui envoie plusieurs requête au serveur. Ces requêtes sont stockés dans le FIFO tenu par le serveur. Une fois que la dernière requête est transmit au FIFO le client sera bloqué.

### Question 13
*Il existe deux modes de terminaison d'un thread, par suicide ou meurtre.*

* *Quel appel système correspond à un suicide ?*
L'appel système *pthread_exit()* permet de suicider.

* *Quel appel système correspond à un meurtre ?*
L'appel système *pthread_cancel()* permet de tuer un thread.

* *Quelle est la fonction système appelée dans ces deux cas ?*
On appel la fonction *thread_delete()* permet de détruire un thread.

* *Pourquoi est-il plus simple de terminer un thread s'exécutant en mode détaché ?*
Le target thread T a tuer est en mode détaché, ainsi le killer thread peut être le target thread T lui même. On peut alors faire un appel simple à la fonction *thread_delete()*.

## Question au prof

* Question 2 : rôle du clusters copy
* Question 3 :problème - plus grave - interdit en pratique la migration des threads
* Question 9 : Est-il toujours utilisé COW
* Question 10 : Poser au prof