[SOS] Virtual Memory Manager

[KAISER Edouard]

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/