[Kos-dev] Divers

[d2]

Bonjour,

>>>>> "Thomas" == Thomas Petazzoni <thomas.petazzoni@enix.org> writes:
    Thomas> niveau du post. Par contre, juste du pinaillage, pourquoi
    Thomas> on libere le rmap pour le PT au niveau du post ? Pourquoi
    Thomas> ne pas le laisser alloue pour la prochaine fois ?  (ca
    Thomas> evite de faire un cache_free puis de nouveau un
    Thomas> cache_alloc).

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 :

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

Evidemment, vu que le post_add est le meme que post_del, on a le meme
"comportement" quand des add/del ou des del/del, plutot que add/add,
sont tres entrelaces comme dans le cas ci-dessus.

Mais, dans 99.99999% des cas, on sera dans un cas normal (ie pas comme
ci-dessus), ie on aura le spare_pt_rmap qui sera la et qui evitera de
faire le free du pt_rmap inutilisé !  Il suffit pour cela que les
vmap/vunmap ne soient pas entrelaces (ce qui sera le cas general). Car
dans ce cas, un pt_rmap qui est inutilise par un vmap/vunmap peut etre
reutilise par le vmap/vunmap qui suit -> pas de kslab_free/kslab_alloc
pour le nouveau pt_rmap : il suffit de reutiliser le spare_pt_rmap.

    Thomas> Par contre j'ai pas bien compris ou tu en etais au niveau
    Thomas> du FOREIGN PT (pour mapper une page dans l'espace de
    Thomas> n'importe quelle team). Peux-tu me le rappeler rapidement
    Thomas> ?

J'ai pas teste. C'est implante, c'est tout : ca mappe les PT d'une
autre team en local, PDE=511 (ou 510, je sais plus). Evidemment, avant
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.

Encore une fois, ce n'est pas teste. La partie chaude est celle-ci (cf
_setup_mm_ctxt()) :
  my_pd[FOREIGN_PT_AREA_INDEX] = 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) == dest_mm_ctxt->pd))

Pour le reste, les autres routines devraient etre a jour.

Samedi, j'ai l'intention de repasser sur les pbs de lock des
get/put_phys_page (utiliser un semaphore valué 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 !

Bonne journee,

-- 
d2