[Kos-dev] Kvalloc / Kmalloc

[Thomas Petazzoni]

salut,

petit rapport sur le boulot du WE concernant Kvalloc :

	- correction de pmm.c qui permettait d'allouer la page 0, et des pages
comprises entre 0xA0000 et 0x100000 (qui on le sait sont reservees au
hardware).
	- correction de pmm.c qui plantait lamentablement quand il n'y avait
plus de memoire physique libre
	- ajout des fonctions add_new_page_of_range (qui ajoute une page pour
des ranges dans la liste) et reclaim_page_of_range (operation inverse).
a noter que maintenant les nouvelles pages ne sont plus placees en tete,
mais en queue.
	- ajout de l'allocation d'une nouvelle page avant que l'on ai plus du
tout de range disponible car l'appel a kvalloc donnerait lieu a un appel
recursif. ainsi, lorsqu'on arrive a MINIMAL_SURVIVAL_RANGE_NB (kvmem.h)
on alloue une nouvelle page pour contenir des ranges.
	- ajout de unmap_range qui demappe et libere les pages physiques
associes a un range.
	- ajout des spinlocks pour du MT-safe
	- correction de divers bugs

au niveau tests, j'ai realise les choses suivantes
	- allocation de 200 ranges de taille comprises entre 1 et 3 ou 4 pages,
puis desallocation
	- allocation de 200 ranges, liberation, reallocation, reliberation
	- allocation de 500 ranges, liberation, reallocation de 200 ranges,
reliberation. 

enfin plein de combinaisons.. et ca marche !!
cependant, il peut rester des bugs. et notre systeme de ranges stockes
dans des pages est pas parfait : il suffit qu'il reste un range dans une
page et celle ci ne peut etre libere... il n'y a pas de regroupement,
rien du tout.

mais ce qu'il faut voir c'est que la les tests on les faits sur
plusieurs centaines de ranges. en realite au max, on aura ptet je sais
pas une centaine de modules pour le noyau (ca fait 100 ranges), plus une
centaine de ranges pour d'autres trucs par exemple. bin avec tous ces
ranges, ca remplit qu'une seule page de ranges... (qui contient 255
ranges).

pour ameliorer l'allocation de ranges au sein d'une page on pourrait
envisager d'utiliser un bitmap. je l'avais fait au depart, puis en fait
ca m'avait embeter de poursuivre. disons que pour scanner 256 ranges, il
suffit au maximum de 8 bsf. alors que sinon au pire il faut 256 fois des
cmpl, des incl et des jnz (ou autre) c'est nettement plus lent. en plus
avec lib-x86 la gestion des bitmaps est plutot easy.

concernant le kmalloc j'ai defini en commentaires les nouvelles
structures a utiliser dans kmem.h. mais j'ai rien code (pas le temps
encore, j'ai deja passe des heures sur le kvalloc pour les divers bugs).

concernant globalement l'organisation du code, il faudra separer le
fichier task.c en plusieurs truc, et envisager pour kvmem.c un machin
dans l'esprit du kmem : avoir un kvalloc.c, un kvfree.c et un
kvmem_utils.c par exemple. ca serait pas mal.

question a Julien (pour l'esthetique de l'arbo) : peut-on envisager de
creer des sous repertoires dans un meme module ?

question plus large : ne devrait-on pas splitter le module mm, en module
mm, module kmem, module kvmem par exemple ? je sais pas si ca sert a
quelque chose pour des modules qui sont autant a la base du systeme.

voila pour ce WE,

amicalement,

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