[Kos-dev] Réflexion au sujet de la taille des piles utilisateurs

[Thomas Petazzoni]

Salut

Ce mail est envoyé suite à une petite réflexion que j'ai eu au sujet des
piles utilisateurs. J'envoie ça ici histoire de pouvoir le retrouver le
jour où on aura besoin de l'information nécessaire.

A l'heure actuelle, la zone USER_STACK_START, de taille USER_STACK_SIZE
(en fait de 3.5 Go à la fin de l'espace virtuel) est réservé pour UNE
pile utilisateur. Dans le handler de page fault (_vmm_as.c), on trouve :

  if(vaddr >= (USER_STACK_START + PAGE_SIZE) 
     && (vaddr <= USER_STACK_START + USER_STACK_SIZE)
     && (pf->page_present == PF_NOT_PRESENT))

Donc tout accès sur une page non présente dans cette zone occasionne
l'agrandissement de la région concernée. En fait, la région de la pile
ne fait pas 512 Mo dès le début, mais seulement une page, et elle
s'agrandit au fur et à mesure.

Avec Julien, quand on a fait ça, on était à fond dans Unix, et on avait
un peu oublié qu'on pouvait avoir plusieurs threads utilisateur et donc
nécessité d'avoir plusieurs piles. J'ai donc regardé du coté de pthread
comment ça marchait.

En gros, dans pthread, tous les threads utilisateur ont leur propre
pile, qui fait 1 Mo par défaut. On peut configurer la taille lors de la
création pour qu'elle soit plus grande (pas possible que ce soit plus
petit). 

La solution la plus simple me semble donc de réserver une zone virtuelle
(comme ce qu'on a fait), et ensuite de pondre un mini-allocateur capable
d'allouer des piles de tailles variables là dedans (avec une granularité
de 1 Mo par exemple). Faudra donc un allocateur un peu plus fin qu'un
allocateur de type bitmap. Dans un premier temps, un allocateur
first-fit de base sera largement suffisant. 

Ensuite, on créé directement une région virtuelle de x Mo qui couvre la
pile, et basta on en parle plus. La région est en MAP_ANONYMOUS, et donc
pas de soucis pour gérer la chose. Il faudra juste penser à laisser une
page de vide entre chaque région pour que ça explose si on bouffe trop
de pile.

Ce qu'on peut faire aussi, c'est que lorsqu'un #PF a lieu sur une pile,
on vérifie que le #PF est bien réalisé par le thread à qui appartient la
pile, sinon, c'est pas bien.

Voilà pour ces quelques réflexions, à conserver pour archives.

Thomas
-- 
PETAZZONI Thomas - thomas.petazzoni at enix.org 
http://www.enix.org/~thomas/ - Jabber: kos_tom at sourcecode.de
KOS: http://kos.enix.org/ - Lolut: http://lolut.utbm.info
Fingerprint : 0BE1 4CF3 CEA4 AC9D CC6E  1624 F653 CB30 98D3 F7A7
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://localhost/pipermail/kos-dev/attachments/20031111/f9817895/attachment.bin