[Kos-dev] Nouveautes du jour

d2 kos-dev@enix.org
25 Feb 2002 09:40:58 +0100


Bonjour,

>>>>> "thomas" == thomas  <thomas@the-doors.enix.org> writes:
    thomas> faire un petit allocateur specialement pour les rmap.  Je
    thomas> trouve que c'est plus propre que arch/mm ne repose pas sur
    thomas> kmem, mais d'un autre cote, la multiplication des
    thomas> allocateurs ne me plait pas forcement non plus.

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.

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.

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. 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.

Bonne journee,

-- 
d2