[Kos-dev] Commentaires sur draft-0

[Thomas Petazzoni]

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/