[Kos-dev] Divers

[Thomas Petazzoni]

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

> C'est ce qui est fait. C'est a ca que sert le spare_pt_rmap : a eviter
> de faire le free. Bref, a eviter d'etre "naif". Mais dans certains cas
> (extremement rares), il n'y a pas d'autre choix que de faire le free
> quand meme :

Effectivement, j'ai relu ton code avec plus d'attention, et c'est ce
qui est fait. Par contre, une question (peut etre bete) : pourquoi
toutes les fonctions de _rmap.c sont elles __init ?

>    thread 1                              thread 2
>     - pre_add
>     [preemption]                         - pre_add
>     - do_add                             [preemption]
>     - post_add                           ...
>       =3D> pt_rmap pre-alloue inutilise
>       =3D> remplir spare_pt_rmap
>     [preemption]                         - post_add
>                                            =3D> pt_rmap pre-alloue in=
utilise
>                                            =3D> spare_pt_rmap DEJA ut=
ilise
>                                            =3D> kslab_free a la main

Oui effectivement, dans des cas extremes comme celui la, il se peut
qu'on fasse un kslab_free, puis un kslab_alloc de trop. On pourrait
ameliorer : au lieu d'avoir seulement un spare_pt_rmap, on pourrait
avoir une liste (ca ajoute pas de spinlock t'en as deja un). Mais bon
ptet que c'est un peu bourrin... Quoique dans les cas "normaux" ca
rajoute presque pas de code : un list_add_tail c'est pas grand
chose. M'enfin bon de toute facon c'est pas vital-vital.

> J'ai pas teste. C'est implante, c'est tout : ca mappe les PT d'une
> autre team en local, PDE=3D511 (ou 510, je sais plus). Evidemment, av=
ant
> ca verifie que ce mapping n'est pas deja en place, et avant chaque
> acces aux PT (dans les vmap/vunmap/get_vpage_status), ca fait le
> invlpg qui va bien : les routines vmap/vunmap sont a jour, de meme que
> get_vpage_status.
>=20
> Encore une fois, ce n'est pas teste. La partie chaude est celle-ci (cf
> _setup_mm_ctxt()) :
>   my_pd[FOREIGN_PT_AREA_INDEX] =3D PD_ANY_TEAM(dest_mm_ctxt->pd_index=
_in_pd_table);
> et le test de "deja mappe" juste avant :
>   if ((!IS_UNMAPPED(CURRENT_PDE(FOREIGN_PT_AREA_INDEX)))
>       && (CURRENT_PDE_PADDR(FOREIGN_PT_AREA_INDEX) =3D=3D dest_mm_ctx=
t->pd))
>=20
> Pour le reste, les autres routines devraient etre a jour.

Okay, j'ai regarde ce coup de FOREIGN. Ai pas encore teste, mais je
vais peut etre essayer ce soir. Ca me semble plutot correct. Par
contre il faudrait essayer de proprifier parce qu'on a un truc
_translate_access_rights, et un truc _translate_vm_entry, qui ne font
pas exactement la meme chose, mais qu'on pourrait peut etre essayer de
rapprocher (fusionner ?). A voir.

> Samedi, j'ai l'intention de repasser sur les pbs de lock des
> get/put_phys_page (utiliser un semaphore valu=E9 sur la list des
> gpfme_free). Mais avant ca, j'ai envie de m'amuser a deplacer les
> pages physiques, et verifier que tout continue de marcher bien quand
> on deplace la page de code courante, ou la page de pile courante. Sans
> lock pour pouvoir tester plus vite d'abord. Moi aime bien faire
> joujou. Ceci dit, je ne garantis rien ni pour l'un ni pour l'autre de
> ces amusements, donc si ca te chante de t'y coller avant, vas-y !

[semaphore sur la liste des free] : je ne sais pas si utiliser un
semaphore sur la liste des GPFME est une bonne idee : les sections
critiques sont excessivement courtes et se deroulent en un temps fini
: il n'y a aucun parcours. d'autre part il me semble qu'avoir un lock
(ou semaphore peu importe) pour chaque liste est strictement inutile
etant donne que get/put_physical on besoin et de la liste des free et
de la liste des used. les fonctions de la pmm ne sont que des
fonctions qui balancent une page d'une liste a l'autre =3D> necessite
d'acquerir deux locks pour manipuler les deux listes, bof bof.

[lock sur GPFME] : AMHA, il faut un spinlock par GPFME pour proteger
l'insertion de plusieurs rmap sur une meme page physique en meme
temps. apres le probleme c'est que pmm lui acquiert des locks globaux
au niveau des GPFME (pour toutes les listes), et modifie pourtant les
GPFME.. bref je sens qu'il va y avoir un probleme !

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

[rmap PTs] tu crois vraiment que le champ   rmap->index_pte  =3D va_to_=
pte(virt);
 a un sens lorsque l'entree de rmap correspond a un PT (is_pt =3D TRUE)
 ?=20

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