[Kos-dev] Memoire : objet physique, range...

Thomas Petazzoni kos-dev@enix.org
Tue, 15 May 2001 19:23:35 +0200


salut,

je viens de regarder a nouveau les sources de kos, et je m'apercois
qu'il reste dans pmm.h une bete que l'on avait appele physical_object_t,
destinee a regrouper les pages physiques par objet. nous voulions creer
un arbre de GPFME (descripteur de page physique), comme le montre les
pointeurs left et right de la structure gpfme_t, definie elle aussi dans
modules/mm/pmm.h

je pense que l'utilite de ces choses est absolument nulle : en effet
nous desirons dissocier au maximum la gestion de la memoire physique de
la gestion de la memoire virtuelle. les seuls liens existants sont :
	- dans le sens virtuel --> physique : les PTE
	- dans le sens physique --> virtuel : une sorte de liste chainee, qui
reste a implementer, qui permettrait de chainer toutes les adresses
virtuelles mappant une adresse physique donnee (a faire au moment d'un
map_virtual_to_physical), afin de pouvoir swapper ou deplacer une page
physique tranquillement.

d'autre part, nous avons parle avec david d'uniformisation du systeme de
range. les regions decrivent de larges espaces reserves, par ex 512-768M
pour le kernel, 0-256M pour l'identity mapping, mais il faudrait ajouter
un systeme de range qui permettrait au handler de page fault si oui ou
non l'adresse fautive a bien ete allouee.

pour l'instant le fonctionnement de ces ranges reste a reflechir. david
avait pense a un machin du style : **sub_ranges dans la structure
virtual_region_t, qui permettrait de faire pointer ca soit vers les
ranges d'un kvalloc, soit vers les ranges d'un autre allocateur.

il faut y reflechir. personnellement, je suis pour l'instant plutot
contre parce que je n'en vois pas la vraie utilite. mais peut etre
que... bref, ceci reste a voir.

j'aimerais vraiment que l'on avance avec cette gestion de la memoire.
examinons ce qu'il nous reste a faire :
	- finir (tester) le kvalloc
	- amenager le kmalloc pour qu'il alloue en virtuel grace a des listes
chainees de kmem_page_t, au lieu de listes chainees de gpfme_t.
	- faire prendre en compte par le handler de page fault les subtilites
du kvalloc, soit par un systeme de range comme prevu par david, soit par
un systeme plus simple, qui fait un cas special en fonction du type de
chaque region virtuelle.
	- faire un allocateur de pages virtuelles pour la zone utilisateur. je
ne sais absolument pas comment s'y prendre, mais de toute facon, il
faudra bien faire un sbrk un jour...
	- synchronisation des PDE du noyau entre toutes les teams.

une fois qu'on aura fait ca, je pense que la gestion memoire sera bien
avancee. les points 1 a 3 peuvent etre realises a assez court terme, je
vais essayer de travailler dessus dans les semaines qui viennent (avec
julien a l'ascension ?), les deux derniers points etant des vues plus
sur le long terme (mais pas trop quand meme).

voila,

amicalement,

thomas
	
-- 
PETAZZONI Thomas
thomas.petazzoni@meridon.com     UIN : 34937744
Projet KOS : http://kos.enix.org
Page Perso : http://www.enix.org/~thomas/