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

[d2]

>>>>> "Thomas" == Thomas Petazzoni <thomas.petazzoni@enix.org> writes:
    Thomas> Dans la sr, il y a la liste de TOUTES (absolument toutes)
    Thomas> les virtual region mappant completement ou partiellement
    Thomas> cette sr. Donc ici si on a un #PF sur A, on va trouver non
    Thomas> seulement VB dans la liste, mais aussi VC et VD... Et
    Thomas> comment savoir qu'il faut mettre a jour VB et pas VB ni VD
    Thomas> ?

A mon avis, le probleme existe bien. Mais je le vois ailleurs. On va
essayer d'aller le plus loin possible dans "un" algo, jusque la ou ca
coince.

On s'interesse d'abord au #PF (distinction read/write => plus loin) du
team curant sur une de ses VR qui est *MAP_SHARED*.  Dans toute la
suite, ce sont les VR "RW" qui m'interessent (pour les VR RO, un #PF
dessus, c'est soit map() de la SR si c'est un #PF read, soit SEGV si
c'est un #PF write).

Au moment du #PF, on connait l'offset dans la SR sous-jacente ou le
#PF a lieu (puisqu'on connait la team courante, la VR concernee par le
#PF, et la SR qui est dessous) : appelons le "pf_offs" (et
"SR:pf_offs" la zone dans la ressource associee). Sur la SR, on a la
liste des VR des autres teams qui la mappent en MAP_SHARED et en
MAP_PRIVATE. Les VR des autres teams qui nous interessent ici sont
uniquement celles qui recouvrent SR:pf_offs (=> cf le calcul ds le
mail precedent). On ne s'occupe pas des VR de de la liste qui ne
recouvrent pas SR:pf_offs. La derniere fois, j'avais pas distingue #PF
read/write.

Si le #PF est read, pour les VR de la SR qui recouvrent SR:pf_offs, on
mappe la SR (methode map()) : partage de la page pour tout le monde,
VR MAP_PRIVATE et MAP_SHARED confondues. Ce partage doit etre RO pour
tout le monde dès qu'il y a au moins un MAP_PRIVATE dans le tas (pour
differentiation plus bas), RW sinon.

Si le #PF est write, la on a 2 possibilites : soit elle etait deja
mappee RO avant, soit elle l'etait pas. Si elle l'etait, il y'a
differenciation => COW pour nouveau mapping RW soit du cote des
MAP_SHARED (MAP_PRIVATE inchangees) ; soit du cote de chacune des
MAP_PRIVATE independamment (MAP_SHARED inchangees) => choix a voir. Si
elle n'etait pas encore mappee, alors on ne la mappe que du cote des
MAP_SHARED (qui recouvrent SR:pf_offs bien sur) et on laisse les
MAP_PRIVATE non mappees.

Si le #PF a lieu dans un VR *MAP_PRIVATE* du team courant, il y'a
differenciation quoi qu'il arrive (COW sur page propre si #PF write,
map() sur page propre si #PF read).

La ou effectivement il y a un hic, c'est au niveau du "COW". En effet,
le COW amene a avoir au sein d'une meme VR : quelques pages de la SR
non encore differenciees (ie reellement associees a la SR), *ET*
quelques pages anonymous (ie plus liees a la SR du tout). Donc on peut
potentiellement se retrouver avec une meme VR, mais pour laquelle la
SR originale est par morceaux, les trous etant du "anonymous". Et la,
je suis d'accord, il y'a une couille dans le modele.

Non pas pour le COW lui-meme. Puisque techniquement, le rmap suffit a
recuperer les differents teams concernes par un COW. C'est d'ailleurs
la que la notion de SR "anonymous" disparait dans kos : elle est
remplacee par le rmap.

MAIS la ou le modele *reste* incomplet c'est qd il y aura du swap. Si
on a un #PF, comment donc distinguer entre un #PF sur la SR originale,
ou sur une anonymous swappee ? La, je vois effectivement un reel
probleme.

    Thomas> Va-t-on recopier des le fork() tous les PD/PT de cette
    Thomas> virtual region ? C'est peut etre un peu bourrin.  D'apres
    Thomas> toi, on aura cree une sr pour chacun des processus. Mais
    Thomas> quand le processus B va faire un read PF sur la VR VB, il
    Thomas> va falloir qu'on choppe la page dans la region VA
    Thomas> (puisqu'on a pas recopie les PD/PT, et dans la mesure ou
    Thomas> la region VA ne l'a pas modifie entre temps). Et avec
    Thomas> cette histoire de duplications des sr de /dev/null ca me
    Thomas> semble pas possible

Ca, c'est le pb du partage de PT, plutot qu'un pb de SR, non ? On
n'avait pas des masses reflechi la-dessus, a part peut-etre la
solution qui consiste a passer tous les PT user pere/fils en RO au
moment du fork, et a gerer les COW sur les PT.

Parce que pour le reste (on imagine qu'on recopie PD/PT en lazy par
COW, ou sur page propre facon bourrin), au fork on doit transformer
les pages de VR MAP_PRIVATE en RO pour pere ET fils. Et le premier qui
fait un #PF write, on lui fait un joli COW (cf remarque ci-dessus), et
soit 1/ y'a 1 seul "autre", on passe le mapping de l'autre en RW (si
il s'agit bien d'un R/W) ; soit 2/ il y'a plus de 1 (strict) "autres",
on leur laisse le mapping en RO.

    Thomas> Autre probleme : il va falloir plus d'une sr par
    Thomas> processus, parce qu'il peut y avoir plusieurs regions
    Thomas> anonymes differentes par team. Bref on va vers une
    Thomas> multiplication des sr /dev/null alors qu'il etait entendu
    Thomas> que l'objet sr devait etre unique.

Avec le modele actuel y'a effectivement un pb de coherence avec les
"anonymous", puisqu'on peut avoir a la fois des morceaux de la vraie
SR originale, *et* une serie d'anonymous au sein de la meme VR (cas
d'une VR MAP_PRIVATE). [bis] Si on a un #PF, comment donc distinguer
entre un #PF sur la SR originale, ou sur une anonymous swappee ? La,
je vois effectivement un reel probleme.

Est-ce que j'ai encore tout compris tes questions de travers ? Est-ce
que je viens de soulever le meme probleme que toi ? Ou est-ce que les
problemes n'ont absolument rien a voir ? Ou suis-je encore
complètement bouché ?

-- 
d2