[Kos-dev] Synchro VMM : premiers essais

[Thomas Petazzoni]

Salut,

J'ai écrit un petit test (pas encore committé) pour stresser un peu la
VMM d'un point de vue synchro. En gros, plusieurs threads
créent/détruisent des régions mémoires en les touchant à chaque fois
pour être sûr qu'une page physique est allouée.

En gros, quand y'a un thread qui fait ça (une centaine de fois), tout va
bien. Dès qu'il y a plus d'un thread, ça explose de partout ;-)

On s'en serait douté vu qu'il n'y pour l'instant aucune synchro sur
toute la gestion de la mémoire virtuelle. J'ai regardé vite fait dans
Linux, et ils utilisent un semaphore (d'où mes questions sur
down_write). Je pense utiliser donc un unique semaphore pour chaque
espace d'adressage, dans la structure addrress_space (cf
http://kos.enix.org/~d2/snapshots/kos_current/doc/kos_structures.eps).
Ce semaphore serait pris dans chaque fonction qui touche à la
modification de l'arbre des régions virtuelles ou des régions virtuelles
elles mêmes.

Des questions surviennent alors :

 - A-t-on besoin d'un lock au niveau de arch/mm pour protéger les
modifications concurrentes des PD/PT. A priori non, puisque tout est
censé passer par la mémoire virtuelle.

 - Comment ça va se passer avec les #PF. J'avais déjà posté un mail à ce
sujet, en particulier en ce qui concerne les données swappées ou dans
des fichiers qu'il faut rapatrier en mémoire. On avait conclu qu'il
fallait garder une liste des requêtes à servir, relâcher le lock, au
bout d'un moment servir la requête d'I/O et relancer la tâche. Comme ça,
si pendant ce temps là un autre thread du même espace d'adressage fait
un #PF sur la même page, on va pas charger deux fois la même page du
disque. Par contre, si jamais c'est une région anonyme, on a juste à
allouer la page et à mettre des zéros, vous croyez qu'on peut conserver
le sémaphore pendant ce temps là ?

Thomas
-- 
PETAZZONI Thomas - thomas.petazzoni at enix.org 
http://thomas.enix.org - Jabber: kos_tom at sourcecode.de
KOS: http://kos.enix.org/ - Lolut: http://lolut.utbm.info
Fingerprint : 0BE1 4CF3 CEA4 AC9D CC6E  1624 F653 CB30 98D3 F7A7
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://the-doors.enix.org/pipermail/kos-dev/attachments/20040624/1642ebf2/attachment.pgp