[Kos-dev] Anonymous : pas si facile que ca

[Thomas Petazzoni]

salut,

> T'avances comme un gros fou, je vois. C'est cooooooool.

Comme un gros fou faut pas exagerer, mais oui ca avance, et
heureusement...
Je compte bien avancer encore pas mal pdt la semaine avec Julien et le
WE avec toi, afin de sortir une release sous peu.

> Pour l'histoire du map(/dev/null), j'avais propose un protocole y'a
> pas longtemps (semaine derniere ?). Ca reposait sur l'alloc d'une
> nouvelle SR en meme temps que la creation de la ressource au moment du
> open(), et ca permettait la chose suivante :

Oui, mais tu n'avais pas precise au'il faut alors faire un open sur
/dev/null pour chaque region anonyme. Ex : tu veux une region de 2 pages
a l'adresse A, et une region de 4 pages a l'adresse B, il te faut 2 sr.

>   - team A : map(/dev/null) sur VR "VA" => nouvelle ressource +
>     *nouvelle* SR "RA" (callback "open" un peu particulier pour la SR
>     dev_null_master qui cree une nouvelle SR avec chaque ressource)
>   - team A : fork => team B (=> copie VR "VA" dans AS de B => meme SR
>     "RA" pour les 2 "VA").

Jusqu'ici tout va bien.

>   - team A+team B : partagent effectivement la meme SR "RA", donc
>     partage de memoire explicite. Si tout autre team fait
>     map(/dev/null), il ne partagera *jamais* la /meme/ SR (puisqu'il y
>     aura creation d'une nouvelle SR au map(/dev/null)).

Oui et fort heuresement !

>   - est-ce que ce mecanisme de marquage reste valide sur d'autres
>     architectures ? Je pense que oui tres fortement (j'imagine mal une
>     archi sans ne serait-ce que le bit "P" des PTE).

=> oui c vrai aue si on veut rester arch independent au max faudrait
trouver une autre solution.

>   - est-ce que le modele vmm de kos ne se retrouve pas un peu bancal ?
>     Car on a alors 2 types de pages anonymous. Celles qui resultent de
>     map(/dev/null) et qui sont associees a une SR ; et celles qui
>     resultent de la differenciation par rapport a du MAP_PRIVATE et
>     qui ne sont pas associees a une SR. Voir la suite.

Ouais mais ca dans tous les cas on l'aura, regarde UVM. Les regions qui
mappent un fichier sont bien liees a un uvm_object, et les regions
anonymes a un amap.

> Ce que je craignais avec ce modele, c'est qu'on ait des problemes avec
> le partage des anonymous du type "anonymous resultant d'une
> differentiation". Mais le scenario suivant parait qd meme tenir
> debout :

Oui moi c'est ce que je crains aussi. Tant au'on a du partage en SHARED
(pas de differenciation) pas de probleme, mais alors avec le COW c'est
plus complexe.

>   - team A => map("/foobar") MAP_SHARED  => VR VA
>   - team B => map("/foobar") MAP_PRIVATE

Ok, donc les modifs de team B ne doivent pas apparaitre dans team A
(pourtant il va bien falloir commiter a un moment les trucs sur le
disque non ?).

>   - differentiation (A ou B font des #PF en write sur VA ou VB
>     respectivement). Si VA et VB se recouvrent sur la SR de "/foobar",
>     il en resulte que la zone VA se retrouve etre une succession de
>     mappings de "/foobar" original et de pages anonymous sans SR.

Oui logiaue.

>   - team A => fork() => team C : copie (ou COW) des PT + copie des VR
>     + MAJ des rmap
>   - dans ce cas, A et C mappent un melange de pages de /foobar orignal
>     presentes ou absentes de swap/RAM (mais presentes sur disque), et
>     des pages anonymous differenciees mais qui sont forcement
>     physiquement presentes (RAM ou SWAP), donc on est capable dans les
>     2 cas de gerer le partage des pages effectif (via la liste des VR
>     de /foobar, ou via le rmap).

Hum... oui, je suis pas sur de pouvoir dire "donc on est capable dans
les 2 cas de gerer".

> Je propose qu'on ait une terminologie plus precise a ce niveau pour
> nous y retrouver : "logical anonymous mapping" (ie associe a 1 SR sans
> nom cree au map /dev/null), et "physical anonymous mapping" (ie les
> pages RAM ou swap physiquement presentes et resultant de la
> differentation a cause des MAP_PRIVATE).

Et le cas ou

team A mappe en PRIVATE une region anonyme VA
team A fork pour donner naissance a team B -> creation d'une region
anonyme VB en PRIVATE, pointant sur la meme SR.

Comment va se faire la differenciation ?

Honnetementm, avoir plein de SR pour /dev/null ca me plait moyen. En
plus j'ai peur que si on envisage des cas de forks sur plusieurs niveaux
(team A => team B => team C) on ait des vieilles listes a parcourir. Je
m'explique : PF en read sur VC (region anonyme de la team C, issue du
fork de B, elle meme issue du fork de A). Alors on va chercher la page :
est-elle dans B (zou un parcours), si oui OK, sinon est-elle dans A..
Bref imagine ce aue ca va donner au bout d'un moment.

Ce probleme existait deja dans NetBSD avant UVM , et un des buts d'UVM
etait d'eviter ca....

Est-ce qu'on pourrait essayer d'avoir relu la doc de UVM pour vendredi
(pdt le train ca se fait) pour qu'on puisse causer sur une base
interessante ?

Thomas
--
thomas.petazzoni@enix.org - icq #34937744
Projet KOS : http://kos.enix.org
Club LinUT : http://club-linut.enix.org
Page Perso : http://www.enix.org/~thomas/