[Kos-dev] kvalloc
d2
kos-dev@enix.org
04 May 2001 13:55:55 +0200
Bonjour,
Reprenons. Le point delicat est le cas ou ma zone a allouer ne peut
rentrer que dans un range plus grand (strictement). Dans ce cas, je
suis oblige de splitter ce range en 2. Puisque j'avais 1 range a
l'origine, et que je me retrouve avec 2 ranges maintenant, il faut
donc allouer une structure struct range qqpart.
Pour ca : soit j'ai encore la place suffisante pour un autre struct
range dans une des pages physiques qui contiennent les autres struct
range, auquel cas l'allocation consiste a un ajout tout bete d'un
nouveau struct range dans cette page. Soit j'ai plus de place, et il
faut que :
1/ J'alloue une page physique
2/ je mette un struct range pour rajouter un range destine a ne
contenir que des struct range : je met ce "range_range" (aka
"meta_range" par la suite) precisement dans cette nouvelle page
3/ Maintenant : j'ai etendu ma zone destinee a ne contenir que des
struct range : je peux donc ajouter dans cette meme page
physique, et a la suite du meta_range precedent, le struct range
que je desirais allouer.
C'est le principe de la partie delicate de l'algo.
Le pb de l'algo que j'ai propose, c'est que la recherche de place pour
un nouveau range_range a allouer ne considere que ce qui est
(physiquement) apres la queue dans la page physique de cette queue ;
ie le dernier range_range : (range_marques_free).tail. Il serait plus
judicieux de prendre un struct range libere (suite a un merge) dans la
liste des range_range, sinon on court a la fuite de memoire. Ca
suggere donc de rajouter un flag dans struct range : int meta_range,
positionne a 1 quand le range considere est un meta_range. La
recherche d'un struct range disponible se fait alors en parcourant la
liste des range_marques_used, a la recherche de struct range pour
lesquels meta_range est a 1, et a scanner chacune des pages physiques
de ce range_range a la recherche de ranges pour lesquels (par exemple)
nb_pages == 0. Bref, cette partie est a revoir. Mais tel que c'est, ca
devrait marcher.
D'autre part, y'a un bug (au moins) dans l'algo : il concerne un
commentaire. Quand j'ecris :
// #PF or map_to_physical manual
new_range_range->start_address = (addr_t) new_range_range; // self
new_range_range->nb_pages = PREFERRED_RANGE_RANGE_SIZE;
.. en fait, on n'a pas le choix : il *faut forcement* faire le
map_to_physical, puisque si on attend le #PF, comme le #PF aura lieu
alors que le range n'est pas cree, ca entrainera un "page doesn't
belong to us".
Bonne journee,
--
d2