[Kos-cvs] [kos] Modification CVS par d2

[KOS CVS]

Module :	kos
Modifié par :	d2	03/03/02 00:58:23

Fichiers modifiés :
	modules/kmem   : _kslab_cache_free.c _kslab_cache_grow.c 
	modules/kos    : spinlock.h system.h 
	modules/pmm    : _pmm.c pmm.c pmm.h 
	modules/x86/mm : _rmap.c _vmap.c 

Détails :
pmm: synchro gpfm globale + 1 lock par gpfme...

J'ai essaye de separer les locks de gpfm en plusieurs locks (1 par
liste), mais c'est lourd : qd on bouge un gpfme d'une liste a l'autre,
il faut posseder les 2 locks = lock source + lock dest. Or, suivant le
sens du mouvement, l'ordre d'acquisition des locks n'est pas toujours
le meme. Il faudrait avoir une fct intermediaire qui rearrangerait
l'ordre d'acquisition/desacquisition des locks. J'ai laisse tombe ca
pour l'instant => 1 gros lock pour toutes les listes gpfm.

Le but de la manip sinon, c'etait d'avoir 1 lock par gpfme en plus,
pour que arch/mm puisse faire sa cuisine sans avoir a locker le lock
global des gpfme, histoire de speeder un peu. C'est tres chiatique,
mais ca a l'air de marcher. 1ere chose : l'ordre de locking = le gpfme
d'abord, puis eventuellement le lock gpfm global. Parce que si on fait
les locks dans l'autre sens, quand vmap possede le lock de gpfme, rien
ne lui garantit que le gpfme ne va pas etre transfere d'une liste de
gpfm a une autre (par exemple, devenir swappable). En faisant dans le
sens gpfme puis gpfm, on a donc la garantie que, a partir du moment ou
on possede le lock de gpfme, le gpfme ne bouge pas de liste.

Le probleme (car il y en a 1) est que, dans le cas ou on doit chercher
le gpfme ailleurs que dans la RAM, vu qu'on doit parcourir les listes,
on ne peut pas locker le gpfme entre temps, et le ressortir lock'e
(ordre de locking oblige). Par consequent, entre le unlock des listes
et la fin de get_gpfme_at_paddr (puis la fonction qui l'appelle par
derriere), le gpfme n'est pas du tout protege. En soit, c'est pas trop
genant : il peut changer 2367584723 de liste d'accueil, on s'en fout
(puisque la ou on en a besoin dans vmap, on prend le lock sur le
gpfme, ce qui l'empeche de bouger pdt qu'on s'en sert). Seulement, il
faut etre assure que le pointeur n'est pas kfree() entre temps par un
autre thread pendant ce temps la. En consequence, quand on libere les
pages de mapping en dehors de la RAM (demapping d'un periph hardware),
on ne peut pas liberer les gpfme hors RAM qui ont ete alloues
specialement pour ca => on les stocke dans une liste garbage, et le
gpfme recupere le type "INVALID", pour indiquer qu'il est
invalide. C'est pas tres beau, mais ca devrait etre suffisamment
rare. A moins que le mec passe son temps a
activer/desactiver/activer/desactiver... sa carte video, auquel cas
pas mal de gpfme inutiles vont rester.

Voir les commentaires " [GARBAGE Note] " dans _pmm.c