[Kos-dev] DSR du commit de Thomas

[d2]

Hello,

On reparlera de tout ca a Bordeaux, mais je fais quand meme une
reponse publique.

>>>>> "Thomas" == Thomas Petazzoni <thomas.petazzoni@ifrance.com> writes:
    Thomas> ca me parait bien trop complexe d'avoir clISR, stISR, DSR
    Thomas> puis proxy. je pense que l'etape stISR que je viens
    Thomas> "d'inventer" n'est pas vraiment (voire pas du tout)
    Thomas> utile. On peut surement placer les traitements a faire la
    Thomas> dedans soit dans le clISR, ou mieux dans le DSR. dans tous
    Thomas> les cas, 3 niveaux ca me paraissait deja bien complexe,
    Thomas> mais 4 ca me semble carrement disproportionne. qu'en
    Thomas> pensez-vous ?

Il se trouve que le stISR permet de renforcer le sens "deferred" aux
DSR. Car le sens "deferred" des DSR n'apparait que suite a des
imbrications d'ISR. En effet : les DSR ne sont executes que apres la
terminaison de l'interruption la plus externe. Si il n'y a pas de
stISR, il y a moins d'imbrication d'ISR, donc "deferred" dans DSR a
moins de sens.

Sans stISR, le sens "deferred" des DSR apparait lors d'un scenarion du
type (avec 1 seule file de DSR => ordre FIFO) :

  ---- IRQ 1 -----
  clISR 1
    add_DSR(dsr1)
    add_DSR(dsr2)
  sti
    /* spawn_dsr... */
    debut dsr1
      ---- IRQ 0 ----
      clISR 0
        add_DSR(dsr3)
      sti
        /* On n'est pas ds l'IRQ la plus externe => pas de spawn_dsr */
      iret
    suite_et_fin dsr1
    exec_dsr2
    exec_dsr3
  iret

Bref, dans ce cas, seul dsr3 est un "vrai" DSR (vraiment
"deferred"). C'est dsr1 qui justifie le caractere "deferred" a ce
dsr3. On ne peut pas dire que dsr2 soit vraiment "deferred", puisque
de toutes facons il devait s'executer apres dsr1 (ordre FIFO).

Maintenant, si on avait un handler stISR dans l'isr 1, le caractere
"deferred" de dsr1 apparaitrait plus directement.

Bref, pour resumer, c'est vrai que stISR n'est pas vraiment
necessaire. Mais on peut :
  - imaginer que certains ISR aient des traitements qu'il serait
    preferable d'executer juste apres le clISR plutot qu'en sortie des
    imbrications d'ISR.
  - remarquer qu'avec un test avant le call dans l'ISR assembleur
    (test sur adresse stISR != NULL), ce stISR ne coute pas trop cher
    en temps processeur.

Donc je suis partisan de le laisser, garde par un test. Mais il
faudrait renommer tout ca (clISR, stISR, DSR).

    Thomas> a quoi serviraient tous ces niveaux de DSR_LEVELS, comment
    Thomas> tu les attribue ?

On peut avoir DSR_LEVELS = 1 si on veut. Dans ce cas, les DSR sont
executes suivant l'ordre FIFO. Mais c'est rarement l'ideal, puisque ca
voudrait dire que l'ordre d'arrivee des interruption influe
directement sur l'ordre d'execution des DSR. D'ou la notion de
priorite (DSR_LEVELS > 1) pour retablir un ordre plus "absolu", moins
arbitraire. Sous Linux, on a DSR_LEVELS = 32 puisque le bitmap
(analogue avec celui propose) est un mot de 32 bits.

    Thomas> a mon avis l'idee de mettre reschedule dans un DSR est
    Thomas> plutot mauvaise.  j'avais deja pense a ca, et
    Thomas> effectivement ce n'est pas du tout compatible avec le
    Thomas> double fault.  je me demande si ce double fault ne va
    Thomas> finalement pas plus nous embeter que nous
    Thomas> arranger. toutefois est-ce dramatique de placer le
    Thomas> reschedule() dans le clISR comme cela est fait
    Thomas> actuellement ?

1. Je trouve cette idee plutot seduisante
2. La compatibilite #DF doit pouvoir se faire en amenageant le handler
   #DF pour qu'il force le reschedule en cas de suppression de thread
   quand :
    - le #DF a eu lieu dans une interruption
    *ET*
    - on sait que le reschedule a deja ete fait dans un DSR
      (mise en place de next_thread=NULL en debut d'ISR ; si
      next_thread != NULL, c'est que le reschedule a deja ete fait).

On doit pouvoir s'en sortir plus simplement en sacrifiant la derniere
queue de plus basse priorite au reschedule, et en interdisant d'y
mettre autre chose que reschedule (=> filtrage au niveau du
dsr_add). Dans ce cas, la derniere possibilite pour le #DF
d'apparaitre est precisement *dans* le reschedule. Sur tout le chemin
retour vers le iret, etant donne qu'on remonte la pile, aucun #DF ne
peut avoir lieu, donc l'hypothese de base "pas de #DF entre la fin du
reschedule et le iret" est verifiee.

Sinon, vous avez remarque beaucoup de cli/sti dans le spawn_dsr
propose. Je pense qu'on devrait utiliser les non-blocking queues dont
Hlide nous avait parle. "Mais en meme temps, je suis pas sur".

    Thomas> PS : julien, tu es tjs vivant ?

Oui, c'est vrai ca... Alors ?

Bonne journee,

-- 
d2