From b33e978896366b6f77c3048063a83dd6552eb2a4 Mon Sep 17 00:00:00 2001 From: Yorick Barbanneau Date: Fri, 17 Dec 2021 01:30:21 +0100 Subject: [PATCH] TD3 Update report --- rapports/td3/rapport.md | 137 +++++++++++++++++++++++++++++++++------- 1 file changed, 115 insertions(+), 22 deletions(-) diff --git a/rapports/td3/rapport.md b/rapports/td3/rapport.md index e442981..959fe2f 100644 --- a/rapports/td3/rapport.md +++ b/rapports/td3/rapport.md @@ -1,7 +1,8 @@ --- -title: systèmes d'exploitation, TD2 +title: systèmes d'exploitation, TD3 documentclass: scrartcl author: + - Juliette Lenoir - Yorick Barbanneau fontsize: 13pt mainfont: DejaVu Serif @@ -12,30 +13,122 @@ urlcolor: liens linkstyle: bold ... -## Mémoire physique +## Bilan -Notre fonction écris directement dans `machine->mainMemory`. Il pointe vers un -tableau de char représentant la mémoire. +Le voici, le boss final de Nachos: le dernier TD! Dans la lignée des précédents, +a-t-il fait passé un boss de Sekiro pour un promenade de santée? La réponse est +non. Profitant de l'expérience des précédents, nous sommes rentrés dedans plus +facilement. Mais ne pensez pas pour autant qu'on a fait une partie de Rayman, +_comme pour les précédents, nous avons du y passer beaucoup de +soirées... -## ReadAtVirtual +### La classe PageProvider -## PageProvider +Nous avons implementé et utilisé sans trop de difficulté `ReadAtVirtual()` comme +demandé (*Action I.3*). La classe `PageProvider` implementée dans le +fichier `userprog/pageprovier.cc` n'as pas montré plus de difficulté non plus ( +*Action I.5*). -Cette classe gère l'allocation de page mémoire, il n'en faut qu'une seule -instance de cette classe car nous devons gérer la mémoire que d'un seul endroit. -Dux instance de cette classe entrainerai des collisions : deux objets -pourraient allouer la même page. - -## ForkExec - -Nous avons choisis de déclarer les vasiables pour gérer le compteur de processus -dans `threads/system.{h,cc}` et des les utiliser dans `userprog/addrspace.cc`. -Un processus, de notre point de vue est avant tout un espace d'adressage, il nous -parait plus opportun de gérer le nombre des processus avec le contruscteur et le -destructeur de la classe addrspace. - -## stress Test - -Nous n'avons pas assez de pages, la mémoire est pleine! +Il a éte plus compliqué de choisir l'emplacement de notre variable +`pageProvider`. Nous avons au départ choisi de le positionner dans +`machine/machine.cc`. Mais comme on s'interroge souvent sur *La grande question +sur la vie, l'univers et le reste*, on s'est aussi interrogé sur la pertinence +de cet emplacement. Nous avons fini par le positionner dans `threads/system.cc`. +Cette classe gère l'allocation de pages mémoire, il n'en faut qu'une seule +instance de cette classe, **nous devons gérer la mémoire que d'un seul +endroit**. Plusieurs instances de cette classe entrainerai des collisions : +deux objets pourraient allouer la même zone mémoire. + +#### La stratégie de test + +Afin de tester notre implementation, nous avons écrit le programme +`test/userpages0.c`. Celui ci lance deux thread utilisant `PutString` pour +afficher des caractères. Nous nous sommes aidé d'information de débogage +donnée par la commande `DEBUG` afin de vérifier l'enchaînement des élements. +Afin de filter plus précisément les message issus de notre classe, nous +utilisons une lettre (p pour *PageProviser*): + +```c +DEBUG ('p', "PageProvider: GetEmpryPage() allocated page: %i\n", newPage); +``` + +### L'appel système ForkExec + +Le principe est donc simple : créer plusieurs espaces d'adressages, car encore +une fois, un processus est espace d'adressage. Nous avons maintenant de +l'expérience lorqu'il s'agit d'implementer des appels systèmes dans Nachos. + +Nous avons choisi de mettre la fonction `do_ForkExec` dans le fichier +`userprog/userthread.cc`. Nous avons géré deux problèmes possibles dans cette +fonction: + + 1. Le fichier executable passé en paramètre n'existe pas + 2. La creation de l'espace dadressage échoue. Cette erreur doit être capturée + avec un `try ... catch ...` + +### Gérer les processus + +Afin de gérer les processus, il faut les compter. Il nous faut donc un entier et +un sémaphore afin de protéger son incrémentation / décrémentation. Il sont +positionnés dans le fichier `threads/system.cc`. + +L'incrémentation se fait dans le constructeur de `AddrSpace`, la décrémentation +dans son destructeur. Dans le destructeur, nous libérons aussi les pages +mémoire en exécutant ReleasePage sur chaque +`AddrSpace->pageTable[]->PhysicalPage`. + +#### Le test + +Le programme `/test/forkexec.c` nous a servi de test pour notre implementation. +Il lance deux processus (`test/userpages0.c`). Le fichier `mempory.svg` exporte +dans la fonction `StartUserProc()` (`userprog/usertthread.cc` ligne *101*) +laisse bien apparaître nos **deux espaces d'adressages**. + + +### Le stress test + +Nous avons écris le programme `test/forkexec_stress.c` qui fait appel à +`test/userpages0.c` et `test/userpages1.c`. Chacun des deux derniers est lancé +six fois (12 processus au total) et lance à son tours 12 threads. + +Lors du lancement de ce stress-test, nous somme tombe à cours d'espace en +memoire. Nous avons donc augmenté le nombre des pages disponibles dans le +fichier `machine/machine.h`: + +```c++ +#define NumPhysPages 1024 // 256 pages au départ +``` + +Vous pouvez noter que la l'export de la cartographie memoire dans +`StartUserProc()` a été désactivé pour l'implementation de ce test. La +generation du fichier *SVG* allourdissait considérablement l'exécution. Nous +l'avons testé tout de même une fois: le fichier *SVG* pèse envison 18Mo... + + +## Ce qui nous manque + +Nous n'avons pas eu le temps de traiter les points bonus. Nous avons une +ébauche de l'*Action II.4* sur notre dépôt de code mais rien ne fonctionne (à +vrai dire il est dans un `git stash` au milieu d'autres...). + +## Les limitations + +À partir de l'impementation de l'appel système `ForkExec`, l'*address sanitizer* +est désactivé. Chaque exécution d'un programme utilisateur contenant des thread +menait à des erreur de fuite mémoire. Cette erreur particulième nous contraint à +effetcuer un CTRL+C afin de rependre la main sur notre terminal. + +``` +[...] +Cleaning up... +AddressSanitizer:DEADLYSIGNAL +================================================================= +==2622712==ERROR: AddressSanitizer: SEGV on unknown address 0x000000000000 \ + (pc 0x7fdcc41a8227 bp 0x63100054cfb8 sp 0x63100054c688 T0) +==2622712==The signal is caused by a READ memory access. +==2622712==Hint: address points to the zero page. +``` + +Le temps nous a manquer pour investiguer sur le problème.