[SOS] Virtual Memory Manager

Mar 9 Aou 10:25:55 CEST 2005

Encore moi =)
J'ai un peu cogité à tous ça et surtout le concept de la mémoire
virtuelle : deux processus peuvent utiliser une même adresse qu'on
désignera virtuelle mais qui pointeront vers deux adresses physiques
différentes via une table de traduction.
Personnellement je n'active pas la pagination, je me contente donc de
la segmentation, donc la gestion va vraiment etre différente de SOS.
De ce fait, arréter moi si je me trompe, tout mon système de gestion
des processus sera basé sur les mécanismes de segmentation que me
propose l'archx86.
J'ajouterais et insérer des descripteurs selon les processus qui
doivent etre élu ou stopé non ?
Le mécanisme de traduction se fera par la MMU qui a partir des
selecteurs de descripteurs de segment pourra transformer l'adresse
virtuelle en adresse physique selon la base et la limite du
descripteur de segment pointé ?
Enfin voila, j'ai juste besoins de savoir si je vois juste, et comment
je dois envisager cette partie en sachant que je ne souhaite pas me
servir de la pagination ! =)
Merci à tous pour avoir pris le temps de lire.

Le 05/08/05, KAISER Edouard<edouard.kaiser at gmail.com> a écrit :
> Merci pour tout, maintenant j'y vois un peu plus clair. L'analogie
> férovière est excellente personnellement, tu devrais la garder pour
> tes futurs articles !
> J'ai une autre question, mais rien à voir avec le code ;) Je vais
> lancer un autre sujet.
> Merci à tous.
> 
> Le 04/08/05, Thomas Petazzoni<thomas.petazzoni at enix.org> a écrit :
> > Salut !
> >
> > [ Je réponds à partir de mes souvenirs sur le code et les articles. Je
> > n'ai pas revérifié le code, donc j'espère que je ne vais pas me gourer
> > sur la terminologie. Si je dis des bétises, corrigez moi ]
> >
> > KAISER Edouard a écrit :
> >
> > > SOS permet si j'ai bien compris d'allouer des "régions" dans la
> > > mémoire. Cependant j'ai du mal à saisir l'utilité de ces régions que
> > > vous appellez "range". Les régions contiennent elles les caches qui
> > > eux meme contiennent les slabes qui pour finir contiennent une liste
> > > d'objet ? J'ai du mal à saisir la hiérarchie et ce qu'il se passe
> > > réellement.
> >
> > La zone de mémoire réservée au noyau est découpée en régions appelées
> > «ranges». Un allocateur permet d'allouer et de libérer des «ranges» de
> > mémoire dans cette zone de mémoire. Il permet donc d'allouer des régions
> > d'une taille multiple de la taille d'une page (4 Ko, 8 Ko, 12 Ko, 16 Ko,
> >  etc...). Ce premier allocateur est implémenté dans sos/kmem_vmm.c.
> >
> > Un autre allocateur, complètement séparé (mais reposant sur le
> > précédent) est implémenté dans sos/kmem_slab.c. Il repose sur le
> > principe des slabs présenté in-extenso dans l'article que tu trouveras
> > sur le Web ou dans le papier de Jeff Bonwick.
> >
> > Disons que le «cache» est un train. Ce train contient un ensemble de
> > rames (plusieurs wagons accrochés ensemble), ce sont les «slabs». Une
> > rame contient un certain nombre limité de personnes, les «objets».
> >
> > Lorsqu'il n'y a plus assez de place (plus assez de personnes, plus assez
> > d'objets) dans ton train (cache), tu dois rajouter une rame (slab). Pour
> > rajouter cette rame, tu dois rajouter un certain nombre de wagons (les
> > pages). Vu que tes rames font 4 wagons, tu alloues 4 wagons (4 pages),
> > et tu les accroches à ton train (ton cache). Et hop, tu peux mettre plus
> > de personnes (allouer plus d'objets).
> >
> > Bon, je sais pas si mon analogie ferroviaire est heureuse, mais tant
> > pis, je la laisse ;-)
> >
> > Prenons un exemple. Tu créés un cache pour stocker des objets de 64
> > octets. Au départ, le cache est vide, il ne contient pas de place pour
> > allouer des objets.
> >
> > Tu veux allouer un premier objet depuis le cache. Vu qu'il n'y a pas
> > assez de place, on doit rajouter un slab, c'est à dire un ensemble de
> > pages. La configuration a déterminé qu'on utilisait 2 pages par slab. On
> > demande donc à l'allocateur de ranges décrit plus haut 2 pages de
> > mémoire. Ensuite, on va découper ces 2 pages (donc 8192 octets) en 128
> > objets de 64 octets. Et on va te retourner un pointeur sur l'un deux.
> > Voilà, tu as alloué 64 octets ;-)
> >
> > Dans notre exemple, notre cache va contenir un certain nombre de slabs
> > (qui va varier au fil des allocations/libérations) qui eux-mêmes
> > correspondent chacun à deux pages, découpées en 128 objets de 64 octets.
> >
> > (La réalité est un peu plus complexe: sur les 8192 octets, on se garde
> > un peu de place pour mettre des structures de contrôle de l'allocateur,
> > donc on ne disposera que de 127 ou 126 obets de 64 octets.)
> >
> > > En fait le concept de la pagination me perturbe, surement pour rien,
> > > mais bon...
> >
> > C'est normal. La première fois que j'ai eu à comprendre la pagination,
> > ça m'a pris 6 mois !
> >
> > > Imaginons que SOS n'active pas la pagination et se contente de la RAM
> > >  disponible, nous avons donc une adresse linéaire qui devient
> > > directement une adresse physique (si la base du segment dans la GDT
> > > est à 0 bien sur). Le VMM va donc découper la RAM en régions ?
> >
> > Ici ce n'est pas une question de VMM en fait, car peu importe qu'il y ai
> > de la gestion de mémoire virtuelle ou non pour comprendre les
> > allocateurs du noyau. Le nom kmem_vmm.c pour l'allocateur par ranges est
> > à mon avis un peu mal choisi.
> >
> > > Ces
> > > régions qui seraient donc logiquement plus grande que 4Ko, vu qu'on
> > > gerait deja la mémoire en page de 4Ko, contiendraient les caches
> > > caractérisés par une taille d'objet précise. Et on retrouverait
> > > dedans les slabs. Pourquoi dans les régions ne pas directement
> > > stockées un slab qui est déja une structure qui contient une liste
> > > d'objet de taille précisé dans la description du slab ?
> >
> > Les deux allocateurs sont bien indépendants. Je pense avoir donné les
> > explications ci-dessus pour répondre à cette question et aux autres que
> > tu posais. Si ce n'est pas le cas, n'hésites pas à redemander des
> > précisions.
> >
> > Thomas
> > --
> > PETAZZONI Thomas - thomas.petazzoni at enix.org
> > http://thomas.enix.org - Jabber: thomas.petazzoni at jabber.dk
> > KOS: http://kos.enix.org/ - SOS: http://sos.enix.org
> > Fingerprint : 0BE1 4CF3 CEA4 AC9D CC6E  1624 F653 CB30 98D3 F7A7
> >
> >
> >
> >
> 
> 
> --
> KAISER Edouard.
> Wiki-Blog : http://kaiser.edouard.free.fr/
> BesOS : http://besos.mtp.epsi.fr/
> 

-- 
KAISER Edouard.
Wiki-Blog : http://kaiser.edouard.free.fr/
BesOS : http://besos.mtp.epsi.fr/