[SOS] Article 10 -- système de fichiers FAT

[guerineau]

Au sujet de la "famine" de thread ("No kernel thread ready") :
Il me semble que le phenomene peut se produire d'une maniere generale quand
un process meurt et que ses fichiers doivent etre fermes: la thread "idle"
est
sollicitee pour faire le travail de fermeture des fichiers. Ces operations
de fermeture
engagent en general , des entree sortie disque, donc des synchronisations:
la thread "idle"
est mise en attente. Le probleme survient alors quand il faut trouver une
thread pour prendre
le relais des activites.
Deux approches sont envisageables: (elles ne sont d'ailleur pas
incompatible)
- la disparition de la contrainte de disposer obligatoirement d'au moins une
thread activable
  Ceci peut etre realise en introduisant une modification dans la boucle
d'ordonnancement
  (la fonction sos_reschedule): au lieu a generer une erreur, quand la
famine est detectee, on
 provoque une attente particuliere, sur le modele
  - sti (demasquage des interruptons)
  - hlt (on attend la prochaine interruption)
  - cli
  puis re-exploration des threads activables.
  Il existe une contrainte: puisque , a un moment donne, il peut n'exister
aucune thread
 active dans le systeme, il faut relacher le controle attache a la fonction
de fourniture
 de la thread active: thread.c::sos_thread_get_current
  ie, suprimer le controle sur l'etat de la thread.


- la second approche consiste a synchroniser les deces de thread en les
chainant dans une
  liste et a creer une thread de "fossoyeur", comme cela:
  - la thread "fossoyeuur" est en attente sur une file dediée (via le
service sos_kwaitq_wait)
    Les  threads "mourantes" sont chainees dans la "liste des deces".

  - la fonction sos_thread_exit() est modifiee, comme suit:
    Elle enregistre la thread mourante dans la "liste des deces"
    Elle active le fossoyeur via le service sos_kwaitq_wakeup.
    Elle declenche un reordonnancement (via sos_reschedule)
    Et , au lieu de terminer avec le service "sos_cpu_context_exit_to", elle
    appelle le service de commutation sos_cpu_context_switch comme s'il
s'agissait
    d'une commutation normale. Normalement, le fossoyeur prend alors la main
...

   Le service de fossoyage relaie les demandes de deces vers la fonction
habituelle
   "delete_thread".

   Ces deux approches permettent de repondre a un afflux massif de mort de
process ,
  entrainant des fermetures multiples de fichiers, apres la disparition des
proprietaires.
   Je me suis penché plus particulierement sur la seconde approche, qui
offre l'evantage
  d'eradiquer la fonction "sos_cpu_context_exit_to" qui m'a toujours semble
un peu lourde.
 (une simplification d'un coté, une transition additionnelle de l'autre: le
resultat est une augmentation
  de complexite du noyau plutot legere).
  Si vous souhaitez en savoir plus sur le detail de la modification, vous
pouvez explorer
  le patch que je joins en annexe ("10_euthanasie.pat")

C. Guerineau
----- Original Message -----
From: anthoine.bourgeois <anthoine.bourgeois at wanadoo.fr>
To: SOS mailing-list <sos at the-doors.enix.org>
Sent: Monday, November 19, 2007 3:48 PM
Subject: Re: [SOS] Article 10 -- système de fichiers FAT


Rebonjour,


> Message du 10/10/07 17:55
> De : "geoffroy weisenhorn" <geoffroy.weisenhorn at gmail.com>
> A : "SOS mailing-list" <sos at the-doors.enix.org>
> Copie à :
> Objet : Re: [SOS] Article 10 -- système de fichiers FAT
>
> Cepandant un bug plus génant survient à la terminaison de fstestfat,
> SOS backtrace et dit : "No kernel thread ready ?!" dans la fonction
> sos_reschedule de sched.c.
> je sais pas du tout quelle sont les conditions qui on amené l'ordonnanceur
> dans cet état et surtout comment l'éviter... je continue à recherche ..

Ce week-end j'ai regardé le problème. Je vous fais part de mes recherche
et vous mets à contribution pour trouver une solution car je n'en vois
aucune qui soit correct.

L'appel système exit() fait un appel à sos_thread_delete().
sos_thread_delete appelle l'ordonnanceur pour changer de thread.
Le thread idle est élu puisqu'il est seul il n'y a plus d'autre
thread dans les files de l'ordonnanceur à ce moment.
La destruction du thread s'execute donc avec le thread idle.
La destruction du thread entraine la destruction du processus
qui contenait ce thread.
Le processus contenait des fichiers ouverts.
Ces fichiers sont fermé un à un.
C'est ici que le problème survient :
L'écriture sur disque provoque bloquage sur des sémaphores (ide.c:605)
donc le thread idle rentre dans une waitqueue et l'ordonnanceur
et rappelé pour l'election un nouveau thread.
Comme le thread idle était le dernier on tombe sur le problème
décrit plus haut.

Je ne vous pas de solution propre.
-On ne peut pas syncroniser les fichiers avant la suppression
du thread.
-On ne peut pas supprimer les sémaphores de la procédure
d'écriture disque.
-On ne peut pas empécher l'ordonnanceur d'élire le thread
idle pour écrire sur le disque.

Peut-on refaire passer le thread bloqué dans une waitqueue
dans l'état "pret" s'il est le seul disponible?

Dans la pratique ca marche mais je ne trouve pas ca propre.

Qu'en pensez-vous?

Anthoine


_______________________________________________
Sos mailing list
Sos at the-doors.enix.org
http://the-doors.enix.org/cgi-bin/mailman/listinfo/sos

-------------- section suivante --------------
Une pièce jointe non texte a été nettoyée...
Nom: 10_euthanasie.pat
Type: application/octet-stream
Taille: 5424 octets
Desc: non disponible
Url: http://the-doors.enix.org/pipermail/sos/attachments/20071125/12924d88/attachment.obj