[Kos-dev] Reentrance de reschedule : un solution ?

[Hlide]

Non, David, tu as parfaitement raison sur le fait qu'un BH ne doit pas être
bloquant, parce qu'il serait tout bonnement incompréhensible et injuste
qu'une tâche quelconque qui a eu le malheur d'être interrompue par un ISR
puis un BH soit bloquée par le BH parce que ce dernier utiliserait une
ressource bloquante (cette même ressource n'ayant strictement rien à avoir
avec la tâche victime...). D'où l'idée effectivement d'un thread mandataire
(mandaté pour un BH bloquant, c'est bien là où tu veux en venir, j'imagine)
qui serait bloqué par ce BH plutôt que la tâche victime.

Très intéressant tout ça...

Néanmoins, s'agit-t-il d'un ou plusieurs threads mandataires ? parce que
j'imagine bien qu'un autre BH pourrait bloqué. Un thread mandataire par BH
(i.e, par ISR) ? utiliserait-on systématiquement ce thread mandataire pour
les BH ?

Evidemment on peut supposer un cas très spécial où si on se trouve dans une
tâche victime d'un BH bloquant, un thread mandataire prendra le relais pour
permettre à la tâche victime de continuer et ce serait le thread mandataire
qui serait bloqué. Bien sûr, cela suppose que les primitives bloquantes
sachent si oui ou non elles tournent dans une tâche victime ou fautive. Si
elle est victime, on duplique le thread pour en bloquer un et laisser
continuer l'autre (je suppose que l'on a une réserve de thread prêt à
l'emploi pour ces cas-là). Si elle est fautive, c'est que cette tâche doit
être bloquée. Les tâches interrompues par les BH tombent dans le cas des
victimes. Allez c'est un peu fumeux, je vous l'accorde ;-).

Pour résumer, mon idée était qu'un BH n'est pas forcément bloquant, donc
l'utilisation systématique d'un thread mandataire constitue un "overhead"
inutile. Ce thread mandataire ne serait utilisé qu'en cas de nécessité
expresse, i.e, que si le BH se bloque - comme de tout façon, il doit bloquer
une tâche, autant créer alors ce thread mandataire à ce moment là, ça
n'ajoutera pas plus d'"overhead" que si on le faisait systématiquement à
chaque BH. C'est un peu le même principe que les exceptions - en particulier
les défauts de page, par exemple : l'artillerie lourde de la pagination
n'intervient qu'"exceptionnellement". Le thread mandataire serait donc la
réponse exceptionnelle à un BH bloquant.

Voilà.

Pour en revenir aux IPL, il se trouve que les PC basés sur l'architecture
intel 32-bit des 86 utilise un chipset (PIC) pour les interruptions assez
basique en fin de compte car le niveau de priorité est figé. Le timer 0 qui
est l'IRQ #0 a une priorité maximum par défaut sur les autres. Certes, en
étant malin et en utilisant astucieusement les port de registres du PIC
(0x20,0x21,0xA0,0xA1) on pourrait simuler les IPL, mais ce serait encore
très limité.

