[Kos-dev] Commentaires sur draft-0

[Hlide]

Comment puis-je avoir accès à ce draft ?

----- Original Message -----
From: Thomas Petazzoni <thomas.petazzoni@ifrance.com>
To: <kos-dev@enix.org>
Sent: Sunday, June 24, 2001 4:53 PM
Subject: [Kos-dev] Commentaires sur draft-0


> salut,
>
> une pause pdt mes petites revisions pour les examens m'a permis de
> relire plus attentivement le draft-0 proposé par d2. j'ai donc plusieurs
> questions concernant ce papier :
>
> Page 2, section 1.1.3 : "Cependant malgre l'aspect preemptif du systeme
> du point de vue utilisateur, avec les Unix classique, et en UP toujours
> : une fois en mode noyau, le thread courant s'execute jusqu'a ce que le
> noyau passe la main (blocage sur ressource). Cet aspect multitache
> cooperatif..."
>
> -> Dans KOS, un thread noyau peut tout a fait etre interrompu par le
> timer, et un autre thread (noyau ou utilisateur) peut etre execute. En
> somme les threads noyau ou utilisateur sont considérés comme des entites
> tres similaires, et dans les 2 cas, le multitache est preemptif me
> semble-t-il...
>
> Page 3, section 1.1.3 : "La propriete de reetrance est facile a obtenir
> : il suffit d'interdire des fonctions du type struct passwd
> *getpwuid(uid_t uid), caractérisés par le fait que le résultat retourne
> est implicitement alloué par le compilateur sous forme d'une variable
> globale".
>
> -> Je ne comprends pas bien ton explication concernant ce type de
> fonction et l'allocation implicite faite par le compilateur. Pourrais-tu
> expliquer un peu de plus de manière a ce que je comprenne pourquoi cela
> est genant pour la reentrance ?
>
> Page 3, Section 1.2.1 : "Pour interdire tout deadlock sur le processeur,
> il est nécessaire que test+boucle soient protégés par un
> masquage/retardement des interruptions locales".
>
> -> Je suppose que le deadlock d'un processeur correspond a un etat dans
> lequel le processeur se retrouve completement bloque (par un mauvais jeu
> de spinlock). Mais je comprends pas bien ta condition necessaire (et
> apparemment suffisante) pour que ces deadlocks n'apparaissent pas....
>
> Page 3, Section 1.2.2 : "Cependant, ce mécanisme de files d'attente est
> difficilement compatible avec la notion d'interruption : il est hors de
> question de mettre le traitement d'une ISR dans une file d'attente pour
> réveil a plus tard".
>
> -> Tu devrais preciser que pourtant c'est ce qu'on fait avec les bottom
> halves, mis a part que tout le traitement n'est pas remis a plus tard.
> Ce qui essentiel (mise de cote de donnees critiques...) est effectue de
> suite, le reste est deporte a plus tard. Ce passage est donc un peu
> ambigu, non ?
>
> Partie 1.3.1 : effectivement la solution des bottom halves me parait
> plus appropriee, et c'est d'ailleurs celle utilisee dans Linux et dans
> d'autres OS... c'est qu'elle est surement valable. N'utiliser que les
> spinlocks risque de provoquer une chute de performances assez terrible.
> On pourrait donc imaginer un pool de threads reserves a l'avance, qui
> pourrait etre associes rapidement a un traitement d'interruption donne.
> Peu importe le mecanisme exact, mais j'aimerais que dans la mesure du
> possible, les bottom halves ne constituent pas une nouvelle entite,
> differente du thread noyau.
>
> Partie 1.3.2 : tu pourrais aussi preciser que le task switch qu'implique
> l'utilisation de task gate entraine un certain surcout. d'apres les
> mesures que j'avais effectue, il etait moins grand que prevu, mais je
> pense qu'il etait au moins de 15 ou 20%.
>
> Partie 1.4 : content de voir que nous sommes d'accord concernant
> l'utilisation de bottom halves, ou equivalent.
>
> Partie 2.1 (page 7) : ta volonte de reduire la section gardee par
> cli/sti rejoint la volonte de creation de bottom halves. En effet, le
> vrai handler d'interruption, lui est ininterruptible, et ses seuls roles
> sont :
> - conserver de cote les donnees utiles.
> - demander un thread dans un pool pour y placer son bottom half.
>
> Ce bottom half quant a lui, sera interruptible. Donc en fait ca revient
> a reporter le maximum des traitements dans une partie interruptible, le
> bottom half.
>
> Toutefois, je ne saisis pas bien le mecanisme d'IPL que tu decris
> pendant une page. Je pense que tu devrais etre plus precis concernant
> les interruptions dont tu parles. Parles-tu uniquement des IRQs (ce doit
> etre le cas, tu parles de EOI, etc...), ou de toutes les interruptions y
> compris les fautes (page fault, double fault & co). Je ne comprends
> vraiment pas a quoi ca peut servir, si tu pouvais m'eclairer sur ce
> sujet, ce serait plutot pas mal.
>
> Partie 2.3 : il est clair que la serialisation est a proscrire
> totalement. on risque de rater plein d'interruptions timer, et meme dans
> un systeme non temps reel c'est difficilement acceptable du point de vue
> performances.
>
> Partie 3 : personnellement, je ne trouve pas que les papiers de Sun
> soient si revolutionnaires que ca. j'en avais deja parle dans un mail
> precedent, mais en gros ce qu'ils proposent c'est ce que nous
> envisagions de faire, il n'y a vraiment rien de transcendant dans tous
> ces papiers. leur avantage est peut etre de nous avoir expose l'ensemble
> des problemes lies a la memoire virtuelle, histoire qu'on sache un peu a
> l'avance sur quoi on va tomber (pas comme d'habitude !).
> Leur idee de driver par contre est plutot pas mal, c'est a mon avis une
> chose a developper.
>
> voila concernant mes reflexions concernant ce draft-0,
>
> amicalement
>
> thomas
> --
> PETAZZONI Thomas
> thomas.petazzoni@meridon.com     UIN : 34937744
> Projet KOS : http://kos.enix.org
> Page Perso : http://www.enix.org/~thomas/
>
> _______________________________________________
> Kos-dev mailing list
> Kos-dev@yoda.isnpro.com
> http://the-doors.enix.org/cgi-bin/mailman/listinfo/kos-dev
>