TD3 Update report
This commit is contained in:
parent
20e058d610
commit
b33e978896
1 changed files with 115 additions and 22 deletions
|
|
@ -1,7 +1,8 @@
|
||||||
---
|
---
|
||||||
title: systèmes d'exploitation, TD2
|
title: systèmes d'exploitation, TD3
|
||||||
documentclass: scrartcl
|
documentclass: scrartcl
|
||||||
author:
|
author:
|
||||||
|
- Juliette Lenoir
|
||||||
- Yorick Barbanneau
|
- Yorick Barbanneau
|
||||||
fontsize: 13pt
|
fontsize: 13pt
|
||||||
mainfont: DejaVu Serif
|
mainfont: DejaVu Serif
|
||||||
|
|
@ -12,30 +13,122 @@ urlcolor: liens
|
||||||
linkstyle: bold
|
linkstyle: bold
|
||||||
...
|
...
|
||||||
|
|
||||||
## Mémoire physique
|
## Bilan
|
||||||
|
|
||||||
Notre fonction écris directement dans `machine->mainMemory`. Il pointe vers un
|
Le voici, le boss final de Nachos: le dernier TD! Dans la lignée des précédents,
|
||||||
tableau de char représentant la mémoire.
|
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,
|
||||||
|
<Plug>_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
|
Il a éte plus compliqué de choisir l'emplacement de notre variable
|
||||||
instance de cette classe car nous devons gérer la mémoire que d'un seul endroit.
|
`pageProvider`. Nous avons au départ choisi de le positionner dans
|
||||||
Dux instance de cette classe entrainerai des collisions : deux objets
|
`machine/machine.cc`. Mais comme on s'interroge souvent sur *La grande question
|
||||||
pourraient allouer la même page.
|
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`.
|
||||||
## 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!
|
|
||||||
|
|
||||||
|
|
||||||
|
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.
|
||||||
|
|
|
||||||
Loading…
Add table
Add a link
Reference in a new issue