[Kos-dev] Piles niveau noyau, gestion du fork()

[Thomas Petazzoni]

Salut,

Trois aspects dans mon mail :

Aspect 1 :

J'ai finalement au le temps de lire la doc sur l'utilisation de
"continuations" dans Mach pour l'implementation des threads. Plusieurs
choses ressortent de ce document :
 - tout d'abord Mach 3.0 MK32 est capable de swapper les pages des piles
noyau. Je ne sais pas si cela est verifie pour toutes les architectures,
mais toutefois pour MK32 c'est possible.
 - dans MK40, le principe des continuations a ete implemente. Il a
permis de reduire le nombre de piles noyau a une par processeur, plus
une pour un thread noyau indispensable. En gros le principe de base
c'est que la plupart du temps tres peu de piles noyau sont utilisees.

A mon avis, il faudrait deja voir comment dans MK32 le swapping des
piles noyau a ete fait, puis si cela n'est pas possible sur x86 voir
peut etre pour les continuations. Ceci etant dit, ils ont reussi a
reduire autant le nombre de piles noyau parce que leur noyau n'est pas
preemptif (apparemment, sinon je vois pas comment ca peut marcher).

Aspect 2 :

Une team A forke. Creation d'une team B. La team B fait un #PF sur une
page (que ce soit read ou write). Comment va-t-elle savoir si cette page
etait mappee par la team A, ou si elle est dans le swap (parce qu'elle
avait ete mappee auparavant par la team A). Avec les structures de
donnees actuelles, ceci implique un parcours de l'ensemble des virtual
region qui mappent une SR pour en trouver qui eventuellement dit quelle
est la page physique a utiliser ou bien ou elle se trouve dans le swap.
Cette technique me semble pas terrible.

Je trouverais mieux d'avoir dans chaque SR un tableau de pointeurs. Le
pointeur pointe soit un gpfme, soit sur une structure decrivant une page
swappee (genre gsfme = global swapped frame map entry). Vu que ces
structures sont alignees sur 4 octets, on peut utiliser les 2 bits de
poids faibles pour dire si l'adresse est celle d'un gpfme ou d'un gsfme.

Bien entendu, si la SR s'agrandit, c'est un peu chiant, mais je pense
que le nombre de fois ou la SR s'agrandit est tres petit par rapport au
nombre de fois ou on aurait a parcourir la liste de l'ensemble des
virtual region.

Je precise que la solution qui consisterai a regarder dans le pere si la
page est mappee ne fonctionne pas, car :

Team A -> creation page 2.
fork() -> Team B
          fork() -> Team C
                    Team C -> #PF sur page 2.

Dans cet exemple la page 2 est pas dans le pere de la team C, mais dans
le grand pere. Et on va pas s'amuser non plus a traverser l'ensemble de
ses peres/grands-peres.

A noter qu'il va falloir serieusement reflechir aux problemes de lock :
la vmm va utiliser les SR d'une part, et babel d'autre part (cf le
bordel pour bbl_open_sr).

Aspect 3 :

Un dernier aspect, que j'ai rapidement aborde avec Julien au telephone
hier. Pour l'instant dans le noyau, on utilise partout des spinlock.
Mais je me demande si finalement ca diminue pas la reactivite du
systeme, parce que l'on desactive les interruptions. Si on utilisait des
semaphores, alors pas besoin de desactiver les interruptions, et donc on
peut encore se chopper des IRQs pendant un traitement, ce qui augmente
la reactivite du systeme. 

Exemple typique : on parcourt l'arbre des SR (la fameuse bbl_open_sr),
pendant tout le temps du parcours les interruptions sont desactivees
(spinlock de partout) alors qu'on pourrait tres bien gerer une
interruption clavier qui arrive par exemple !

Je sais pas si l'exemple ci dessus est encore valable, parce qu'avec le
rewrite de d2 de bbl_open_sr il me semble qu'on utilise moins de lock,
mais plutot un compteur de ref (equivalent a une semaphore en gros).

Voila qu'en pensez-vous ? (surtout de l'aspect 2)

Thomas




--
PETAZZONI Thomas - icq #34937744
thomas.petazzoni@enix.org - http://www.enix.org/~thomas/
Projet KOS : http://kos.enix.org
Club LinUT : http://club-linut.enix.org