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
|
||||
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,
|
||||
<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
|
||||
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.
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue