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

[anthoine.bourgeois]

Bonjour,

Tu as parfaitement saisi la problèmatique.
Ta solution me parait élégante. Par contre je n'aime pas le fossoyeur avec
une priorité aussi élevé. Dans ce cas c'est inutile que le fossoyeur ai une
liste puisqu'il est certain d'avoir la main pour nettoyer le processus juste
après. Pourquoi ne pas mettre le fossoyeur avec la même priorité que le
thread "idle" + 1 pour qu'il soit juste au dessus du thread idle?

Merci pour ton patch sur l'initialisation.

Anthoine


> Message du 25/11/07 21:21
> De : "guerineau" <chris.guer at wanadoo.fr>
> A : "anthoine.bourgeois" <anthoine.bourgeois at wanadoo.fr>, "SOS mailing-list" <sos at the-doors.enix.org>
> Copie à : 
> Objet : Re: [SOS] Article 10 -- système de fichiers FAT
> 
> 
> 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
> 
> 
>
> [ 10_euthanasie.pat (6.3 Ko) ]