[Kos-dev] Divers

[d2]

Bonjour,

>>>>> "Thomas" == Thomas Petazzoni <thomas.petazzoni@enix.org> writes:
    Thomas> de trop. On pourrait ameliorer : au lieu d'avoir seulement
    Thomas> un spare_pt_rmap, on pourrait avoir une liste (ca ajoute
    Thomas> pas de spinlock t'en as deja un). Mais bon ptet que c'est
    Thomas> un peu bourrin... Quoique dans les cas "normaux" ca
    Thomas> rajoute presque pas de code : un list_add_tail c'est pas
    Thomas> grand chose. M'enfin bon de toute facon c'est pas
    Thomas> vital-vital.

Dans la premiere version (jamais commitee), c'est comme ca que c'etait
fait. Mais je me suis rendu compte que vu la rarete de la chose
c'etait pas necessaire. Et je me suis dit qu'on pouvait jouer
l'adversaire mechant et utiliser ce mecanisme pour remplir la memoire
de spare_pt_rmap qui ne seront jamais recuperes... Au lieu de me
pencher sur ce probleme (est-ce qu'un adversaire peut vraiment faire
ca, etc...), je me suis dit qu'il etait plus sage de limiter a 1 le
nombre de spare_pt_rmap, parce que de toutes facons ca ne coute que 1
kslab_alloc/free de plus si l'adversaire est tres mechant, au lieu de
couter la saturation memoire.

    Thomas> [semaphore sur la liste des free] : je ne sais pas si
    Thomas> utiliser un semaphore sur la liste des GPFME est une bonne
    Thomas> idee : les sections critiques sont excessivement courtes
    Thomas> et se deroulent en un temps fini : il n'y a aucun

En l'etat oui, bien sur. Mais le probleme avec la liste des gpfme,
c'est que a terme, il y aura un swapper. Et que on pourra faire appel
a ses services qd on arrivera a cours de memoire physique. Dans ce
cas, ca entrainera un bloquage au niveau des get/put_phys_page, ie une
preemption vers le swapper. D'ou l'interet de prevoir un semaphore
plutot qu'un spinlock. Ceci dit, on peut peut-etre envisager un
mecanisme a 2 phases : spinlock d'abord et semaphore en cas de besoin
apres... Faudra essayer d'y reflechir.

    Thomas> [deplacer les pages physiques] il y a un soucis : on avait
    Thomas> dit (il me semble) que pour les pages PHYS_KERNEL_LOCKED
    Thomas> on ne maintenait pas les reverse mappings... Or toutes les
    Thomas> pages du noyau sont en PHYS_KERNEL_LOCKED, comment va-t-on
    Thomas> les deplacer ?

Je ne sais plus ce qu'on avait dit. Mais ca serait qd meme bien de
pouvoir deplacer les pages noyau, meme les PT (et, pourquoi pas, les
PDs...). Il faudra peut-etre tout betement changer le nom de la macro :
LOCKED deviendrait NON_SWAPPABLE tout simplement. Et dans ce cas, il
faut evidemment 1 rmapping par page noyau (y compris PT et PD).

Bonne journee,

-- 
d2