Si on prend l'hitachi SH1 (sur lequel j'ai travaillé), chaque vecteur
d'interruption à un niveau de priorité compris entre 0 (- prioritaire) et 15
(+ prioritaire) totalement paramétrable. Il n'y a pas d'instruction cli/sti
pour masquer les interruption, on écrit simplement le niveau de priorité
dans lequel on veut exécuter le code et seules les interruptions ayant un
niveau de priorité supérieur peuvent interrompre le code. Bref, pour faire
un cli, je mets le niveau de priorité courant à 15, si je veux permettre
toutes les interruptions, je mets 0 (c'est en général le niveau de priorité
qu'on donne à un code hors-interruption). Quant une interruption est
exécuté, le niveau de priorité du code est mis à celle de l'interruption
pour masquer les interruptions de niveau de priorité inférieur ou égal. Le
système peut être encore plus dynamique en ce sens qu'une interruption peut
voir son niveau de priorité changer dynamiquement pour mieux se coller à la
demande extérieur (à condition d'avoir le code intelligent pour les
arbitrer). Cela ouvre des perspectives très intéressantes quand on y
réfléchit.

Je dois avouer que je trouve maintenant le mécanisme des interruptions sur
les PC bien pauvres et irritants.

Cela dit, toujours pour la théorie, même si on ne peut pas entièrement
simuler la gestion des interruption comme sur le SH1, on peut toujours
changer l'ordre de priorité de façon dynamique sur le PIC. Cependant, je
crois que l'ordre sera toujours :
+ 0->1->...->5->6->7 -,
+ 1->2->...->6->7->0 -,
+ 2->3->...->7->0->1 -,
etc.
mais on ne pourra sans doute pas avoir par exemple :
+ 0->7->3->2->6->5->1->4 -.

Je ne vous recommande pas de se lancer dans ce jeu là - cela constituerait
des "overheads" probablement pas rentables.

En revanche, la gestion des IPL dans les BH, pourquoi pas ? ce n'est ni plus
ni moins qu'une façon d'ordonner l'exécution des BH.

A la prochaine !



----- Original Message -----
From: d2 <David.Decotigny@irisa.fr>
To: <kos-dev@enix.org>
Sent: Monday, June 25, 2001 4:39 PM
Subject: Re: [Kos-dev] Reentrance de reschedule : un solution ?


>
> >>>>> "Thomas" == Thomas Petazzoni <thomas.petazzoni@ifrance.com> writes:
>     Thomas> okay la je comprends mieux. pourrais-tu mettre a jour
>     Thomas> draft-0 avec toutes les precisions apportees dans ce mail
>     Thomas> (concernant l'exemple d'un machin non reentrant,
>     Thomas> concernant cette explication, et d'autres) ?
>
> Peut-etre.
>
>     Thomas> je ne comprends pas trop la relation de cause a effet
>     Thomas> existant entre 'le BH n'est pas associe a un thread
>     Thomas> propre' et 'il est hors de question que ce BH puisse
>     Thomas> bloquer en attente sur ressource'.
>
> Pour etre honnete, c'est pas evident.
>
> En gros, ce que je crains, c'est qu'un pauvre thread qui n'a rien
> demande et qui se fait interrompre par une ISR qui bloque, va se
> retrouver bloque lui aussi alors qu'il a rien demande. Si ce thread
> effectue des gros calculs (ie ne bloque jamais), c'est idiot de le
> bloquer, et partant de l'empecher de faire ses calculs alors qu'il
> pourrait tres bien les faire. Bref, je crains une sous-utilisation du
> processeur (d'avantage visible en SMP).
>
> C'est peut-etre discutable.
>
>     Thomas> je suis d'accord sur le principe, mais pas sur la
>     Thomas> terminlogie : pourquoi thread mandataire ? pourquoi proxy
>     Thomas> ?
>
> En info, la traduction classique de "proxy" est "mandataire" en
> Francais. C'est un design pattern en Objet
> (http://www.clickblocks.org/patterns1/pattern_synopses.htm#Proxy). Par
> analogie (abus de langage), j'ai appele ces taches "mandataires" car
> elles jouent le role de proxy pour les traitements des ISR.
>
>     Thomas> necessite de ton systeme des ipl, pourrais-tu le preciser
>     Thomas> ?
>
> cli/sti = blocage binaire des IRQ + on perd les interruptions pdt
> cette periode.
> L'idee, c'est qu'avec le mecanisme plus fin des IPLs, on remplace les
> cli/sti par un mecanisme de memorisation des ISR qui ont eu lieu, pour
> en tenir compte soit immediatement (priorite plus forte que l'ipl
> courant), soit plus tard (priorite plus faible). Ca a peut-etre encore
> plussssse son interet dans les BH : puisqu'a ce moment on devient
> interruptible, mais on peut selectionner par quoi on peut etre
> interrompu (on retarde les IRQ qu'on veut). Un autre interet, c'est aussi
> qu'on peut "personnaliser" les priorites des interruptions (on peut
> deja le faire par d'autres moyens, mais bon).
>
> Bonne journee,
>
> --
> d2
>
> _______________________________________________
> Kos-dev mailing list
> Kos-dev@yoda.isnpro.com
> http://the-doors.enix.org/cgi-bin/mailman/listinfo/kos-dev
>