[Kos-dev] Proposition de Hlide : Signalisation inter threads
d2
kos-dev@enix.org
13 Sep 2000 09:53:17 +0200
The following message is a courtesy copy of an article
that has been posted to the-doors.forum.kos.specs.kernel.taches as well.
--=-=-=
Bonjour tout le monde,
Voici un message interessant de Christophe concernant l'utilisation de
l'extension PVI des Pentium, a des fin de signalisation inter
processus / inter-threads. Version integrale. Pour la petite histoire,
l'Url dont il est fait reference au debut, c'est celle de
kernel-traffic : http://kt.linuxcare.com/kernel-traffic/latest.epl .
--=-=-=
Content-Type: message/rfc822
Content-Disposition: inline
X-From-Line: hlide@club-internet.fr Wed Sep 13 00:34:00 2000
Received: from dns.irisa.fr (dns.irisa.fr [131.254.254.2])
by sky.irisa.fr (8.9.3/8.9.3) with ESMTP id AAA07715
for <ddecotig@sky.irisa.fr>; Wed, 13 Sep 2000 00:34:00 +0200 (MET DST)
Received: by dns.irisa.fr (Postfix)
id 77C3ECAAE; Wed, 13 Sep 2000 00:34:00 +0200 (MET DST)
Delivered-To: ddecotig@irisa.fr
Received: from front4m.grolier.fr (front4m.grolier.fr [195.36.216.54])
by dns.irisa.fr (Postfix) with ESMTP id 1006ECA85
for <David.Decotigny@irisa.fr>; Wed, 13 Sep 2000 00:34:00 +0200 (MET DST)
Received: from club-internet.fr (nas11-253.wms.club-internet.fr [213.44.38.253])
by front4m.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id AAA02836
for <David.Decotigny@irisa.fr>; Wed, 13 Sep 2000 00:25:47 +0200 (MET DST)
X-Gnus-Mail-Source: file:/var/mail/ddecotig
Message-ID: <39BEAF31.65C3F8@club-internet.fr>
Date: Wed, 13 Sep 2000 00:33:21 +0200
From: Christophe Avoinne <hlide@club-internet.fr>
Reply-To: hlide@ecris-moi.com
X-Mailer: Mozilla 4.7 [fr] (Win98; I)
X-Accept-Language: fr
To: David.Decotigny@irisa.fr
Subject: Re: Une petite citation pour la route...
References: <wacpuma55ka.fsf@rantamplan.irisa.fr>
Lines: 119
Xref: rantamplan.irisa.fr Divers-2000-09:56
X-Gnus-Article-Number: 56 Wed Sep 13 01:15:02 2000
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable
Salut !
Je suis all=E9 =E0 l'URL que tu nous as envoy=E9, et je te remercie bie=
n, car
=E7a me donnera un meilleur apper=E7u de ce qui se trame entre les
concepteurs de linux :-).
Bon, toujours est-il que j'ai pench=E9 un peu au hasard sur la gestion =
des
exception - ou signaux - c'est toi qui voit. En effet, en consultant les
manuels sur les microprocesseurs et en particulier le chapitre concerna=
nt
l'extension PVI (Protected-mode Virtual Interrupts), il m'est venu =E0
l'id=E9e de l'utiliser pour impl=E9menter la gestion des signaux ou
exceptions dans le mode user (CPL3). D'ailleurs pour le reste, je ne
parlerais que d'exception ou signal en mode user (CPL3).
En effet, en g=E9n=E9ral une exception externe (page fault, general
protection, etc.) ex=E9cute un code kernel et non user. Dans certain ca=
s,
on aimerait pouvoir ex=E9cuter le code user qu'un processus =E0 install=
er
(exemple sous Unix : sigaction). D'autre part, une t=E2che pourait tr=
=E8s
bien envoyer des signaux =E0 une autre. Or il est hors question que l'on
s'amuse =E0 changer de t=E2che imm=E9diatement pour ex=E9cuter le code =
user du
signaux, pour ensuite revenir =E0 la t=E2che d'avant. Il ne faut ex=E9c=
uter ce
code user que lorsque la t=E2che concern=E9e par le signal entre en
ex=E9cution.
Evidemment, =E7a complique l=E9g=E8rement la programmation car il faut =
placer
la t=E2che qui a re=E7u un avis de signal dans la queue des t=E2ches pr=
=EAtes, et
avertir cette t=E2che de la raison (autrement dit, faire en sorte qu'el=
le
ex=E9cute le code user du signal et non le code o=F9 elle s'=E9tait arr=
=EAt=E9.
Pire, imaginer que cette t=E2che tournait en mode kernel : que doit-on
faire, l'interrompre ou attendre le retour en mode user ? (la deuxi=E8me
parait plus logique).
Alors, plut=F4t que d'avoir un code qui v=E9rifie =E0 chaque fois si te=
lle
t=E2che n'est pas en situation de reception d'un signal, j'ai pens=E9 a=
voir
recours =E0 l'extension qui est disponible =E0 partir des pentiums : PV=
I.
Avec l'extension VME, on a deux flags dans eflag, VIF et VIP qui permet
d'=E9muler le flag IF en mode virtuel. En particulier, si on a VIF =3D =
0 et
VIP =3D 1, et que l'on fait IRETD (qui cherche =E0 mettre IF =E0 1) ou =
STI, on
a un #GP de lev=E9. Ca sert =E0 =E9muler une interruption virtuelle dan=
s le
mode virtuel juste apr=E8s un sti ou un iretd modifiant le flag IF. En
effet, l'OS peut simuler les IRQ dans le code virtuel en mettant VIP =
=E0 1
pour que le code puisse ex=E9cuter leur handler en mode r=E9el/virtuel =
apr=E8s
un sti ou un iretd (mettant IF =E0 0) rencontr=E9.
En temps normal, en mode prot=E9g=E9 et en CPL3, l'utilisation de CLI e=
t STI
provoque un #GP.
Bien, avec un IOPL < 3, l'extension PVI activ=E9e, on peut alors utilis=
er
les flags VIF et VIP de la m=EAme mani=E8re qu'en mode virtuel. Sauf que
lorsqu'une t=E2che veut envoyer un signal =E0 une autre t=E2che, elle m=
et le
bit VIP de l'autre =E0 1, enregistre la raison quelque part dans l'autre
(le handler =E0 ex=E9cuter, je pense =E0 une queue de signals re=E7us p=
our
l'autre), remet l'autre dans la file des t=E2ches pr=EAtes si n=E9cessa=
ire, et
continue enfin sa route. Lorsque l'autre entrera en ex=E9cution, avec s=
on
bit VIP =E0 1 (mis par la t=E2che qui lui a envoy=E9 le signal) :
- si elle est en mode kernel, rien ne se passe, elle continue jusqu'au
repassage en mode user.
- si elle est en mode user, et si le bit VIF est =E0 0, rien ne se pass=
e,
elle continue jusqu'au sti ou iretd rencontr=E9.
- si elle est en mode user, et si le bit VIF est =E0 1 (apr=E8s un sti =
ou un
iretd), alors #GP. Cette exception d=E9couvre que le VIP est =E0 1, il =
y a
donc =E9mulation de signaux en mode user =E0 ex=E9cuter : on va cherche=
r dans
la queue les handlers =E0 ex=E9cuter en mode user. Quand c'est fini, on=
met
le bit VIP =E0 0 et on reprends l=E0 o=F9 le #GP s'est d=E9clar=E9.
A noter que lors d'une commutation d'une t=E2che, si la nouvelle t=E2che
=E9tait en mode user quand elle a =E9t=E9 interrompue, elle y revient g=
r=E2ce =E0
un iretd, or avec le bit VIP =E0 1 et VIF =3D 1 (interruptions authoris=
=E9es),
on a droit au #GP :-). Le seul cas, o=F9 ce #GP ne se d=E9clarera pas t=
out de
suite, c'est quand le code user avait fait cli auparavant, auquel cas il
faut attendre qu'il fasse sti, pour que ce #GP se d=E9clare et que les
signaux ou exceptions user soient trait=E9s enfin. La paire cli et sti
fonctionne donc comme un masquage global des signaux (encore que je
pensais aussi leur destiner une autre fonction : une exclusion mutuelle
des threads au sein d'un m=EAme processus, par exemple. Si =E7a t'int=
=E9resse
je t'en parlerais aussi).
Cette technique devrait nous all=E9ger de coder la gestion des signaux =
au
sein du commutateur de t=E2che et de l'ordenanceur. Le travail =E9tant
effectu=E9 par le #GP qui n'a lieu que lorsqu'effectivement une t=E2che=
a
re=E7u au moins un signal.
Par ailleurs, les exceptions page fault, general protection, mais aussi
invalidate instruction, etc. peuvent =EAtre des handlers qui mettent le=
bit
VIP de la t=E2che courante =E0 1, installe le handler en mode user (cel=
ui
donn=E9 par l'application, par exemple, =E0 l'instar de sigaction sous =
Unix)
en queue, de sorte que lorsque l'exception kernel fait iretd pour
retourner au code fautive de l'application user, on g=E9n=E8re #GP qui =
va
ex=E9cuter le handler. Bien s=FBr, soit l'application se ferme, soit le
handler en mode user =E0 r=E9gler le probl=E8me et on peut donc reprend=
re
l'ex=E9cution du code de l'application user. Toutefois si le code user a
fait un cli, il y a probl=E8me. Une solution serait de forcer VIF =E0 1=
en
sauvegardant sa valeur pr=E9c=E9dente pour la restituer apr=E8s ex=E9cu=
tion du
handler d'exception. Une autre solution est de ne pas consid=E9rer
l'utilisation du VIP pour ce cas d'exception : on modifie l'appel de
retour dans le code user pour appeler le handler user qui se chargera de
terminer proprement la t=E2che en laissant la possibilit=E9 d'appeler le
handler de terminaison install=E9 par le code fautive. En sauvegardant
l'ancienne adresse de retour dans la pile si le handler peur y revenir
apr=E8s correction.
Ce sont normalement des =E9v=E9nements plus rares que les commutations =
des
t=E2ches ou extr=E8mement faibles par rapport =E0 l'ex=E9cution des ins=
tructions.
C'est pourquoi, l'overhead du #GP, ne devrait pas =EAtre trop p=E9nalis=
ant
compar=E9 aux tests que l'on aurait d=FB faire dans le commutateur ou
l'ordenanceur de t=E2che sans ce syst=E8me, des tests n=E9gatifs la plu=
part du
temps compte tenu de la proportion des signaux et exceptions g=E9n=E9r=
=E9es...
Qu'en penses-tu ?
Si tu penses que ce mail devrait =EAtre publi=E9 en public, je te laisse
faire. Moi, je ne sais pas =E0 quelle cat=E9gorie de la nouvelle ml il =
faut
la placer.
Hlide.
--=-=-=
--
d2
--=-=-=--