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

d2 kos-dev@enix.org
26 Jun 2001 09:08:49 +0200


Bonjour,

Pour Chirstophe : le seruveur rame, mais le draft-0 est quand meme
accessible a :
  http://kos.enix.org/~d2/snapshots/kos-doc_current/draft-0-html/
Je viens de verifier : la page est toujours la.

>>>>> "Christophe" == Christophe Avoinne <hlide@club-internet.fr> writes:
    Christophe> Néanmoins, s'agit-t-il d'un ou plusieurs threads
    Christophe> mandataires ? parce que j'imagine bien qu'un autre BH
    Christophe> pourrait bloqué. Un thread mandataire par BH (i.e, par
    Christophe> ISR) ? utiliserait-on systématiquement ce thread
    Christophe> mandataire pour les BH ?

A mon sens, il y a plusieurs facons de voir la chose. Je me cite « la
méthode est de mettre sur file d'attente, non pas l'interruption en
cours, mais 1/ soit une tâche mandatée pour s'occuper du traitement en
question ; 2/ soit une fonction qui sera rajoutée dans une file des
traitements à faire effectuer plus tard par une tâche dédiée (à la
manière des bottom-halves), par exemple quand l'ISR la plus externe
termine. » Sachant que « Le premier cas entraîne un ``gaspillage'' de
ressources (piles). Mais cette méthode est sans doute plus réactive
que la seconde, qui impose la sérialisation des traitements, et donc
l'impossibilité d'entrelacer les exécutions des traitements par le jeu
des attentes sur ressources. »

Donc deja, ca constitue un choix a faire, toujours en compromis entre
reactivite et ressources.

Si on choisit le 1/, on peut se rendre compte qu'on va avoir besoin de
plusieurs taches mandataires. Reste a savoir combien on en prevoit,
car il faut effectivement les prevoir a l'avance. Si on choisit cette
solution, on se heurte a un probleme de dimensionnement. Car si on se
trouve en rupture de stock de threads mandataires, c'est la grosse
zone.

Ou alors on a une solution mixte 1/ et 2/ : on reserve exactement 1
thread mandataire pour chaque niveau d'interruption (=> 16 sur
IA32). Et par exemple quand le thread mandataire ISR 0 est bloque, si
on a une IRQ 0 qui est levee et qui a encore besoin de bloquer, elle
rajoute tout simplement une fonction (comme dans 2/) a faire executer
par le thread mandataire ISR 0 quand elle aura fini son precedent
traitement.

Finalement, c'est peut etre ce qui serait le mieux :
  - 1 thread mandataire par niveau d'interruption (* nombre de
    processeurs en SMP)
  - Sur chaque mandataire : une file de traitements a effectuer, qui
    peuvent etre bloquants.

    Christophe> Evidemment on peut supposer un cas très spécial où si
    Christophe> on se trouve dans une tâche victime d'un BH bloquant,
    Christophe> un thread mandataire prendra le relais pour permettre
    Christophe> à la tâche victime de continuer et ce serait le thread
    Christophe> mandataire qui serait bloqué. Bien sûr, cela suppose

Ca, ca correspond a ce que j'ai appele "modele mixte" (paragraphe
1.3.3). Ca me parait un peu trop complique. Car le BH, quand il se
rend compte qu'il doit etre bloquant, il doit transferer son etat sur
le thread mandataire. Je crains que ce soit lent.

Je voyais qqch de plus "manuel" (decide par le programmeur). De la
meme maniere que le programmeur decide si les traitements d'un ISR
vont resider dans la partie "non interruptible" ou dans la partie
"interruptible" (BH) de l'ISR, le programmeur deciderait si le
traitement en question peut bloquer, auquel cas il le met sur un
thread mandataire.

C'est pour ca que je parlais de "bottom-half de 2eme niveau", parce
que j'imaginais que la demarche etait identique : c'est le programmeur
qui decide.

    Christophe> utilisant astucieusement les port de registres du PIC
    Christophe> (0x20,0x21,0xA0,0xA1) on pourrait simuler les IPL,
    Christophe> mais ce serait encore très limité.

Certes. Mais est-ce que ca ne serait pas encore plus lent (outb) que
cli/sti ?

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

Exactement. Et ca permet de se degager un peu de l'archi statique PC
(ordre entre les IRQ fixe) : on peut alors le personnaliser cet
ordre.

Bonne journee,

-- 
d2