[Kos-dev] Nouveautes du jour

[Thomas Petazzoni]

d2 <David.Decotigny@irisa.fr> writes:

> Moi non plus. Et puis il va bien falloir que tu mappes les pages de
> ton nouvel allocateur, ce qui nous fera peut-etre la chaine (cas de vmap
> d'une page noyau) :
>  vmap -> lock(kernel_space) -> rmap -> alloc_rmap -> vmap -> lock(kernel_space)
> ==> deadlock
> ... a moins que tu mappes "a la main", ie sans utiliser le vmap
> "normal". Mais ca fait 2 mecanismes "en parallele" (avec du code tres
> proche) pour le kslab et vmap des rmappings, ce qui n'est pas
> optimal cote duplication de code.

Non ce que j'avais fait etait un peu plus subtil (enfin je crois). En
fait j'avais ecrit au niveau de _vmap.c deux fonctions :

arch_map_virtual_kernel_page_unsafe
arch_unmap_virtual_kernel_page_unsafe

En gros elles contenaient le code de arch_map et arch_unmap, mais
seulement pour la partie noyau et sans le lock. Ces deux fonctions
etaient inline, et appelles depuis arch_map et arch_unmap.

En gros :

arch_map_virtual_page :
si (page noyau) alors
  locker(kernel)
  arch_map_virtual_kernel_page_unsafe()
  unlocker(kernel)
sinon
  locker(user)
  faire le bordel necessaire
  unlocker(user)

Ensuite, je faisais bien attention dans rmap : si la page dont on
souhaitait ajouter le rmap est dans l'espace noyau, je suis sur que le
lock kernel est deja pris, donc pas besoin de le reprendre, je peux
appeler direct arch_map_virtual_kernel_page_unsafe. Si c'est une page
de l'espace user, alors j'appelle directement arch_map_virtual_page,
et vu que c'est une page user, on prendra pas le lock sur l'espace
noyau, mais sur l'espace user, donc pas de deadlock.

> Sinon, ce WE, j'ai juste essaye d'eviter le pb du deadlock en cas
> d'alloc/desalloc de rmapping a cause de l'oeuf et de la poule sur
> kernel_lock_space et vmap/kslab. Je n'ai rien locke de nouveau.

Oui, de mon cote il faut que je reflechisse beaucoup. Je veux mettre
un lock par GPFME, mais apres j'ai l'impression que ca va poser
quelques problemes. Je regarderais plus precisement, et je te ferais
part de mes interrogations.

> En particulier, je ne suis pas rentre dans le probleme du lock des
> listes gpfme. Car en effet, c'est un truc qu'il va falloir regarder de
> plus pres. A terme, l'alloc d'une page physique risque de prendre du
> temps (car risque de demander l'intervention du swapper). Pour que ce
> soit possible, il va sans doute falloir remplacer des spinlocks par
> des semaphores [non binaire] (je pense a kernel_gpfm_lock). Dans ce
> cas, on voit bien qu'il faudra alors que get_physical_page (et
> put_physical_page par la meme occasion) soit appele en dehors de tout
> spinlock, quels qu'ils soient. Ce qui va necessiter de revoir le code
> la ou les get_/put_physical_page sont appeles, et s'arranger pour
> qu'ils soient appeles en dehors de tout lock. 

J'avais essaye effectivement de sortir les get_physical et
put_physical en dehors des spinlocks, mais ce n'est pas toujours tres
evident.

> La ou on doit posseder
> un lock en meme temps que le get_physical_page, on peut imaginer un
> mecanisme d'allocation/desallocation differee (pas trop naif)
> similaire a celui de rmap_session. Sinon, pour le debuggage, ie savoir
> si le get/put_physical_page sont appeles alors qu'un ou plusieurs
> spinlocks sont possedes, on peut peut-etre modifier les macros
> spinlock avec un compteur global de niveau d'imbrication des
> spinlocks, et verifier que ce compteur est a 0 qd on est dans
> get/put_physical_page.

De toute facon, les problemes de spinlock vont nous embeter, mais ca
fait partie du jeu de devoir composer avec ;)

Sinon, je suis rentre sur Belfort, et j'ai eu droit au speech du
departement GI ce matin ;) Passionant !

A bientot,

Thomas
-- 
PETAZZONI Thomas - thomas.petazzoni@enix.org - UIN : 34937744
(Perso)      http://www.enix.org/~thomas/
(KOS)        http://kos.enix.org/ 
(Club LinUT) http://club-linut.enix.org