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

[anthoine.bourgeois]

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
>