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

[geoffroy weisenhorn]

Bonjour ,

J'aurais une question à propos de la solution proposé sur la gestion
de cette famine de thread:
j'avais eu un peu près la même idée dans le sens où notre problème
apparaît à la fermeture de fichiers qui doivent être écrit/réécrit sur
le périphérique de bloc pourquoi ne pas laisser faire ce travail de
synchronisation au thread bdflush au lieu
d'avoir un nouveau thread noyau ? seulement j'ai pas réussi à trouver
dans le code
où les opérations d'écriture sont lancés suite à la fermeture de
fichier, mais finalement c'est peut-être pas une solution aussi simple
que la solution proposée et que d'autres problèmes risque
d'apparaître.
d'ailleurs j'ai un message de gcc très bizarre en utilisant le patch:
sos/thread.c: In function 'sos_thread_exit':
sos/thread.c:469: warning: 'noreturn' function does return

Sinon au sujet du compromis réactivité/mémoire j'ai pas bien compris
où se situe le problème ? ce problème apparaît -il dans le cas de
nombreuses terminaisons de threads et de ressources mémoire limitée,
la suppression des ressources mémoire n'est pas immédiate dans le cas
où un thread de haute priorité récupère la main, c'est ça ?

Geoffroy

Le 28/11/07, anthoine.bourgeois<anthoine.bourgeois at wanadoo.fr> a écrit :
> Salut,
>
>
> > Message du 27/11/07 21:14
> > De : "guerineau" <chris.guer at wanadoo.fr>
> > A : "anthoine.bourgeois" <anthoine.bourgeois at wanadoo.fr>
> > Copie à :
> > Objet : Re: [SOS] Article 10 -- système de fichiers FAT
> >
> > Aucune  objection au sujet de la priorité.
> > Mon idee de ce fossoyeur etait , avant même de l'appliquer a notre probleme
> > initial, de contourner un defaut de SOS qui menacait sa réactivité. En
> > effet, si nous prenons la situation suivante:
> > - une tache se termine, plus ou moins proprement, avec des fichiers ouverts
> > - a ce momemnt précis, une tache urgente se trouve elligible
> > Alors , cette derniere tache prend la main, et il lui est demandé, en
> > première action de s'occuper de terminer la fermeture de la tache qui vient
> > de s'achever: non seulement notre tache urgente doit se consacrer , avant
> > toute chose, a une activité qui n'est pas sienne, mais en plus, elle risque
> > fort  de se trouver bloquée au cours du traitement de cette activité. En
> > d'autre terme, le determinisme sur le temps de réponse du sytème devient
> > flou.
> >  Ce fossoyeur me semblait repondre correctement a mon probleme. Alors,
> > maintenant, la question concernant la dévaluation de sa priorité ne va pas
> > changer sa réponse concernant ma préoccupation initiale
> > (héviter un blocage au démarrage de tache urgente).  La priorité que j'avais
> > fixe initialement s'appliquait a un système ou la ressource etait maigre,
> > tres maigre et visait a eviter une situation d'engorgement induite par une
> > rafale de sequences du genre {creation process + destruction immediate). Il
> > aurait quand même fallu une longue rafale ...  En remarque et pour terminer,
> > dans la situation qui prévallait avant le patch, les travaux de fossoyage
> > etaient attribues de maniere automatique a la tache de plus forte priorité
> > (puisqu'ils étaient realises au démarrage par la tache élue lors du
> > reordonnancement consecutif au décès).
>
> On est d'accord. Avant c'était implicitement le cas. Mais maintenant qu'on a
> le choix, autant ne pas refaire la meme erreur. Donc de mettre le fossoyeur
> en priorité basse pour permet justement de laisser les threads de haute
> priorité s'exécuter tranquille. Donc réactivité, mais au dépend de
> ressources mémoire comme tu l'as dis. Il faut faire un compromis
> réactivité/ressource comme souvent.
>
> > Et encore une remarque pour finir: le code concernant ce fossoyeur est
> > perfectible. En particulier j'ai empilé deux ordres de masquage
> > d'interruption dont un semble inutile.
>
> On est d'accord.
>
> > C. Guérineau
> >
> > ----- Original Message -----
> > From: anthoine.bourgeois <anthoine.bourgeois at wanadoo.fr>
> > To: guerineau <chris.guer at wanadoo.fr>; SOS mailing-list
> > <sos at the-doors.enix.org>
> > Sent: Tuesday, November 27, 2007 8:15 AM
> > Subject: Re: [SOS] Article 10 -- système de fichiers FAT
> >
> >
> > 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
> >
>