[Kos-dev] synchro en SMP

[d2]

>>>>> "Thomas" == Thomas Petazzoni <thomas.petazzoni@enix.org> writes:
    Thomas> Je vois bien l'idée de la chose. Je pense qu'effectivement
    Thomas> ça solutionne la chose, mais ce n'est pas sur que ce soit
    Thomas> la solution la plus élégante. Je me demande si en
    Thomas> utilisant un autre état (ala Linux TASK_UNINTERRUPTIBLE),
    Thomas> ou quelque chose dans l'esprit, il n'y aurait pas moyen de
    Thomas> s'en sortir un peu mieux, parce que globalement les locks
    Thomas> qui se baladent de partout, bof bof.

oui, c'est a voir. je pense pas que l'etat supplementaire suffise ou
ameliore les choses, a la reflexion (si tu penses que je change d'avis
comme de chemise, tu as tort : je change plus souvent d'avis ces
derniers temps). cf plus bas.

    Thomas> Avant de dire des bétises, peux-tu rappeler la race
    Thomas> condition (en SMP) qui intervient si on relache le lock
    Thomas> avant de _commencer_ le cpl0_switch ?

voila une version simple (resume) du truc foireux en SMP (similaire a
la version d'hier qui resolvait la RC2 en UP). On imagine qu'on est en
train de bloquer sur une ressource, schematiquement la solution
foireuse donnerait :
 * lock sur un lock + determine si on doit bloquer
 * mise du cur_thr a l'etat bloque dans une wq
 * unlock_remote du lock // IRQ toujours desactivees, mais spinlock relache
 [RC]
 * cpl0_switch

Le probleme est le suivant : j'ai un thread A qui fait ca. En [RC],
sur un autre processeur, un thread B decide de reveiller un thread en
attente sur la meme ressource. Il se trouve que A est elu. Donc en
[RC], A s'execute en meme temps sur 2 processeurs differents. Mais
c'est pas ca qui est bien grave : c'est juste avant qu'il y'ait ces 2
instances de A que ca coince le plus gravement ! Car en fait B va
restaurer le contexte de A avant de switcher vers lui, or le contexte
de A "actuel" n'a pas encore ete sauvegarde puisque on (ie [RC]) est
avant le cpl0_switch. Conclusion : non seulement A s'execute
simultanement sur 2 processeurs (pas trop grave), mais surtout la
version de A qui s'execute sur le 2eme processeur est dans un etat
completement caduque !

Conclusion : il est necessaire d'assurer strictement que A ne va pas
pouvoir etre vire de la kwq avant d'avoir ete completement bloque au
sens propre (ie avant qu'il y ait eu sauvegarde de son contexte).

On doit pouvoir le faire avec la solut que j'ai proposee tout a
l'heure (a verifier). Et aussi en jouant avec les etats de
threads. Ceci dit, avec les etats de threads, ca risque d'etre
bidouille aussi, puisqu'il faut que le processus d'election d'un
thread ds une wq (kwq_wakeup) ne tienne pas compte des threads marques
URGENT (c'est ca la difficulte), afin qu'un thread sur un processeur
P1 ne puisse pas elire un thread en train de bloquer ds un processeur
P0 : dans ce cas, on va se retrouver ds une config bancale pour la
gestion des ressources :
  - proc0: thread A locke un spin
  - proc0: ressource deja occupee => A se marque "bloque" -> ajout ds
    une wq + passage en etat "URGENT" (ou TASK_UNINTERRUPTIBLE)
  - proc0: A unlock  remote le spin
  - proc1: B lock le spin
  - proc1: B libere la meme ressource.
  - proc1: B choisit un thread ds la wq ; on imagine qu'il n'y a que
    A, mais qui est marque URGENT => ne pas le prendre en compte
  - proc1: B unlock le spin (si il veut)
  - proc0: cpl0_switch # On s'endort

Autrement dit : on vient de s'endormir sur une ressource qui a ete
liberee entre le moment ou on a cru qu'elle etait occupee et le moment
ou on s'est endormi. Ce qui veut dire qu'il faut ds ce cas que B fasse
des choses en plus, genre :
  while (personne pret a etre debloque ds la wq)
    yield();
  debloquer le thread en attente

Ca risque d'etre un peu bidouille aussi.

Pour bochs : a mon avis ca suffit pas de decrementer les ticks "a la
main" qd on a vu un outb sur 0xe8... C'est pas tellement ces cycles
qu'il faut regarder, c'est surtout que des que 'outb 0xe8' a ete
decode (ou meme pendant), tick1 ou tickn ne fasse pas bouger le
calendrier des evenements du tout.

PS : Thomas ta radio streaming c'est quoi deja ?

-- 
d2