[Kos-dev] Gestion de la memoire virtuelle : pour y voir plus clair

[d2]

Hello,

Tout ca me parait clair. Ca meriterait de completer le draft-0, voire
de donner naissance a un draft-1.

>>>>> "Thomas" == Thomas Petazzoni <thomas.petazzoni@ifrance.com> writes:
    Thomas> fichier incrimine dans cette page.  Si le mapping est de
    Thomas> type MAP_SHARED (partage entre les fork()), la premiere
    Thomas> tentative d'ecriture provoquera un COW (Copy on Write),
    Thomas> les autres tentatives d'ecriture se feront sur la meme
    Thomas> page quelque soit le thread realisant l'ecriture. Probleme
    Thomas> : comment gerer la consistence dans ce cas la ?

Avec ton mecanisme d'"inverse lookup" des pages virtuelles a partir
des pages physiques (cf fin du mail), ca doit pas trop poser de
probleme.

A noter que si, a partir d'une page physique, on ne remonte que vers
des pages virtuelles MAP_SHARED, on n'a meme pas besoin de faire de
COW : il suffit de passer les pages virtuelles associees en mode
"ecriture autorisee" des le premier page fault.

A noter aussi qu'on doit se poser la meme question de la consistance
lorsqu'une page passe de MAP_SHARED a MAP_PRIVATE dans une des teams :
il faut dans ce cas passer les pages virtuelles associees a la page
physique en read-only et le prochain acces en ecriture provoquera un
COW.

    Thomas> Voici son boulot : pour chaque page physique, il parcoure
    Thomas> la liste de ses mappings en memoire virtuelle, si la page
    Thomas> physique a ete accedee, elle est ramenee au debut d'une
    Thomas> liste des pages physiques. Sinon elle reste a sa place. Ce

Cote vocabulaire, ca s'appelle "mecanisme LRU" (Last Recently Used).

    Thomas> Le swapper pourra prendre en compte le nombre d'acces a
    Thomas> des pages (nombre de fois que le bit Accessed a ete mis a
    Thomas> 1) pour permettre d'optimiser la repartition des pages
    Thomas> entre le swap et la memoire physique.

Tu veux dire que ce serait un 2eme mecanisme (appele "aging" si je ne
m'abuse) redondant avec le LRU ?

    Thomas> Pour que le swapper puisse fonctionner, et qu'on puisse
    Thomas> demapper et remapper des pages physiques en virtuel, on va
    Thomas> maintenir une liste chainee des mappings d'une page
    Thomas> physique.

Ca me parait correct.

Pour un eventuel draft-1, tu pourrais introduire a quoi sont relatifs
ces segments : la def des "address spaces". Peut-etre, pour situer les
choses, le schema figure 1 page 3 de SunOS Virtual Memory
Implementation est une bonne intro (juste le "Unix System Calls and
Services" pas tres clair => preciser qu'il s'agit de teams).

Sinon, peut-etre quelques remarques sur la terminologie : definir la
notion de mapping anonyme. Et la notion de backing store utile pour
les decision de swapin/out.

Bonne journee,

-- 
d2