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

[Thomas Petazzoni]

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

> Le probleme, c'est de savoir si une autre virtual region que celle de
> team fautif est concernee. C'est ca ? Histoire de mettre a jour tous
> les address-spaces *concernes* a jour, et seulement ceux-la ? Le
> probleme etant alors d'identifier ces address-spaces reellement
> /concernes/. 

Oui voila exactement le probleme qu'il faut resoudre et pour les zones
anonymes et les zones mappant un fichier "normal".

 
> Je pense pas que ca doive etre tres fin. Si je me souviens bien de nos
> tests mmap() qu'on avait menes, on remarquait que si 1 processus A
> mappait /foobar en SHARED d'un cote, et qu'un autre processus B (avec
> OU sans aucun lien de parente) mappait lui-aussi /foobar en SHARED, on
> voyait que B voyait les modifs faites par A. Ce qui suggere que des
> qu'il y a SHARED des 2 cote, et des que les zones du fichier mappe se
> recouvrent, il y a partage des pages physiques. Donc si la sr est
> mappee dans A avec la virtual_region VA, dans B avec VB, C/VC, D/VD,
> tels que VA=VB=V1, VC=VD=V2 (en terme de pointeur vers
> shadow_resource, resource_offset et de longeur de virtual_region
> seulement), si un #PF arrive pour A dans VA, alors la sr regarde
> quelles virtual regions en SHARED recouvrent l'offset resource ou il y
> a eu le #PF => elle trouve seulement VB, et donc ne s'interesse qu'a
> mapper la page dans B.

Non, non et non ! Et justement tout le probleme est la !

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

Avec les objets actuellement en place, cela me semble tout simplement
impossible.

> Je pense que le cas mmap(/dev/null) est un peu atypique et ne repose
> pas sur une shadow ressource unique globale au systeme. De mon point
> de vue, a chaque fois qu'un team mmap(/dev/null), ca cree une nouvelle
> shadow resource speciale dedicace pour le team qui fait le mmap. Qd ce
> mapping est shared, c'est cette shadow resource nouvellement allouee
> qui est partagee entre pere et fils (pluriel), et le mecanisme
> ci-dessus s'applique sur cette nouvelle sr. Qd c'est un fichier autre
> que /dev/null, la par contre, il y' a bien 1 seule shadow ressource
> pour tout le systeme, et le mecanisme ci-dessus s'applique (partage
> des memes pages physiques meme si les 2 processus n'ont aucun lien de
> parente).

Ca peut effectivement etre une solution, mais je ne sais pas si elle
suffit veritablement, il me semble qu'il va manquer un "etage" dans
notre hierarchie d'objets. Exemple :

Soit un processus A, ayant une VR anonyme VA, mappee en
MAP_PRIVATE. Ce processus A forke, pour donner naissance au processus
B, qui mappe  une VR anonyme VB, mappee en MAP_PRIVATE.

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

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

Je sais bien que le cas de /dev/null est atypique, mais au final je me
demande si nous ne sommes pas obliges de passer par une solution ala
UVM ou SVR4 avec une gestion de la memoire anonyme.

Je sais bien qu'on avait dit que c'etait pas la peine, et je vais
m'attacher ce WE a retrouver des mails, des comptes rendus de WE
expliquant le pourquoi du comment on pensait que c'etait pas la peine.

Mais la, texto si vous relisez le chapitre "Anonymous Memory"
(chapitre 5 je crois) de la these sur UVM, vous allez vous rendre
compte qu'il doit manquer quelques elements dans notre VMM.

> Qd c'est du MAP_PRIVATE par contre, ca doit juste rajouter 1 etape :
> tant que c'est des #PF en read, on mappe la shadow_resource comme
> ci-dessus. Des le 1er #PF en write, on supprime la sr pour la
> remplacer par une sr type /dev/null ("anonymous"), et on n'agit plus
> que sur celle-ci (en ne recreant pas une sr /dev/null au prochain #PF
> write bien sur).

Oui mais si t'as un #PF en write, tu vas mapper une nouvelle page,
contenant le contenu de l'ancienne page (de l'ancien processus). Mais
tu peux aussi chopper d'autres #PF en read, et donc vouloir la
partager avec l'ancien processus (tant qu'il a pas fait de #PF en
write). Et vu que on recopie pas forcement les PD/PT a la creation du
processus (par fork()), je vois pas comment tu peux retrouver ca avec
deux sr pour /dev/null.

> Voila mon point de vue, fortement inspire de la norme posix. Reste a
> savoir si cette norme nous convient.

Et la norme s'en sort avec ca ?

Honnetement, je ne suis pas sur de ce que j'avance, et je ne me veux
pas etre un expert en VMM, loin de la, mais j'ai franchement
l'impression qu'il manque des objets entre virtual region et shadow
resource dans KOS.

Dans UVM, pour les fichiers normaux ca s'appelle uvm_object, et pour
les regions anonymous ca s'appelle amap.

Bonne fin de journee,

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