[SOS] Virtual Memory Manager

Jeu 4 Aou 20:00:55 CEST 2005

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 256 bytes
Desc: OpenPGP digital signature
Url : http://the-doors.enix.org/pipermail/sos/attachments/20050804/4005e541/signature.pgp