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

[d2]

>>>>> "Thomas" == Thomas Petazzoni <thomas.petazzoni@ifrance.com> writes:
    Thomas> cela correspond en quelque sorte a la solution que j'ai
    Thomas> proposee dans le mail que je viens d'envoyer, en reponse a
    Thomas> Hlide me semble-t-il ?

Dans le draft-0, j'avais evoque (cf 1.3.2) un inconvenient a la
methode que tu rappelles dans ton mail : systematquement deleguer un
thread a chaque interruption est lourd (chgt de contexte
systematique). C'est pour ca que je proposais une solution plus
souple, a 3 niveaux :
  - ce que tu appelles "le prehandler" : non interruptible
  - ce que j'appelle le Bottom Half (ou wait queue Linux): dans le
    contexte de l'ISR normal = celui du thread interrompu =>
    interruptible mais non bloquable. Se charge du reschedule()
    (uniquement pour l'interruption la plus externe) + iret.
  - les threads proxy (ie mandataires) : choisis a la volee dans un
    pool pre-alloue de threads : pour les traitements interruptibles
    et bloquables. Le reschedule est implicite a chaque bloquage, et a
    chaque terminaison de traitement.

C'est le programmeur qui determine dans quelle "categorie"
(pre-handler, BH, proxy) il ecrit les differents traitements des
interruptions.

Schematiquement, on aurait :

 | ================= ISR ====+=========== |reschedule(*)       |============|
 |                           |            | +                  |   proxy    |
 |<--- Non Interruptible --> | <-- BH --> |iret                |<---------->|

(*) : quand nested_level == 1

Sachant que dans les proxies "Le reschedule est implicite a chaque
bloquage, et a chaque terminaison de traitement".

Ca ressemble a la solution rappelee par Thomas, a ceci pres qu'on
rajoute un etage intermediaire (le BH), afin de ne pas causer
systematiquement de chgt de contexte a chaque traitement un peu
complique et non-bloquant dans les interruptions.

Voila.

-- 
d2