[Kos-dev] VMM : zero, kmem, kstack, lien avec FS

[Christophe]

----- Original Message -----
From: Thomas Petazzoni <thomas.petazzoni@utbm.fr>
To: <kos-dev@enix.org>
Sent: Friday, October 12, 2001 9:32 AM
Subject: Re: [Kos-dev] VMM : zero, kmem, kstack, lien avec FS


> >>- zero
> raw_write et raw_read sont des methodes qui doivent etre obligatoirement
> proposées par tout driver de systeme de fichiers. raw_write sert
> simplement a prendre le contenu de la memoire pour le remettre dans le
> fichier qui a ete mappe sur le disque. par exemple si on mappe un
> fichier en lecture/ecriture, qu'on y fait des modifs, puis qu'on le
> demappe, il va bien falloir mettre ces modifs quelque part.... sur le
> disque grace a raw_write.
>

OK

> le mecanisme du swapping est completement decorele de tout cela, il se
> debrouille tout seul pour prendre des pages en memoire et les foutres
> sur le disque.
>

OK

> > Pour ma part, un "team" n'est pas une tâche mais une collection de
tâches
> > ("threads") ayant les mêmes ressources et le même espace virtuel. De
fait,
> > c'est bien le "thread" qui doit recevoir l'exception "user" indiquant un
"
> > BAD MEMORY ACCESS " (à savoir, ton SIGSEGV), car lui seul en est le vrai
> > responsable du défaut de page qui n'a pu être résoulu. Les autres
"threads"
> > n'ont pas de raison d'être punis.
>
> C'est effectivement la solution qui me paraissait la meilleure... Mais
> alors il faudrait prevoir quelque chose pour que si tous les threads
> d'une team ont ete killes, la team soit killee aussi.
>

Chaque fois que tu tues un "thread", tu vérifies si le "team" auquel
appartient le "thread" n'a plus de tâches associées : tu libères le "team"
et tous les ressources qui vont avec. La suppression du "team" peut être
conditionnée, par exemple, soit par un nombre de tâche dans le "team" nul
soit par une file cyclique des tâches vide.

> > Les deux sont possibles, simplement en rajoutant un paramètre
d'allocation à
> > la fonction kvalloc pour sélectionner le comportement à suivre :
> > - la mémoire à allouer est petite et sûre d'être utilisée très
rapidement :
> > allocation immédiate.
> > - la mémoire à allouer est très grande et seule une petite partie est
> > finalement utilisée (choisie aléatoirement) : allocation "lazy" pour
mieux
> > coller à l'utilisation réelle.
>
> J'aime pas trop rajouter des parametres optionels aux fonctions, apres
> c'est chiant a comprendre comment ca marche.
> De toute facon, il est assez rare que le programmeur systeme ait a
> utiliser kvalloc, c'est plus directement kmalloc qu'il va utiliser (ou
> kslab_cache_alloc si il alloue plein de donnees de la meme taille). Et
> dans ce cas, si on rajoute un parametre a kvalloc, a partir de quelle
> taille de blocs on n'alloue plus automatiquement la page ?
> Peut etre que si le bloc fait plus d'une page, ce n'est pas la peine de
> tout mapper effectivement. C'est une idee...
>

Non tu ajoutes juste un paramètre qui indique si tu veux une allocation
immédiate ou non. J'ai vu plusieurs OS proposer cette solution. C'est le
programmeur qui décide, quelque soit la taille du bloc.

Par ailleurs ce paramètre pourra contenir d'autre mode d'allocation sans que
l'on ait besoin de modifier le prototypage de la fonction. Par exemple, dans
le cas de Linux, il y a possibilité d'allouer "atomiquement" ou non une page
(i.e, la tâche où l'allocation a lieu ne peut pas être interrompu).

Bref, plutôt que de limiter, ajoute un paramètre de mode d'allocation qui
permettra de faciliter l'ajout des modes.

Pour le moment, tu pourras priviligier une méthode, puis après l'autre si
cela s'avére aussi utile.

> David et moi avons travaille six mois sur le probleme du double fault et
> de l'agrandissement dynamique de pile au niveau noyau. Nous y etions
> presque, mais le materiel nous a battu. En effet, lorsque le double
> fault intervient pendant les pushs implicites du processeur pour entrer
> dans un handler d'irq, l'adresse ou a eu lieu le double fault n'est pas
> dans le handler d'irq, mais a l'endroit ou l'irq a eu lieu dans un
> certain thread. Ce n'est pas grave parce qu'on pouvait retrouver l'IRQ
> qui a eu lieu dans les registres du PIC, et la relancer manuellement. Or
> ceci fonctionnait bien tant que l'irq arrivait juste avant le dernier
> push implicite. Si l'irq arrive avant le deuxieme push implicite, et
> bien le registre du PIC n'est pas forcement a jour : parfois il l'est,
> parfois il ne l'est pas ? Commment savoir quelle est l'irq a relancer ?
> C'est impossible.
>

C'est dommage que je n'ai pas pu être avec vous pour "voir" tout ça, car le
PIC a plusieurs modes de programmation. Faudrait que je revois la
documentation. De tout façon, il est clair que les incertitudes liées aux
IRQ sont un frein à une solution de gestion dynamique de tâche ROBUSTE.

Quoiqu'il en soit, je n'estime pas que la gestion dynamique des piles noyaux
soit utile : l'argument, selon lequel on doit mettre en place une cuisine
assez compliquée et incertaine me suffit à ne pas le considérer dans l'OS.

amicalement,

Hlide.