Vous êtes sur la page 1sur 74

Rapport de fin de stage

Ecoulement
de la charge sur le syst`eme `a image unique Kerrighed :
application au domaine de la biologie.
par

Jerome Gallard

Equipe
daccueil : PARIS
Encadrement : Christine Morin - Pascal Gallard
Septembre 2006

Contact :
IRISA / INRIA Rennes
Campus universitaire de Beaulieu
Avenue du General Leclerc
35042 RENNES Cedex - France
Telephone : 02 99 84 71 00

Remerciements
Je souhaite remercier toute lequipe PARIS qui ma suivi et encadre tout au long
de mon stage et particuli`erement Christine Morin mon encadrant qui ma toujours ete
de bon conseil, ma toujours laisse libre court dans la gestion de mon travail et qui a
bien voulu lire et relire ce rapport un nombre incalculable de fois ! Je tiens egalement
`a remercier mon fr`ere Pascal Gallard qui ma aussi encadre (aussi bien sur le plan des
concepts que sur celui de la technique), soutenu et eclaire sur differents points tout au
long de cette annee !
Jaimerais egalement remercier tout le personnel de lENSSAT (enseignant, personnel administratif, direction des etudes, ...) qui ma guide durant ces trois annees sur le
chemin du metier dingenieur !
Enfin, jadresse aussi mes remerciements les plus chaleureux `a ma famille (mes parents, mes grand-parents, mon fid`ele cousin, ...) et `a mes amis (ma tite Elvire, mon
binome, Estelle, Fred, ...) qui ont toujours ete l`a pour moi au cours de ces trois annees.

`
TABLE DES MATIERES

Table des mati`


eres
Resume . . . .
Mots-Cles
Abstract . . . .
Keywords

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

Introduction
1 Pr
esentation
1.1 Le cadre de travail . . . . . . . . . . . . . . . .
1.1.1 LIRISA : une unite de recherche . . . .
1.1.2 Lequipe PARIS . . . . . . . . . . . . .
1.1.3 Lactivite de recherche (( Kerrighed )) . .
1.2 Contexte de travail . . . . . . . . . . . . . . . .
1.2.1 Introduction . . . . . . . . . . . . . . .
1.2.2 Linformatique au service de la biologie
1.2.3 Les besoins . . . . . . . . . . . . . . . .
1.2.4 Lapplication MrBayes . . . . . . . . . .

V
V
V
V
1

.
.
.
.
.
.
.
.
.

3
3
3
4
4
4
4
5
5
5

.
.
.
.
.
.
.
.
.
.
.

7
7
8
8
9
10
11
11
12
13
13
13

3 Ex
ecution diff
er
ee de processus dans Kerrighed
3.1 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.2 La gestion des processus . . . . . . . . . . . . . . . . . . . . . . . . . . .

17
17
18

.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.

2 L
etat de lart
2.1 Les grappes de calculateurs . . . . . . . . . . . . . . . . . . . . .
2.2 Gestion des travaux sur grappes de calculateurs . . . . . . . . . .
2.2.1 Introduction aux syst`emes `a execution par lots . . . . . .
2.2.2 Les principaux crit`eres devaluation . . . . . . . . . . . .
2.2.3 Les fonctionnalites des syst`emes `a execution par lots . . .
2.3 Les syst`emes `a image unique . . . . . . . . . . . . . . . . . . . .
2.3.1 Presentation . . . . . . . . . . . . . . . . . . . . . . . . .
2.3.2 Les fonctionnalites quoffrent les syst`emes `a image unique
2.3.3 Differents syst`emes `a image unique . . . . . . . . . . . . .
2.3.4 Kerrighed . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.4 Synth`ese . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.

`
TABLE DES MATIERES

II

3.3

3.2.1 La gestion des processus dans un syst`eme Linux standard


3.2.2 La gestion des processus avec Kerrighed . . . . . . . . . .
Les principes de conception . . . . . . . . . . . . . . . . . . . . .
3.3.1 Vue densemble . . . . . . . . . . . . . . . . . . . . . . . .
3.3.2 Gestion des processus differes . . . . . . . . . . . . . . . .

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

19
20
22
22
22

4 Mise en uvre dans Kerrighed


25
4.1 Mise en liste dattente dun processus differe . . . . . . . . . . . . . . . . 25
4.1.1 Introduction `a la fonction fork() . . . . . . . . . . . . . . . . . . 25
` quel moment devons nous bloquer la creation du processus? . 25
4.1.2 A
4.1.3 La capacite FORK DELAY . . . . . . . . . . . . . . . . . . . . . 26
4.1.4 Instrumentation du do fork() . . . . . . . . . . . . . . . . . . . . 27
4.1.5 Instrumentation de la structure task struct . . . . . . . . . . . . 27
4.1.6 Gestion de la liste des processus differes . . . . . . . . . . . . . . 27
4.2 Gestion du reveil des processus . . . . . . . . . . . . . . . . . . . . . . . 28
4.2.1 Presentation des differentes strategies possibles . . . . . . . . . . 28
4.2.2 Definition de linterface (API ) . . . . . . . . . . . . . . . . . . . 30
4.2.3 Reveil `a linitiative dun nud dans un anneau `a jeton . . . . . . 31
4.2.4 Reveil `a linitiative de chaque nud . . . . . . . . . . . . . . . . 33
4.2.5 Comparaison qualitative des deux strategies implementees . . . . 36
4.3 Ordonnancement des processus geres en mode differe . . . . . . . . . . . 36
4.3.1 Preambule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
4.3.2 Ordonnanceur de Kerrighed : la fonction migration manager thread() 36
4.3.3 Quand arreter un processus differe . . . . . . . . . . . . . . . . . 37
4.3.4 Detection dun processus `a arreter . . . . . . . . . . . . . . . . . 37
4.3.5 Arret dun processus differe . . . . . . . . . . . . . . . . . . . . . 37
4.3.6 Synth`ese . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
4.4 La charge virtuelle : vload . . . . . . . . . . . . . . . . . . . . . . . . . . 39
4.4.1 Le principe de la charge virtuelle (vload ) . . . . . . . . . . . . . . 39
4.4.2 Instrumentation du do exit() . . . . . . . . . . . . . . . . . . . . 40

5 Evaluation
5.1 Description du plan de tests . . . . . . . . . . . . . . .
5.1.1 Le materiel utilise . . . . . . . . . . . . . . . .
5.1.2 Notre application de simulation . . . . . . . . .

5.2 Etude
comparative . . . . . . . . . . . . . . . . . . . .

5.2.1 Etude
theorique . . . . . . . . . . . . . . . . .
5.2.2 Les resultats . . . . . . . . . . . . . . . . . . .
5.2.3 Conclusion . . . . . . . . . . . . . . . . . . . .

5.3 Etude
des performances sans la capacite de migration
5.3.1 Processus longs . . . . . . . . . . . . . . . . . .
5.3.2 Processus courts . . . . . . . . . . . . . . . . .

5.4 Etude
des performances avec la capacite de migration
5.5 Synth`ese . . . . . . . . . . . . . . . . . . . . . . . . . .

.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.

41
41
41
41
42
42
42
43
43
44
45
46
47

`
TABLE DES MATIERES
5.6

III

Ordonnancement des applications . . . . . . . . . . . . . . . . . . . . . .

48

Conclusion

51

Bibliographie

IX

Glossaire

XI

A Annexe
A.1 Le champs fd status . . . . . . . . . . . . . . . . . . . . . . .
A.1.1 int check and block(struct task struct *tsk) . . . . . .
A.1.2 int check and unblock(struct task struct *tsk) . . . . .
A.1.3 void add a pfd at the end of the list(struct task struct
A.2 Activation de la gestion des processus differes . . . . . . . . .
A.3 Reveil `a linitiative dun nud sur un anneau `a jeton . . . . .
A.3.1 La fonction handle admin(); . . . . . . . . . . . . . . .
A.3.2 La fonction handle jeton(); . . . . . . . . . . . . . . .
A.4 Pseudo-algorithme de notre application de simulation . . . .

. . . .
. . . .
. . . .
*tsk)
. . . .
. . . .
. . . .
. . . .
. . . .

.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.

XIII
XIII
XIII
XIII
XIII
XIV
XIV
XIV
XV
XVI

IV

`
TABLE DES MATIERES

R
esum
e
Le travail presente dans le rapport a ete effectue dans le cadre dun stage de fin
detude `a lIRISA de Rennes. LIRISA est une unite de recherche dont lune des activites
est le calcul `a haute performance qui peut etre obtenue par lutilisation de grappes
de calculateurs. Cependant lutilisation de ressources distribuees au sein dune grappe
nest pas simple. Kerrighed est un syst`eme dexploitation `a image unique permettant
de virtualiser un ensemble de ressources distribuees. Ainsi, lutilisateur a limpression
que sa grappe de calculateurs est comme une seule machine multiprocesseur avec une
memoire partagee entre lensemble des ordinateurs.
Nous voulons etudier le comportement de Kerrighed avec des applications de type
bio-informatique demandant beaucoup dheures de calcul et pouvant saturer tout syst`eme
informatique. Les syst`emes `a execution par lots permettent de gerer cette classe dapplication. Nous etudions de quelle mani`ere il serait possible dintegrer `a Kerrighed les
fonctionnalites des syst`emes `a execution par lots afin quil puisse gerer (( au mieux ))
lexecution de ce genre dapplication.
Mots-Cl
es : Kerrighed, Linux, syst`eme dexploitation, grappe, syst`eme distribue, syst`eme `a execution par lots, ordonnancement de processus, Fork Delay, bio-informatique,
LiveCD, Knoppix.

Abstract
We carried out our training period at IRISA, Rennes. IRISA is a research unit. One of
its research activities is about high performance computing. Nowadays, industries need
high performance computing to perform simulations. High performance computing can
be reached with clusters. Clusters are not easy to use as their resources are distributed
in different nodes. Kerrighed is a Single System Image Operating System and it eases
cluster use by providing the illusion of a single virtual multiprocessor to users. This
virtual computer provides the resources (CPU, memory, hard disk...) of the whole cluster
that appears as a single machine.
We want to study the behavior of Kerrighed with bioinformatics applications. For
that, we took contacts with a laboratory of biology in Wales. They proposed to us the
study of a class of application requiring hours of computation and being able to saturate
any information processing system. There are systems making it possible to manage this
class of application. They are called systems of batch scheduling. We study how it would
be possible to integrate into Kerrighed the functionalities of a batch scheduling system
so that it can manage (( as well as possible )) the execution of this kind of application.
Keywords : Kerrighed, Linux, operating system, cluster, distributed system, batch
scheduling, process scheduling, Fork Delay, bioinformatics, LiveCD, Knoppix.

VI

RESUM
E

Introduction
De nos jours, la puissance de calcul est de plus en plus desiree. Cela est d
u au fait
que de plus en plus de taches sont informatisees et traitees de mani`ere automatique.
Cependant, cette puissance de calcul est une ressource limitee (meme dans des centres
de calcul dedies). Elle doit donc etre geree au mieux afin den tirer un profit maximum.
Prenons par exemple le cas dune equipe de biologistes. Ils disposent dapplications
informatiques dont le temps de calcul peut depasser aisement la centaine dheures.
Dans la plupart des cas, les laboratoires de biologie ne poss`edent pas dordinateurs de
calcul dedies et les biologistes ne sont pas des specialistes en informatique. Ils veulent
cependant gerer au mieux les ressources (les ordinateurs) dont ils disposent afin dobtenir
dans les meilleurs delais leurs resultats et cela de mani`ere simple et efficace. Kerrighed est
un syst`eme dexploitation `a image unique developpe par lequipe PARIS de lIRISA. Il
offre des fonctionnalites permettant de gerer des grappes de calcultateurs. Nous voulons
etudier le comportement de Kerrighed ainsi que les ameliorations que lon pourrait lui
apporter sur une classe dapplication dans le domaine de la bio-informatique.
Nous avons decompose notre travail en plusieurs etapes. Dans une premi`ere partie
(stage dete 2005 et debut du tutorat jusquau mois doctobre), nous nous sommes
concentres sur le probl`eme de la simplicite dutilisation de Kerrighed et nous avons
obtenu une solution : le Kerrighed-LiveCD [13, 11]. Ce cederom qui est `a lorigine de
demonstration, est destine `a etre repris et adapte pour une utilisation intensive par
les laboratoires de biologie. Puis, comme exemple dapplication bio-informatique, nous
avons etudie MrBayes, et son comportement sur le syst`eme Kerrighed. MrBayes est
une application permettant de construire des arbres phylogeniques pour donner une
probabilite de liens devolution entre deux esp`eces danimaux. Cette premi`ere etape
nous a permis didentifier de nouvelles fonctionnalites `a mettre en uvre dans Kerrighed
pour une gestion efficace des ressources. La fonctionnalite majeure que nous retenons
est la gestion des ressources au sein de la grappe par execution differee des processus.
Cest ce que nous avons concu et mis en uvre `a partir du mois davril.
Dans une premi`ere partie, nous presentons notre cadre de travail. Puis, nous exposons letat de lart relatif aux grappes, aux syst`emes `a image unique et aux syst`emes
`a execution par lots. Dans une troisi`eme partie, nous indiquons larchitecture mise en
place pour la gestion des processus differes. La partie suivante precise la mise en uvre
de cette architecture. Puis, avant de conclure, nous presentons les resultats des tests
effectues.

INTRODUCTION

Chapitre 1

Pr
esentation
1.1

Le cadre de travail

Cest `a lIRISA (Institut de Recherche en Informatique et Syst`emes Aleatoires) `a


Rennes que ce tutorat est effectue. Les activites de lIRISA vont du developpement
de composants materiels `a la conception de syst`emes avances. Une trentaine dequipes
de recherche travaillent au quotidien sur differents th`emes de recherche. Les travaux
presentes ici seffectuent dans le cadre dun tutorat ENSSAT realise au sein de lequipe
de recherche PARIS (Programmation des syst`emes parall`eles et distribues pour la simulation numerique `a grande echelle). Cette equipe sinteresse `a la conception et `a la
mise en uvre de syst`emes dexploitation ainsi que de mod`eles de programmation pour
grappes de PC et dintergiciels pour les grilles de calcul et de donnees.

1.1.1

LIRISA : une unit


e de recherche

LIRISA est une unite de recherche qui regroupe 4 partenaires :


lINRIA (Institut National de Recherche en Informatique et en Automatique),
le CNRS (Centre National de la Recherche Scientifique),
lUniversite de Rennes I,
lINSA (Institut National des Sciences Appliquees).
LIRISA regroupe environ 540 pesonnes. Pr`es de la moitie sont des chercheurs ou enseignants chercheurs. Il y a egalement plus de 180 doctorants et 90 ingenieurs. Les
principaux axes des activites de recherche sont :
les reseaux et syst`emes informatiques,
la modelisation du vivant (imagerie medicale, bio-informatique),
la realite virtuelle,
la robotique,
les langages de programmation et la conception logicielle,
le traitement de donnees Signal-Texte-Son-Images et des connaissances,


CHAPITRE 1. PRESENTATION

la modelisation, la simulation et loptimisation de syst`emes complexes.


Dun point de vue structurel, les chercheurs de lIRISA travaillent au sein dequipes de
recherche dont la taille varie de 10 `a 40 personnes focalisees sur un th`eme de recherche
specifique. Chaque equipe comporte un responsable scientifique. De plus, lIRISA, dirige
par Claude Labit [16] entoure de son equipe de direction, comporte plusieurs services
administratifs. En voici les principaux :
le service des ressources humaines,
le service financier,
le service juridique,
le service des moyens informatiques (sans lequel il ne serait pas possible de travailler au quotidien !).

1.1.2

L
equipe PARIS

Les entreprises ont de plus en plus besoin de puissance de calcul pour effectuer
des simulations. Lactivite de recherche de lequipe PARIS [29] concerne les grilles,
les grappes et les fondements des syst`emes pair-`a-pair. Le projet concoit de nouveaux
mecanismes dont le but est de masquer la complexite de programmation des infrastructures parall`eles et distribuees. La contribution dans ce champ dinvestigation peut etre
synthetisee ainsi : combiner des syst`emes parall`eles et distribues tout en preservant la
transparence vis-`a-vis de lutilisateur et des performances maximales.

1.1.3

Lactivit
e de recherche (( Kerrighed ))

Un des axes de recherche de lequipe PARIS est la conception dun syst`eme dexploitation pour le calcul `a haute performance sur grappe. Cest lactivite de recherche
Kerrighed [25]. Kerrighed est un syst`eme `a image unique (dont une description plus
detaillee est donnee dans la section 2.3.4) pour grappe dont le but est doffrir une haute
performance ainsi quune haute disponibilite `a lexecution dapplications scientifiques
(sequentielles et parall`eles communiquant par message et par partage de memoire).
Lobjectif de cette activite de recherche est dapporter une solution permettant de
gerer au mieux les ressources (CPU, memoires, disque durs...) disponibles dans la grappe
pour executer des applications de simulation et de faciliter lutilisation et la programmation des grappes.

1.2
1.2.1

Contexte de travail
Introduction

Dans le but dexecuter des applications de plus en plus complexes et co


uteuses en
ressources informatiques, il devient indispensable de disposer de syst`emes permettant
de les gerer de mani`ere efficace afin de reduire au maximum leur temps dexecution. Au

1.2. CONTEXTE DE TRAVAIL

sein des laboratoires de biologie, il nest pas rare de vouloir executer des applications
dont le temps de calcul depasse la centaine dheures.
Dans le cadre de nos travaux, nous avons pris contact avec les chercheurs du laboratoire de biologie du Molecular Ecology Group `a luniversite de Bangor au Pays de
Galles. Cette equipe travaille, entre autres, sur letude des liens evolutifs existant entre
differentes populations de lezards. Un des logiciels que cette equipe est amenee `a utiliser
de mani`ere reguli`ere est lapplication MrBayes que nous detaillons en section 1.2.4.

1.2.2

Linformatique au service de la biologie

Le terme de bio-informatique regroupe toutes les applications informatiques appliquees `a la biologie [31]. Il existe differents types dapplication. Cela va de lanalyse
du genome `a la modelisation de levolution dune population animale dans un environnement donne en passant par la reconstruction darbres phylogenetiques. Ces applications sont tr`es co
uteuses en temps de calcul. Lequipe de biologistes avec laquelle nous
travaillons sinteresse `a la reconstruction darbres phylogenetiques. Ces biologistes ne
disposent pas de machines dediees au calcul. Cependant, ils veulent obtenir les resultats
de leurs simulations rapidement. Enfin, ce ne sont pas des specialistes en informatique.

1.2.3

Les besoins

Concr`etement, quelque soit la puissance de calcul disponible, selon les donnees `a


traiter, il y aura toujours possibilite de saturer un syst`eme informatique donne.
Apr`es etude de lenvironnement de travail des biologistes du Molecular Ecology
Group, nous avons pu degager quils veulent un syst`eme simple dutilisation qui g`ere
efficacement leurs ressources informatiques peu abondantes.

1.2.4

Lapplication MrBayes

MrBayes [12] est une application bio-informatique de phylogenie. Cette application


cherche sil existe des liens evolutifs entre differentes sequences genetiques qui lui sont
donnees en entree. En sortie, il donne un arbre qui decrit ces liens avec une certaine
probabilite. Il existe plusieurs methodes pour faire ces calculs. MrBayes en utilise une
particuli`ere qui consiste `a calculer la vraisemblance de chaque arbre et `a choisir celui
presentant la plus forte vraisemblance. En pratique cela nest pas realisable (temps
de calcul beaucoup trop long). De ce fait, lapplication utilise un algorithme MCMC
(Markov Chain Monte Carlo) pour obtenir un echantillon de la distribution de ces
arbres.
En effet, meme si au depart nous disposons dune tr`es grande puissance de calcul
pouvant donner un resultat de lapplication MrBayes en moins dune heure pour un
jeu de donnees, il est tout `a fait possible, en rajoutant dautres sequences en entree,
daugmenter de mani`ere considerable le temps de calcul.
Or, les utilisateurs biologistes ne poss`edent generalement pas dordinateurs specifiques
dedies aux calculs (ils utilisent dans la majorite des cas leur ordinateur de bureau) et
ils ne sont pas forcement specialistes des syst`emes informatiques.

CHAPITRE 1. PRESENTATION

Il nous faut donc trouver une solution permettant dutiliser au mieux plusieurs
ordinateurs physiquement independants en vue de la realisation dune meme tache.

Chapitre 2

L
etat de lart
Une grappe de calculateurs est un ensemble dordinateurs (que lon appelle egalement
nud) interconnectes et vus de lutilisateur comme une meme unite de traitement. Les
syst`emes `a image unique sont des syst`emes dexploitation qui permettent de masquer la
complexite des syst`emes distribues et donc celle des grappes. En employant un syst`eme
`a image unique sur une grappe, lusager a alors limpression de nutiliser quun seul
ordinateur alors quil en utilise plusieurs interconnectes par un reseau rapide.
De plus, il existe dautres syst`emes informatiques permettant de reguler une charge
de travail sur un ensemble dordinateurs disponibles. Ce sont les syst`eme `a execution
par lots. Ils permettent une gestion efficace des differentes ressources (vu de la grappe,
chaque nud est une ressource car il contient de la memoire, des processeurs. . . ) au
sein de la grappe.
Nous etudions dans les sections suivantes la bibliographie relative `a ces differents
syst`emes.

2.1

Les grappes de calculateurs

Une grappe de calculateurs est un ensemble de machines independantes interconnectees le plus souvent par un reseau rapide (dans le domaine de la haute performance)
et vu comme une seule unite de traitement par lutilisateur [17, 14]. Ces architectures
sont generalement beaucoup moins ch`eres que des calculateurs parall`eles `a puissance
equivalente.
Cependant, bien quelles puissent etre une bonne alternative aux supercalculateurs,
les grappes restent des architectures distribuees dont la programmation est complexe.
Une solution consiste `a utiliser un syst`eme `a image unique (Single System Image - SSI)
dont le but est de masquer la distribution (et donc la complexite) des ressources aux
utilisateurs.
Les grappes sont tr`es utilisees pour faire des calculs en parall`ele. La charge du
syst`eme (nombre doperations que le syst`eme est en train executer, voir la section 2.2.1)
augmente considerablement si sur une meme grappe, des centaines dutilisateurs lancent
simultanement des centaines de calculs. Plus la charge augmente, et plus le risque que la


CHAPITRE 2. LETAT
DE LART

grappe devienne indisponible augmente. Afin de pouvoir gerer des ressources partagees
entre de multiples utilisateurs, des syst`emes `a execution par lots ont ete mis en place.

2.2
2.2.1

Gestion des travaux sur grappes de calculateurs


Introduction aux syst`
emes `
a ex
ecution par lots

D
efinitions
La charge moyenne dun processeur (load average). La charge dun syst`eme [32,
10] represente la quantite de travail quil est en train de traiter. La charge moyenne dun
syst`eme represente ainsi la charge du syst`eme sur un temps donne. Conventionnellement,
cette charge est donnee selon trois valeurs decrivant la charge moyenne du syst`eme sur
la derni`ere minute, les cinq derni`eres minutes, et les quinze derni`eres minutes 1 .
Les syst`
emes `
a ex
ecution par lots. En informatique une execution par lots [33, 30]
est un enchanement automatique de commandes sans intervention dun operateur. Les
travaux lances par ce type de syst`eme sont non-interactifs. Voici quels sont leurs interets :
partage des ressources informatiques heterog`enes entre plusieurs utilisateurs (gestion de la concurrence dacc`es aux ressources),
gestion efficace de la charge moyenne du syst`eme selon la disponibilite des differents
nuds (au sein dune meme grappe, certains nuds peuvent executer une application alors que dautres nuds executent une autre application).
Pr
esentation
De plus en plus, les architectures distribuees simposent dans le monde du calcul
a` haute performance [1]. Cependant, lutilisation de ces syst`emes est complexe. Pour
les simplifier, il a ete mis au point des mecanismes permettant de gerer lexecution des
travaux sur un certain nombre de ressources disponibles, cela dans le but de les gerer
au mieux.
Du point de vue du syst`eme, il est important dutiliser en continu toutes les ressources disponibles. Cela a pour effet daugmenter la charge du syst`eme. Du point de
vue de lutilisateur, linteractivite du syst`eme est primordiale cest `a dire que le temps
de reponse du syst`eme doit etre le plus faible possible (il faut donc, que le syst`eme ait
une faible charge).
Pour executer un travail sur un syst`eme `a execution par lots, lutilisateur doit
generalement ecrire un fichier de description des ressources [3]. Ce fichier est un simple
fichier texte contenant des mots-cles permettant dindiquer le nom du travail, le type
de plate-forme desiree, le temps maximum dutilisation.
Le travail ainsi que sa description sont envoyes `a lordonnanceur global du syst`eme
`a execution par lots. Ce dernier poss`ede une connaissance globale de letat de toutes
1. Sur un syst`eme Linux standard, la commande top fournit la charge moyenne du syst`eme.

2.2. GESTION DES TRAVAUX SUR GRAPPES DE CALCULATEURS

les ressources du syst`eme, et cest lui qui distribue les travaux en liste dattente sur les
differents nuds.
La figure 2.1 montre une representation simplifiee dun syst`eme `a execution par
lots. Le nud-matre recoit toutes les soumissions des utilisateurs. Il a une parfaite
connaissance de letat de ses ressources. Il attribue donc au mieux les taches (du point
de vue de ladministration) `a executer sur les ressources disponibles en essayant davoir
une charge plutot elevee.

Fig. 2.1 Representation simplifiee dun syst`eme `


a execution par lots

2.2.2

Les principaux crit`


eres d
evaluation

Un syst`eme `a execution par lots doit repondre `a trois grandes fonctionnalites [3] :
Est-il simple dutilisation ? Quelles sont les manipulations que lutilisateur doit
faire afin dexecuter ses applications? Peut-il utiliser une interface de soumission standard au syst`eme Unix ou doit-il utiliser un syst`eme specifique au gestionnaire dexecution
par lots utilises? Est-il robuste et tolerant aux fautes?
Est-il simple dadministration ? Que doit configurer ladministrateur pour que le
syst`eme fonctionne? Combien de temps doit-il consacrer au syst`eme pour le maintenir
`a jour?
Est-il compatible avec les applications existantes ? Les applications existantes
fonctionnent-elles sans modification avec le syst`eme `a execution par lots ? Faut-il les
recompiler?

10

CHAPITRE 2. LETAT
DE LART

Ces crit`eres sont `a garder en memoire, car ils vont nous guider tout au long de notre
travail.

2.2.3

Les fonctionnalit
es des syst`
emes `
a ex
ecution par lots

Il existe beaucoup de syst`emes realisant des executions par lots [6, 5, 1, 3, 24, 22,
2, 8, 7]. Nous enumerons ici leurs principales fonctionnalites. Tout dabord, un syst`eme
`a execution par lots est capable de differer lexecution de processus. Cest-`a-dire que
lorsque lutilisateur execute son application, le syst`eme peut decider de ne lexecuter
que plus tard si les ressources necessaires pour lexecution de lapplication ne sont pas
disponibles par exemple.
Le nud coordinateur : les syst`emes `a execution par lots sont capables de gerer
des ressources heterog`enes. Ils disposent pour la plupart dun nud coordinateur (ou
nud-matre, vu sur la figure 2.1) qui centralise toutes les requetes des utilisateurs et
qui a une vision globale de letat (actif / inactif) de lensemble des ressources dont
il dispose. Ces ressources sont generalement hererog`enes (ces ressources peuvent etre
pour certaines sous syst`eme Unix, dautres sous SunOS. . . ). Le nud coordinateur doit
alors etre capable de gerer lheterogeneite des ressources. Ce nud coordinateur execute
une politique dordonnancement parametree par ladministrateur du syst`eme ou bien
par lutilisateur lui meme sil en a les droits. Le probl`eme de lutilisation dun nud
coordinateur est que si celui-ci devient defaillant, alors lensemble des travaux de la
grappe peut etre perdu.
La migration de processus : selon les syst`emes, ce coordinateur peut, si besoin,
deplacer des applications dune ressource `a une autre. Cette capacite de migration dun
processus permet par exemple `a un processus detre deplace dun nud A `
a un nud B si
2
le nud A devient defaillant . Cela evite au processus de se faire arreter prematurement
et de perdre ainsi tout le travail quil a pu faire depuis sa creation.
La gestion des points de reprise dapplications : le nud coordinateur peut
decider darreter les applications en cours dexecution ou de les redemarrer. Les mecanismes
de sauvegarde et restauration de points de reprise permettent, par exemple, `a lordonnanceur de stopper lexecution dun processus dans le cas o`
u un processus de priorite
superieure viendrait `a requisitionner cette meme ressource. Puis, lors de la terminaison
du processus de forte priorite, lorsque la ressource redevient libre, lordonnanceur peut
redemarrer le processus prealablement arrete.
Gestion dynamique des applications : nous appelons gestion dynamique dapplication le fait de changer la politique dordonnancement vis-`a-vis dune application en
cours dexecution de celle-ci. Dune mani`ere generale les syst`emes `a execution par lots
2. Il existe des mecanismes permettant de detecter une defaillance imminente dun nud (exemple,
augmentation brutale de la temperature).

`
` IMAGE UNIQUE
2.3. LES SYSTEMES
A

11

ne sont pas capable de gerer des applications dynamiques. En effet prenons lexemple
dune application necessitant une ressource processeur. Si au cours de son execution
cette application evolue et a besoin dune seconde ressource processeur la plupart des
syst`emes `a execution par lots ne chercheront pas `a replacer correctement lapplication
sur deux ressources processeur, mais vont la laisser sur une seule ressource processeur,
qui est celle de depart.
La tol
erance aux fautes : certains syst`emes sont tolerants aux fautes. Cela signifie
quen cours dexecution de lapplication, si un nud vient `a defaillir, alors le syst`eme
peut redemarrer lapplication qui etait executee sur ce nud.
Nous comparons maintenant trois syst`emes `a executions par lots qui sont LoadLeveler,
Condor et Torque (le tableau 2.3 synthetise la comparaison de ces trois syst`emes) :
LoadLeveler [8] est un syst`eme commercialise par IBM Corp. depuis plus de 15
ans. Sa stabilite nest plus `a demontrer. Lutilisateur soumet ses travaux par lintermediaire de scripts en ligne de commande ou par interface graphique. Les travaux restent en liste dattente tant que les ressources ne sont pas disponibles. Ce
syst`eme permet la migration de processus `a condition que ceux-ci aient ete lies
avec les librairies de LoadLeveler. Enfin, la tolerance aux fautes de ce syst`eme est
limitee car si une defaillance intervient sur une application, alors le syst`eme tente
de relancer lapplication depuis le debut de son execution (le syst`eme perd tout le
travail effectue par le processus depuis sa creation).
Condor [24] est un syst`eme `a execution par lots qui utilise les ressources des
stations de travail des utilisateurs lorsquelles sont inutilisees. Il est necessaire
dexecuter des applications qui sont liees avec les librairies Condor (donc refaire
une edition de liens de lapplication). Ce gestionnaire existe depuis 1994 et est tr`es
utilise dans le milieu academique. Il est robuste et fiable. De nombreuses extensions ont par ailleurs ete developpees afin de le rendre plus fonctionnel. Condor
dispose des meme fonctionnalites que LoadLeveler en proposant `a lutilisateur une
meilleure tolerance aux fautes (en cas de defaillance, il redemarre lapplication depuis le dernier point de reprise realise et non depuis le debut de lexecution).
Torque [7] anciennement connu sous le nom de Portable Batch System (PBS)
est tr`es utilise dans le milieu industriel. Il dispose de nombreuses fonctionnalites
permettant de gerer avec une grande precision lordonnancement des travaux sur
les ressources.

2.3
2.3.1

Les syst`
emes `
a image unique
Pr
esentation

Un syst`eme `a image unique a pour but de donner lillusion quun ensemble de ressources distribuees ne forme quune seule ressource partagee (cest-`a-dire quun ensemble

12

CHAPITRE 2. LETAT
DE LART

dordinateurs independants forme un ordinateur virtuel multiprocesseur). Un syst`eme


`a image unique ideal doit fournir quatre proprietes :
La transparence `a la distribution : il nest pas necessaire de nommer un nud pour
acceder `a ses ressources,
La transparence `a lutilisation : une application doit fonctionner avec la meme
simplicite sur un syst`eme `a image unique que sur un syst`eme standard,
La s
urete de fonctionnement : si lon consid`ere une grappe comme une machine
virtuelle unique composee de plusieurs machines reelles, la defaillance de lune
dentre-elles ne doit pas entraner la defaillance de toute la grappe,
Lextensibilite : lajout de ressources `a la grappe doit etre pris en compte automatiquement par le syst`eme.

2.3.2

Les fonctionnalit
es quoffrent les syst`
emes `
a image unique

Afin de gerer de mani`ere transparente lexecution dapplications au sein de la grappe,


les syst`emes `a image unique disposent comme les syst`emes `a execution par lots de
mecanismes leur permettant de gerer de differentes mani`eres les processus et les ressources de la grappe. Nous allons reprendre les fonctionnalites decrites pour les syst`emes
`a execution par lots en section 2.2.3 afin de montrer les differences avec les syst`emes `a
image unique.
Le nud coordinateur : par definition, un syst`eme `a image unique ne peut disposer
dun nud coordinateur. En effet, cela serait contraire aux principes de transparence, de
s
urete de fonctionnement et dextensibilite enonces en section 2.3.1. De plus, un syst`eme
`a image unique g`ere des ressources homog`enes. Il nest pas possible davoir des syst`emes
Unix, SunOS. . . geres par un meme syst`eme `a image unique.
La migration de processus : Les syst`emes `a image unique peuvent generalement
deplacer des processus (comme les syst`emes `a execution par lots). Par exemple, si nous
lancons plusieurs calculs sur une grappe, il est possible que certains nuds finissent
leurs calculs avant dautres, alors le syst`eme dexploitation va deplacer des processus
afin dequilibrer la charge de la grappe.
La gestion des points de reprise dapplications : dans le cas dexecution dapplications de longue duree, la probabilite quune defaillance materielle se produise est
grande (comme dans les syst`emes `a execution par lots). De plus, il est egalement possible, si lutilisateur ne dispose pas de ressources dediees au calcul quil ne veuille pas
tout executer dune seule traite, mais plutot, en plusieurs morceaux (exemple, du calcul
pendant la nuit et du travail bureautique la journee).
Gestion dynamique des applications : les syst`emes `a image unique sont capables
dequilibrer le placement des processus dune application sur la grappe en cours dexecution
de lapplication. Par exemple, si au depart une application cree un processus qui necessite

`
2.4. SYNTHESE

13

comme ressource un processeur et quau cours de son execution elle cree un autre processus, le syst`eme `a image unique essaye dequilibrer la charge induite par ce nouveau
processus en cours dexecution de lapplication.
La tol
erance aux fautes : elle est identique `a celle des syst`emes `a execution par lots.

2.3.3

Diff
erents syst`
emes `
a image unique

Il existe differents syst`emes `a image unique tel que OpenMOSIX, OpenSSI, Kerrighed [26, 27, 25]. Tous ont pour but de rendre les grappes de calculateurs fiables, simples
dutilisation et performantes [18]. Nous presentons dans le tableau 2.3 une comparaison des fonctionnalites entre les syst`emes OpenMOSIX et Kerrighed. Lanalyse de cette
comparaison montre que ces deux syst`emes offrent des fonctionnalites similaires si ce
nest que OpenMOSIX est plus tolerant aux fautes et plus stable que Kerrighed. Cependant Kerrighed offre la fonctionnalite de sauvegarde de points de reprise dapplication
que OpenMOSIX ne permet pas.

2.3.4

Kerrighed

Kerrighed est un syst`eme `a image unique qui virtualise les ressources disponibles
dans la grappe par extension du noyau Linux. Vu de lutilisateur, lutilisation dune
grappe Kerrighed devient alors tr`es semblable `a celle dun unique PC Linux multiprocesseur.
Concr`etement, si lon dispose de 6 ordinateurs equipes chacun separement dun processeur, de 512Mo de memoire et de 2Go de disque dur, avec le syst`eme Kerrighed,
lutilisateur aura (( limpression )) de travailler sur une machine multi-processeur (SMP)
disposant de 6 processeurs avec 512 6 = 3072M o de memoire, et 2 6 = 12Go de
disque dur. La figure 2.2 represente cet exemple dans le cadre dune architecture multiprocesseur et dune architecture de grappes.

2.4

Synth`
ese

Il existe des syst`emes permettant de reguler la charge de travail sur une grappe
de calculateurs. Ces syst`emes sont appeles syst`emes `a execution par lots. Ils sont noninteractifs. Les utilisateurs soumettent leurs travaux et veulent obtenir un resultat final sans interaction avec lapplication pendant son execution. Ces syst`emes sont bien
adaptes `a un environnement compose de ressources heterog`enes et permettent de gerer
efficacement la concurrence dacc`es `a ces ressources.
Il existe egalement des syst`emes permettant de donner lillusion `a lutilisateur de
travailler sur une machine multi-processeur alors quune grappe est constituee en realite
de plusieurs machines interconnectees par un reseau. Ces syst`emes sont appeles syst`emes
`a image unique. Les utilisateurs peuvent utiliser ces syst`emes comme sil sagissait dune
machine virtuelle multiprocesseur. Lutilisateur peut ainsi lancer des travaux interactifs
et interagir avec lapplication pendant son execution.

14

CHAPITRE 2. LETAT
DE LART

Fig. 2.2 Architecture SMP vs grappe


Nous voulons etudier en quoi, il serait possible dintegrer un syst`eme `a execution
par lots directement dans un syst`eme `a image unique. Le tableau 2.3 synthetise les fonctionnalites definies precedemment en section 2.2.3 pour differents syst`emes `a execution
par lots et en section 2.3.2 pour differents syst`emes `a image unique.
En bilan de ce tableau nous pouvons dire que la fonctionnalite principale, afin de
gerer lacc`es conccurrent `a des ressources distribuees, est lexecution differee des processus. Un syst`eme permettant lexecution differee dune application soumise par un
utilisateur peut alors gerer les ressources dont il dispose selon une politique dordonnancement definie par ladministrateur. De plus, dautres fonctionnalites peuvent ameliorer
lefficacite des syst`emes `a execution par lots, `a savoir : la migration de processus, la
sauvegarde de points de reprise et la tolerance aux fautes. Or ces fonctionnalites sont
presentes en partie dans les syst`emes `a image unique cites.
Nous allons maintenant etudier sil serait possible et utile dintroduire une fonctionnalite dexecution differee des processus dans Kerrighed.

`
2.4. SYNTHESE

15

Syst`eme
Stabilite
Remarques,
dutilisation

domaine

Heterogeneite
des
syst`emes
Absence dun nud coordinateur
Migration de processus
Gestion des points de
reprise dapplications
Gestion
dynamique
dapplications
Execution differee dapplications
Ordonnanceur global
Tolerances aux fautes

LoadLeveler
Stable
Version
commerciale,
industrie

Condor

Torque

Kerrighed

Stable
Recherche,
industrie

OpenMOSIX
Stable
En
developpement

Stable
Academique

Limite

Limite

Instable
En
developpement

Fig. 2.3 Comparaison entre differents syst`emes de traitement `


a execution par lots

16

CHAPITRE 2. LETAT
DE LART

17

Chapitre 3

Ex
ecution diff
er
ee de processus
dans Kerrighed
MrBayes [12] est une application de construction darbres phylogenetiques. Ces
arbres permettent detudier les liens devolution existant entre differentes populations
danimaux. Lequipe de biologistes, avec laquelle nous sommes en contact, utilise MrBayes pour etablir les liens existant entre differentes populations de lezard.
MrBayes est un programme probabiliste. Cest-`a-dire que pour obtenir un resultat,
il est necessaire dexecuter plusieurs fois le meme calcul afin de voir si tous convergent.
De plus MrBayes est une application de longue duree. Il est courant davoir des temps
de calcul superieurs `a la centaine dheures !
MrBayes est donc une application de longue duree quil faut executer plusieurs
fois afin dobtenir des resultats fiables. MrBayes est representatif dune classe dapplication bio-informatique : execution de multiples processus de longue duree simultanement.
Nous voulons donc concevoir un syst`eme permettant de repartir au mieux lexecution de
ces applications sur la grappe afin davantager au maximum lensemble des utilisateurs.

3.1

Motivation

En conclusion des tests realises avec MrBayes sur Kerrighed, il sest avere quil
pourrait etre interessant dimplementer au sein meme de Kerrighed une fonctionnalite
de creation de processus differee. Cela nous permettrait de concilier la soumission interactive dapplication (`a travers le syst`eme `a image unique `a la mani`ere dun syst`eme
Linux standard) et sa gestion differee comme le fait un syst`eme `a execution par lots
(cette fois-ci de mani`ere non interactive).
Prenons le cas dun laboratoire de biologie compose de six personnes et ne disposant
que de trois ordinateurs. Pour leurs travaux, ils ont besoin dexecuter reguli`erement des
calculs tr`es longs (superieurs `a la centaine dheures). Dans letat actuel du developpement
de Kerrighed, si les six personnes du laboratoire lancent chacune un calcul de 100
heures sur la grappe, les six calculs vont sexecuter en concurrence. Chaque nud va
executer deux calculs simultanement. Vu de lutilisateur, les resultats des calculs ne


EE
DE PROCESSUS DANS KERRIGHED
18 CHAPITRE 3. EXECUTION
DIFFER
seront obtenus quau bout de 200 heures. Dans ce cas dutilisation, les 6 utilisateurs
sont (( penalises )) par le calcul des autres.
Afin de remedier `a cela, une possibilite serait de retarder lexecution dun processus
lors de sa creation (explique en section 4.1.1) : si les ressources sont jugees suffisantes
par Kerrighed, alors, le processus est execute, sinon il est mis en file dattente.
Reetudions lexemple precedent : lorsque les six utilisateurs lancent leur calcul, seulement trois dentre-eux sont executes immediatement. Les trois autres calculs sont mis
en file dattente et sont executes lorsque les premiers calculs sont termines. De ce fait,
trois utilisateurs obtiennent leurs resultats au bout de 100 heures de calculs, et trois utilisateurs ont leurs resultats au bout de 200 heures de calculs (comme pour le cas decrit
precedemment). Grace `a cette methode, 50% des utilisateurs benificient dun temps de
calcul minimum et les autres nobtiennent pas leurs resultats avec des delais superieurs
`a ceux quils auraient eus dans le premier cas.
De plus, nous pouvons pousser plus loin notre raisonnement. En effet, dans le cadre
dune gestion de travaux de type syst`eme `a execution par lots, le syst`eme doit reguler
lensemble des travaux en attente en fonction de ses ressources disponibles. Prenons
le cas o`
u, dans lexemple precedent, une ressource venait `a disparatre (defaillance
materielle, ou tout simplement lexecution dun processus dune forte priorite sur la ressource en question). Cela risque dentraner une augmentation de la charge. Le syst`eme
doit donc etre capable de la reduire au mieux en cherchant `a faire des migrations, et
le cas echeant en arretant les processus differes en cours dexecution. Lorsque les ressources sont de nouveau disponibles (exemple : la fin dexecution du calcul de plus forte
priorite), le syst`eme reprend lexecution des processus differes l`a o`
u il lavait arretee.
Bilan. Une charge excessive sur une grappe peut entraner leffondrement de celleci. Il faut donc au maximum, reguler lexecution des taches lourdes et co
uteuses en
ressources. Cette administration des taches doit se faire de la mani`ere la plus simple
possible.
De plus Kerrighed dispose nativement de fonctionnalites utilisees par les syst`emes `a
execution par lots comme la migration, la gestion des points de reprise, lordonnanceur
global.
Nous avons donc `a concilier soumission interactive et execution differee de travail directement au sein du syst`eme dexploitation Kerrighed sans passer par des intermediaires
de type syst`eme `a execution par lots en rajoutant dans Kerrighed la fonctionnalite de
gestion de processus differes.

3.2

La gestion des processus

Le concept de processus [4] est fondamental dans tous les syst`emes dexploitation
multitache. Typiquement, un processus designe une instance dun programme en cours
dexecution.
Un processus est cree (generalement par appel `a la fonction fork() de lespace utilisateur), il dispose dune duree de vie plus ou moins longue, il peut avoir des fils, et

3.2. LA GESTION DES PROCESSUS

19

meurt par la suite.


Du point de vue du noyau, un processus est une entite qui cherche `a allouer des
ressources (du temps CPU, de la memoire. . . ).

3.2.1

La gestion des processus dans un syst`


eme Linux standard

Description dun processus.


Un processus est decrit par une structure contenant toutes les informations relatives `a celui-ci (task struct). Cette structure est creee et initialisee `a chaque creation
dun nouveau processus (par exemple, la fonction fork() de lespace utilisateur fait
syst`ematiquement appel `a la fonction syst`eme do fork() de lespace noyau). Lors de
cette creation, le processus recoit un identifiant unique (Process IDentifiant - PID).
Les diff
erents
etats dun processus.
Un processus peut avoir plusieurs etats au cours de son execution. Il peut etre en
cours dexecution (elu), ou en attente dexecution (eligible) dans la file des eligibles. Il
peut egalement etre interrompu lorsquil attend une ressource non disponible, ou stoppe,
lorsquil recoit par exemple un signal SIGSTOP provenant de lutilisateur (nous donnons
plus dinformations sur le concept de signaux dans les paragraphes suivants). Il peut
etre dans letat zombie, cest-`a-dire que lexecution du processus est terminee mais que
le p`ere du processus na pas encore ete averti. Il peut etre mort, cest le dernier etat
possible quun processus peut prendre pendant quil est en train detre retire du syst`eme
(exit). Un autre etat particulier est celui trace, cest lorsque le processus a ete stoppe
par un debogueur par exemple.
La file des
eligibles.
Lorsque le noyau veut executer un processus, il en prend un dans la file des eligibles
[9]. Si le processus se fait interrompre, il est retire de la file des eligibles. Le noyau
prend alors un autre processus `a traiter dans la file des eligibles. Lorsque le processus
interrompu se fait reveiller par exemple par un signal lui indiquant que la ressource
quil attendait est maintenant libre, alors, ce processus repart dans la file des eligibles
et lorsque le noyau le decidera, il sera de nouveau execute. La figure 3.1 represente
schematiquement le deroulement de lexecution dun processus.
Les signaux
Les signaux sont des messages qui sont envoyes 1 `a des groupes de processus. Ces messages sont en realite des nombres identifies par un nom dont le prefixe est SIG. Il existe
une trentaine de signaux Linux/i386 dont les plus connus sont : SIGINT (interruption,
d
u par exemple `a la suite dune frappe au clavier : Ctrl-C), SIGKILL (arret immediat du
processus), SIGTERM (signal de terminaison, demande darret dun processus). Ainsi,
1. La commande kill permet sur un syst`eme Linux standard denvoyer un signal `
a un processus.


EE
DE PROCESSUS DANS KERRIGHED
20 CHAPITRE 3. EXECUTION
DIFFER

Fig. 3.1 Representation simplifiee du deroulement de lexecution dun processus


un signal agit comme une (( sonnerie )) qui avertit un processus dun ev`enement synchrone (dans le cas dun signal attendu par programmation) ou asynchrone (dans le cas
dun signal venant de lexterieur du programme).
Ordonnancement des processus
Pour donner limpression `a lutilisateur dune execution simultanee de plusieurs processus sur une meme unite de traitement, il a ete mis en place un mecanisme dordonnancement permettant au noyau de passer de lexecution dun processus `a un autre
en un laps de temps tr`es court. Ainsi, vu de lutilisateur, tous les processus qui sont
eligibles progressent simultanement.

3.2.2

La gestion des processus avec Kerrighed

Kerrighed reprend tous les concepts definis precedemment pour tout ce qui concerne
la gestion des processus, `a quelques exceptions pr`es du fait des specifites liees `a Kerrighed.
Identifiant de processus
Dans le cadre dun syst`eme `a image unique, il est necessaire `a des fins de transparence
quun processus ait un identifiant unique sur toute la grappe. Ainsi, lattribution de cet
identifiant est globale `a la grappe et non locale `a un nud.
Les capacit
es
Kerrighed offre `a lutilisateur la possibilite de donner des capacites aux processus.
Une capacite est un attribut donne `a un processus qui lui permet davoir des fonctionnalites en plus. Par exemple, nous pouvons donner `a un processus la capacite de migration.
Dans ce cas, le processus peut etre deplace dun nud `a un autre. Les capacites peuvent

3.2. LA GESTION DES PROCESSUS

21

sappliquer au processus courant, aux processus fils ou aux deux. On peut alors definir
une notion dheritage des capacites.
La migration. Cest une capacite qui une fois donnee `a un processus lui permet
detre deplace dun nud `a un autre. Cette migration peut etre faite sur demande
de lordonnanceur de la grappe, ou sur demande de lutilisateur. Prenons un exemple
simple : nous dispons de deux nuds. Sur le nud numero 0 nous lancons 2 processus
ayant la capacite de migration. Lordonnanceur va alors decider de migrer un des deux
processus crees du nud 0 vers le nud 1. Cest ce que lon appelle faire de lequilibrage
de charge.
La cr
eation de processus `
a distance. Cette capacite permet `a un processus de
creer ses fils directement `a distance sur dautres nuds. Cela est utile par exemple dans
le cas de processus tr`es courts pour lesquels le temps de migration entranerait une
surcharge considerable, compare au temps dexecution du processus lui-meme. Dans ces
conditions, il vaut mieux directement creer le processus sur le nud distant.
Les points de reprise dapplications. La capacite de point de reprise permet de
sauvegarder letat dune application `a un instant t. Ses usages sont multiples :
Un utilisateur realise un long calcul. Cependant, pour une raison quelquonque, il
doit eteindre sa grappe. Il peut donc sauvegarder letat de son application, puis
lorsque sa grappe sera de nouveau operationnelle, il pourra reprendre lexecution
de son calcul l`a o`
u il lavait arrete.
Dans le cadre des calculs `a haute performance, si un nud vient `a defaillir, il est
possible de ne pas reprendre depuis le debut tous les calculs executes sur ce nud
mais les reprendre seulement depuis la derni`ere sauvegarde de lapplication.
Lordonnanceur global `
a la grappe
Son principe est le meme que pour un ordonnanceur Linux standard `a la difference
que cet ordonnanceur a la connaissance de toute les ressources disponibles sur la grappe
enti`ere, et peut prendre des decisions dordonnancement en consequence. Lordonnanceur Linux g`ere les processus au sein dun nud alors que lordonnanceur global de
Kerrighed g`ere les processus au sein de la grappe.
Les signaux Kerrighed
Kerrighed permet de definir des signaux `a envoyer au processus. Ces signaux sont
personnalisables. Pour envoyer un signal Kerrighed `a un processus, il faut lui specifier
une action (cela se fait en remplissant un champ de la task struct du processus), puis
envoyer le signal par lintermediaire dune fonction que nous etudions en section 4.3.5.


EE
DE PROCESSUS DANS KERRIGHED
22 CHAPITRE 3. EXECUTION
DIFFER

3.3
3.3.1

Les principes de conception


Vue densemble

Nous cherchons `a mettre en uvre au sein de Kerrighed une fonctionnalite permettant de gerer selon les ressources disponibles de la grappe la creation de nouveaux
processus. Le but est de pouvoir lancer des processus en mode interactif tout en donnant au syst`eme la possibilite den differer lexecution si la charge courante est trop
importante. Cela est effectue dans le but dallier la simplicite dutilisation dun syst`eme
`a image unique `a lexecution differee de processus permettant une meilleure gestion des
ressources comme le font les syst`emes `a execution par lots. Nous appelons un processus
differe, un processus qui a la capacite de ne pas etre execute immediatement lors de sa
creation et dont lexecution peut etre suspendue et reprise sur ordre de lordonnanceur
global du syst`eme afin de reguler la charge de la grappe.
Les objectifs `a atteindre sont les suivants :
lancer lexecution de processus uniquement lorsque les ressources de la grappe le
permettent,
arreter des processus differes en cours dexecution si la charge venait `a selever de
mani`ere importante,
cest-`a-dire, conserver la gestion des processus standard et y adjoindre un nouveau type
de processus dont lexecution nest pas immediate et peut etre suspendue `a tout moment.
Nous venons de definir implicitement deux espaces de processus : les processus standard geres par le noyau Linux, et ceux differes geres par le module Kerrighed. Nous
verrons en section 4.1.3 comment nous differencions ces deux espaces de processus.

3.3.2

Gestion des processus diff


er
es

Pr
esentation
Voici comment fonctionne la gestion des processus differes :
Si un utilisateur specifie au syst`eme dutiliser la gestion de processus differe pour
une de ses applications, cela signifie que tout appel `a la fonction fork() de son
application va entraner la creation dun processus differe qui est alors directement
mis dans la liste dattente des processus differes.
Lordonnanceur de la grappe reveille les processus differes en attente selon la
disponibilite des ressources.
Lordonnanceur de la grappe deplace ou stoppe des processus differes en cours
dexecution si la charge augmente de mani`ere importante.
Description d
etaill
ee
Nous pouvons maintenant decrire le fonctionnement de la gestion des processus
differes en differentes parties independantes :
Un processus differe est directement mis en liste dattente (voir section 4.1).

3.3. LES PRINCIPES DE CONCEPTION

23

Les processus de cette liste dattente sont reveilles par ordre de lordonnanceur
selon une politique definie par ladministrateur (voir section 4.2).
Les processus differes en cours dexecution peuvent etre deplaces, ou stoppes de
mani`ere totalement transparente (voir section 4.3).
La politique dordonnancement de notre syst`eme est fondee sur la charge dun
nud `a un instant donne. Kerrighed dispose de sondes (reelles) donnant la charge
des nuds. Or la valeur donnee par une sonde (reelle) peut mettre deux `a trois
secondes avant detre actualisee. Nous avons d
u definir une nouvelle sonde (virtuelle) permettant de corriger la valeur donnee par la sonde reelle (voir section
4.4).
La figure 3.2 resume la gestion des processus differes en presentant lordonnanceur global `a Kerrighed qui g`ere le placement des processus differes entre les
differents nuds de la grappe. On y voit aussi les ordonnanceurs locaux standard
de chaque nud gerer de mani`ere standard lensemble des processus locaux `a
chaque nud.


EE
DE PROCESSUS DANS KERRIGHED
24 CHAPITRE 3. EXECUTION
DIFFER

Fig. 3.2 Architecture generale de la gestion des processus differes au sein dune grappe
Kerrighed

25

Chapitre 4

Mise en uvre dans Kerrighed


Nous implementons dans Kerrighed un mode de gestion particulier des processus
que nous appelons mode differe. Ce mode permet `a un processus de netre execute que
lorsque la charge du syst`eme le permet.
Dans une premi`ere partie nous voyons comment se passe la creation dun processus
differe. Puis nous etudions les algorithmes permettant le reveil des processus qui ont ete
mis en liste dattente des processus differes. La section suivante explique la mani`ere dont
sont ordonnances les processus differes. Enfin, nous terminons cette partie en mettant
en uvre une optimisation permettant dobtenir de meilleures performances dans la
gestion des processus differes : la charge virtuelle.

4.1
4.1.1

Mise en liste dattente dun processus diff


er
e
Introduction `
a la fonction fork()

Dans un syst`eme Linux, la fonction fork() [4, 21, 20] permet de dupliquer un pro` lappel de la fonction, le processus p`ere est clone. La fonction fork() renvoie
cessus. A
0 au processus fils et renvoie lidentifiant du processus (PID) fils au p`ere.
La fonction fork() execute un appel `a la fonction syst`eme do fork(). Cette fonction
clone le processus p`ere en differentes etapes importantes :
allocation de lidentifiant de processus pour le processus fils : pid = alloc pidmap();
clonage du processus p`ere : p = copy process(pid);
premier reveil du processus fils : wake up new task(p);
retour de lidentifiant du fils au p`ere : return pid;

4.1.2

` quel moment devons nous bloquer la cr


A
eation du processus ?

Dans le cadre dune execution differee des processus, nous devons bloquer la creation
dun processus differe `a un moment donne. Lanalyse du fonctionnement du do fork()
nous m`ene vers trois possibilites :
bloquer la creation du processus fils avant dexecuter le do fork(),

26

CHAPITRE 4. MISE EN UVRE DANS KERRIGHED


bloquer la creation du processus fils dans le do fork(),
stopper le processus fils une fois sa creation terminee apr`es le do fork().

Avant le do fork()
En bloquant la creation du processus fils avant le do fork() :
le p`ere se retrouve bloque (il ne peut pas changer detat car sinon, le copy process()
ne serait pas valide),
il ny a pas de retour de lidentifiant du fils au p`ere (deduction de la remarque
precedente).
Pendant le do fork()
En bloquant la creation du processus fils pendant le do fork() nous avons deux
possibilites :
1. soit la creation du processus fils est bloquee juste avant le copy process(), il en
resulte que le processus p`ere se retrouve bloque (meme probl`eme que precedement),
2. soit cela est fait au moment du wake up new task(), le do fork() rend la main au
processus p`ere (qui nest donc pas bloque et peut continuer `a etre execute) : cela
semble etre une bonne idee.
Apr`
es le do fork()
En bloquant la creation du processus fils apr`es le do fork() :
le processus fils est cree et est en cours dexecution, puis il est stoppe. Cette
approche semble etre fonctionnelle mais est assez co
uteuse car le processus fils est
compl`etement reveille, puis sauvegarde, et enfin stoppe.
Conclusion
Il semble que la solution consistant `a bloquer le processus fils dans le do fork() `a
letape du wake up new task() soit la plus judicieuse.
Cest elle que nous implementons.

4.1.3

La capacit
e FORK DELAY

Pour differencier les deux espaces de processus decrits en section 3.3.1, `a savoir les
processus standard et les processus devant etre geres en mode differe, nous utilisons
les capacites (vues en section 3.2.2). Nous mettons en place une nouvelle capacite dans
le syst`eme Kerrighed : la capacite FORK DELAY. Un processus ayant cette capacite
designe un processus dont les fils doivent etre geres en mode differe et font parti de
lensemble des processus differes. Et un processus nayant pas cette capacite designe un
processus dont les fils font parti de lensemble des processus standard. Cest lutilisateur
qui decide de mettre, ou non, la capacite FORK DELAY `a ses processus 1 .
1. Cela se fait par lintermediaire de la commande krg capset.

4.1. MISE EN LISTE DATTENTE DUN PROCESSUS DIFFER

4.1.4

27

Instrumentation du do fork()

`
Le do fork() se deroule normalement jusquau moment du wake up new task(). A
ce moment l`a nous realisons un test : est-ce que le processus en train de faire le fork()
poss`ede la capacite FORK DELAY?
Si oui, cela signifie que tous les processus fils de ce processus sont des processus
differes mis en file dattente. Le wake up new task() ne se fait pas. Il se fera plus
tard, sur decision du syst`eme.
Si non, cela signifie que tous les processus fils doivent etre executes immediatement,
sans tenir compte de la charge de la machine (gestion des processus standard de
Linux).

4.1.5

Instrumentation de la structure task struct

Comme nous lavons vu en section 3.2.1, toutes les informations concernant un processus sont reunies dans une structure associee `a chaque processus : la task struct. Nous
lavons donc instrumentee afin dajouter un champ specifique appele fd flag permettant
`a lordonnanceur de savoir si un processus doit etre gere en mode differe. Ce champ
peut prendre les valeurs suivantes :
NOT A PFD : ce processus ne doit pas etre gere comme un processus differe.
Les processus dans cet etat sont traites dans le syst`eme comme des processus
standard `a Linux sans gestion differee (cest le cas par defaut lors de la creation
dun processus).
PFD NOT ALREADY WU : ce processus est un processus qui a ete cree par un
processus ayant la capacite FORK DELAY et il na jamais ete reveille depuis sa
creation (il se trouve dans la liste des processus differes).
PFD ALREADY WU : ce processus est un processus qui a ete cree par un processus ayant la capacite FORK DELAY et il a dej`
a ete reveille, mais par ordre de
lordonnanceur il a ete arrete et remis dans la file des processus differes.

4.1.6

Gestion de la liste des processus diff


er
es

Nous expliquons dans les paragraphes suivants comment nous gerons une liste des
processus differes globale `a la grappe qui est implementee localement sur chaque nud.
D
eclaration de la liste des processus diff
er
es
Chaque nud contient localement sa propre liste des processus differes. Ainsi, lorsquun processus differe est cree, il est insere dans la file locale du nud sur lequel il a
ete cree. Nous avons implemente cette file dattente des processus differes par une liste
chanee contenant tous les processus locaux `a un nud en attente de reveil.
Un element de cette liste contient :
un pointeur sur la task struct du processus differe p,
un entier clone flags contenant les param`etres necessaires au wake up new task(),

28

CHAPITRE 4. MISE EN UVRE DANS KERRIGHED

un champ fd status contenant letat du processus. Ce champ a ete cree dans le


but dune future interoperabilite entre la sauvegarde de points de reprise dapplication et la gestion des processus differes. Pour plus dinformation, nous invitons
le lecteur `a se reporter `a lannexe A.1.
De plus, nous avons defini une variable globale nb process delayed contenant le
nombre de processus en attente dans la file locale dun nud.
Les diff
erents
el
ements de la liste des processus diff
er
es
Les processus dans la liste des processus differes peuvent etre :
des processus qui nont jamais ete reveilles : ils sont places en fin de liste (premier
arrive, permier servi),
des processus ayant dej`a ete reveilles, mais ayant ete arretes par ordre de lordonnanceur : ils sont places en debut de liste (dernier arrive, premier servi).

4.2

Gestion du r
eveil des processus

Concernant la gestion du reveil des processus differes au sein de la grappe, differentes


possibilites sont `a envisager :
Approche centralisee : reveil `a linitiative dun nud fixe. Un nud central regroupe toutes les informations concernant letat de chaque nud, letat de leur
file dattente et distribue lui meme les taches sur les differents nuds.
Approche semi-centralisee : reveil `a linitiative dun nud sur un anneau `a jeton.
Nous definissons un anneau compose de nuds ayant du travail en attente. Sur
cet anneau, nous creons un jeton. Le nud qui a le jeton recherche sur la grappe
un nud disponible afin de lui attribuer du travail et passe le jeton `a un autre
nud de la grappe.
Approche distribuee : reveil `a linitiative de chaque nud. Chaque nud scrute sa
propre charge et previent les autres nuds lorsquil na rien `a faire pour que ces
derniers reveillent des processus differes.
Nous representons ces differentes strategies sur la figure 4.1.

4.2.1

Pr
esentation des diff
erentes strat
egies possibles

R
eveil `
a linitiative dun nud fixe
Un nud centralise toutes les demandes de reveil de processus. Il dispose dune
vision de chaque file des processus differes de tous les nuds de la grappe. Il scrute la
charge de la grappe. Il decide alors o`
u et quand un processus doit se reveiller.
R
eveil `
a linitiative dun nud sur un anneau `
a jeton
Chaque nud poss`ede sa propre file. On cree un anneau parmi tous les nuds disposant de travaux dans leur file. Un jeton circule sur cet anneau. Le jeton nest consomme


4.2. GESTION DU REVEIL
DES PROCESSUS

29

Fig. 4.1 Representation graphique des differentes approches presentees


par un participant de lanneau, quapr`es avoir execute de sa file un processus differe.
Lorsque le jeton est consomme, le participant le passe `a son voisin 2 . Pour consommer
le jeton, le participant scrute la charge de lensemble des nuds de la grappe. Si elle est
jugee suffisament faible par le participant, alors il consomme son jeton. Sinon, il garde
le jeton jusqu`a ce que la charge dun nud de la grappe devienne suffisamment faible
pour quil puisse le consommer. Le jeton peut donc rester sur un nud aussi longtemps
que la grappe est chargee.

R
eveil `
a linitiative de chaque nud de la grappe
Chaque nud poss`ede sa propre file des processus differes et scrute sa charge. De
plus chaque nud poss`ede une table des etats permettant de savoir `a tout moment letat
des autres nuds. Cet etat peut-etre : nud actif ou nud inactif. Si un nud juge quil
est inactif et que sa file des processus differes est vide, alors il envoie un message `a son
2. Dans un second temps, lorsque Kerrighed surpportera `
a chaud lajout et le retrait de nuds, il
faudra prevoir des mecanismes de gestion du jeton plus elabores permettant de ne pas perdre le jeton.

30

CHAPITRE 4. MISE EN UVRE DANS KERRIGHED

voisin 3 pour lui faire part de son manque dactivite afin que celui-ci mette `a jour sa
table des etats. Si son voisin dispose de processus `a reveiller, alors il en reveille un quil
confie au nud signalant son inactivite et ne retransmet pas le message. Sinon, le voisin
fait passer le message `a son voisin egalement. Le fonctionnement est le meme dans le cas
o`
u un nud juge quil est actif, il passe alors un message `a son voisin pour que celui-ci
mette `a jour sa table des etats. Puis, le voisin passera ce message `a son voisin et ainsi
de suite pour que toute la grappe puisse se mettre `a jour. Si un nud recoit un message
envoye par lui-meme (cest-`a-dire que le message a fait le tour de la grappe), alors il le
detruit.
Conclusion
Nous laissons de cote le reveil `a linitiative dun nud fixe. En effet, travaillant au
sein dun syst`eme distribue, il ne semble pas judicieux de mettre en place une architecture centralisee de gestion de processus. Concernant les deux autres methodes, une
difference notable est que dans la version du reveil des processus differes `a linitiative
dun nud appartenant `a un anneau avec jeton, un seul nud (celui qui a le jeton) peut
executer un processus differe de sa file des processus differes alors que dans la version
du reveil `a linitiative de chaque nud, il est possible que plusieurs nuds puissent
simultanement executer des processus differes en attente. Dans une premi`ere approche
nous developpons le reveil `a linitiative dun nud dans un anneau avec jeton, puis le
reveil `a linitiative de chaque nud (distribue) (voir annexe A.2 pour le passage de lun `a
lautre). Nous les comparons pour montrer quune approche compl`etement distribuee est
plus performante quune approche semi-centralisee. De plus, cela nous permet de definir
une interface de programmation commune `a ces deux politiques de gestion (API ).

4.2.2

D
efinition de linterface (API )

Comme nous lavons vu, il peut y avoir plusieurs politiques dordonnancement des
processus differes. Cependant, les actions `a realiser vis-`a-vis dun processus sont toujours
les memes :
obtenir la charge dun nud,
reveiller un processus,
envoyer un message `a un autre nud.
Obtenir la charge dun nud : int get load of node(int node id)
Cette fonction retourne la charge du nud node id. Cette charge est en fait la charge
virtuelle additionnee `a la charge reelle (voir le chapitre 4.4 pour plus dinformations sur
les principes des charges reelle et virtuelle ainsi que sur les principes de fonctionnement
de la sonde MOSIX) du nud node id.
3. Definition du voisin dun nud : le nud didentifiant n a pour voisin le nud didentifiant n + 1
modulo le nombre de nuds dans la grappe.


4.2. GESTION DU REVEIL
DES PROCESSUS

31

R
eveiller un processus : int wake up pfd(int node to fork)
Cette fonction reveille un processus de la liste des processus differes sur le nud
node to fork. Le mecanisme est le suivant :
reveiller un processus,
le deplacer sur le nud disponible.
Le r
eveil des processus diff
er
es. La recherche des processus disponibles seffectue
dans la liste des processus parmi ceux qui sont non bloques (fd status vu en section
4.1.6). Le reveil dun processus peut seffectuer de deux mani`eres selon letat consigne
dans le champ fd flag (vu en section 4.1.5) :
soit le processus na jamais ete reveille (etat == PFD NOT ALREADY WU, dans
ce cas il convient de faire un wake up new task() pour son premier reveil.
soit le processus a dej`a ete execute mais a ete stoppe (etat == PFD ALREADY WU ),
dans ce cas il faut envoyer au processus un signal de reprise.
Une fois que le processus est reveille, alors, il faut lenlever de la file des processus
differes, et mettre `a jour la charge du syst`eme (voir la section 4.4).
Envoyer un message : void send a message to the local node(int msg, int type)
Cette fonction a pour effet denvoyer un message msg de type type synchrone au
nud local.
Envoyer un message : void send a message to the next node(int msg, int type)
Cette fonction a pour effet denvoyer un message msg de type type synchrone au
nud voisin (nud dont lidentif iant est identif iant + 1 modulo le nombre de nuds
dans la grappe).
Ces deux derni`eres fonctions utilisent les mecanismes denvoi de message offerts par
Kerrighed. Kerrighed offre des mecanismes permettant denvoyer des messages dun
nud `a un autre, de mani`ere synchrone ou asynchrone. Ces mecanismes se nomment les
services RPC (Remote Procedure Call ) [14, 19, 23] et nous les utilisons pour implementer
nos politiques de gestion du reveil des processus differes.
Le principe est le suivant : un processus leger du noyau (( ecoute )) en permanence
sur un canal predefini. Lorsquil recoit des messages, il les traite.

4.2.3

R
eveil `
a linitiative dun nud dans un anneau `
a jeton

Dans une premi`ere approche, nous formulons lhypoth`ese que le jeton ne peut se
perdre (il ne peut y avoir de retrait de nuds `a chaud) et qu`a tout instant lanneau
comporte au plus un jeton.

32

CHAPITRE 4. MISE EN UVRE DANS KERRIGHED

Les diff
erents types de message
Pour la gestion des processus differes, nous avons cree un canal FD CHAN qui est
utilise pour tous les messages echanges entre les differents nuds. De plus, nous avons
defini deux types de message :
ADMIN : messages dadministration de lanneau. Ce type de message est utilise
lorsquun nud veut sintegrer `a lanneau car il a des processus differes en attente,
ou bien quun nud faisant parti de lanneau veut le quitter.
JETON : messages de circulation du jeton. Nous symbolisons le jeton par un message. Lorsquun nud recoit un message de type JETON, il recoit donc le jeton.
Nous disposons donc de deux processus du noyau servant `a traiter ces messages :
handle admin : g`ere les messages dadministration de lanneau,
handle jeton : g`ere la reception du jeton.
Pour plus dinformation sur les details dimplementation, le lecteur peut se reporter
`a lannexe A.3.
Le processus d
election
En mettant de cote la possibilite que le jeton puisse etre perdu, il existe un cas o`
u il
peut ne plus avoir de jeton dans lanneau : cest le cas degenere o`
u lanneau ne contient
aucun nud (typiquement lorsquaucun nud na de processus differes en attente).
Lorsquun nud recoit du travail (cest-`a-dire quil a la creation dau moins un processus
differe) il doit donc creer un jeton pour pouvoir le consommer. Or il se pourrait que
plusieurs nuds veuillent creer un jeton en meme temps (exemple : creation simultanee
de processus differes sur des nuds distincts). Ainsi, afin de sassurer quil ny a au plus
quun jeton sur lanneau, nous procedons `a une election : le nud possedant le plus fort
kerrighed node id a le droit de creer le jeton (les autres nuds doivent attendre que le
jeton leur parvienne avant de pouvoir executer des processus differes en attente).
Algorithme
La fonction handle jeton() est appelee lorsque le nud recoit le jeton. Celle-ci fait
appel `a la fonction fd management() qui contient le corps de notre algorithme decrit ciapr`es. En effet, la fonction fd management() est appelee lorsque le nud recoit le jeton
ou lorsquun processus differe est cree et mis en file dattente des processus differes du
nud. Cette fonction essaye de consommer le jeton si la file dattente des processus
differes du nud nest pas vide (cest-`a-dire quil y a du travail en attente) et passe le
jeton au nud voisin.
Pseudo-algorithme :
SI du_travail_en_attente() == VRAI ALORS
//travail en attente
SI jeton_dans_anneau() == FAUX ALORS
demande_creation_jeton();


4.2. GESTION DU REVEIL
DES PROCESSUS

33

SINON
//est-ce que le noeud possede le jeton ?
SI presence_jeton() == VRAI ALORS
consommer_jeton(); //reveiller un processus et transmettre le jeton
SINON
//attendre que le jeton arrive !
rien_a_faire();
FINSI
FINSI
FINSI

4.2.4

R
eveil `
a linitiative de chaque nud

Dans la strategie du reveil `a linitiative de chaque nud, chacun scrute uniquement


sa charge et previent les autres nuds sil subit un changement detat. Nous avons defini
deux etats : actif et inactif. Un nud inactif va donc prevenir les autres nuds de son
changement detat sil devient actif et reciproquement pour un nud actif qui devient
inactif. Tous les nuds poss`edent une table des etats contenant letat des autres nuds
qui est mise `a jour au fur et `a mesure. Le nud didentifiant n a pour voisin le nuds
didentifiant n + 1 modulo le nombre de nuds dans la grappe.
Le principe est le suivant :
un processus du noyau (fd v2 manager thread()) scrute reguli`erement 4 la charge
` chaque changement detat (le nud devient actif ou inactif)
du syst`eme (local). A
ce processus envoie un message `a son voisin lui indiquant son nouvel etat (actif
ou inactif). Le voisin met `a jour sa table des etats et se charge, selon les cas que
nous voyons par la suite, de retransmettre le message `a son propre voisin ou non.
deux autres processus du noyau (handle ready() et handle not ready()) recoivent
ces messages de changement detat de la part des autres nuds et mettent `a jour
leur table.
`
A linitialisation nous considerons tous les nuds inactifs. Si un nud a son etat
qui change, alors il senvoie un message pour mettre `a jour sa table des etats et relancer
lalgorithme afin de voir sil nest pas possible dexecuter un processus differe de la file
dattente locale. Sil cela est possible, alors il le fait. Sinon, il envoie un message `a son
voisin pour quil se mette `a jour. Le voisin met `a jour sa table des etats et regarde sil
na pas de processus en attente `a reveiller sur le nud `a lorigine du message. Si oui, il
le fait, si non, il passe le message egalement `a son voisin et ainsi de suite.
Algorithme : Lorsquun nud change detat, il senvoie un message dinformation
(pour se mettre `a jour) et envoie un message `a son voisin (pour que toute la grappe se
mette `a jour).
Lorsquun nud recoit un message de mise `a jour (celui-ci pouvant provenir de luimeme ou bien dun autre nud) et que ce message na pas fait une boucle, alors il met
4. Cette periodicite peut-etre definie sur un nud dans /proc/sys/fork delay.

34

CHAPITRE 4. MISE EN UVRE DANS KERRIGHED

a` jour sa table des etats. Selon les cas, il peut decider de lancer un processus en attente
ou bien il passe le message au nud suivant.
Le processus g
erant la charge : int fd v2 manager thread()
Le pseudo-algorithme est le suivant :
BOUCLE_SUR :
load = charge_du_noeud_local();
SI load == idle ET last_load == idle ALORS
SI du_travail_en_attente ALORS
executer_travail_en_attente();
SINON
ne_rien_faire();
FINSI
SI load == idle ET last_load == not_idle ALORS
SI du_travail_en_attente ALORS
executer_travail_en_attente();
SINON
propager_changement_etat();
FINSI
SI load == not_idle ET last_load == not_idle ALORS
SI du_travail_en_attente ALORS
SI rechercher_un_noeud_disponible() == vrai ALORS
executer_travail_en_attente_sur_noeud_disponible();
FINSI
FINSI
FINSI
SI load == not_idle ET last_load == idle ALORS
propager_changement_etat();
SI du_travail_en_attente ALORS
SI rechercher_un_noeud_disponible() == vrai ALORS
executer_travail_en_attente_sur_noeud_disponible();
FINSI
FINSI
FINSI
FINBOUCLE_SUR
Les processus g
erant la mise `
a jour de l
etat des nuds
Nous utilisons deux processus du noyau afin de gerer letat des nuds : un pour
traiter les messages de type READY concernant letat inactif et lautre pour traiter les
messages de type NOT READY concernant letat actif.


4.2. GESTION DU REVEIL
DES PROCESSUS

35

handle ready(); Tout message recu par cette fonction contient comme valeur lidentifiant du nud dont letat est disponible (IDLE ).
Lorsquun message est recu, alors, le nud recevant le message verifie que le message
nest pas en train de boucler. Si tel est le cas, il detruit le message. Puis, sil dispose de
travaux en attente, alors il reveille un processus sur le nud se declarant disponible et
detruit le message. Sinon, il met `a jour sa table des etats et transmet le message `a son
voisin.

Algorithme :
entier msg = reception_message();
//msg contient lid dun noeud dont letat est passe a IDLE
SI (emetteur(msg) != self ET valeur(msg) == self) ALORS
//le message a fait une boucle
retourner(-1);
FINSI;
SI (du_travail_en_attente() == TRUE) ALORS
//je dispose de travail en attente, et le noeud valeur(msg) est disponible :
wake_up_pfd(valeur(msg)); //je reveille un processus differe
retourner(1);
FINSI;
mettre_a_jour_la_table_des_etats(msg);
transmettre_le_message_au_voisin(msg);

handle not ready(); Tout message recu contient comme valeur lidentifiant du nud
dont letat est indisponible (NOT IDLE ). Lorsquun message est recu sur ce canal, alors
le nud recevant le message verifie que le message nest pas en train de boucler. Si tel
est le cas, il detruit le message. Sinon, il met `a jour sa table et fait passer le message `a
son voisin.

Algorithme :
entier msg = reception_message();
//msg contient lid dun noeud dont letat est passe a NOT_IDLE
SI (emetteur(msg) != self ET valeur(msg) == self) ALORS
//le message a fait une boucle
retourner(-1);
FINSI;
mettre_a_jour_la_table_des_etats(msg);
transmettre_le_message_au_voisin(msg);

36

CHAPITRE 4. MISE EN UVRE DANS KERRIGHED

4.2.5

Comparaison qualitative des deux strat


egies impl
ement
ees

Intuitivement, nous pouvons penser que la strategie du reveil `a linitiative de chaque


nud est plus performante que celle `a linitiative dun nud appartenant `a un anneau
avec jeton. En effet, dans la solution compl`etement distribuee, il est tout `a fait possible
que sur une meme grappe, deux nuds disponibles puissent simultanement recevoir du
travail de la part dautres nuds. Cela nest pas possible dans la solution `a linitiative
dun nud appartenant `a un anneau avec jeton, le jeton centralisant toutes les actions.
De plus, dans cette derni`ere solution, chaque nud scrute la charge de tous les autres
nuds par lintermediaire de la fonction get dynamic node info(node id); 5 . Cette fonction fait appel `a des mecanismes entranant une communication reseau importante alors
que, par opposition, la solution distribuee ne fait que scruter la charge locale du nud
(et donc, il ny a pas dacc`es au reseau).
Enfin, prenons le cas dune grappe chargee. Avec la version `a linitiative dun nud
appartenant `a un anneau avec jeton, le nud possedant le jeton, va continuellement
chercher un nud libre pour essayer de consommer son jeton au plus vite. Cela entrane
egalement une petite surcharge inutile. Alors quavec la version du reveil `a linitiative
de chaque nud, que la grappe soit chargee ou non, comme chaque nud ne fait que
scruter sa propre charge et ne previent les autres nuds que lorsque celle-ci varie significativement, le gain en communication reseau est important.
Nous conjecturons donc que la version `a linitiative de chaque nud est plus performante que celle `a linitiative dun nud appartenant `a un anneau avec jeton.

4.3
4.3.1

Ordonnancement des processus g


er
es en mode diff
er
e
Pr
eambule

Un processus differe occupe des ressources qui peuvent etre `a tout moment requisitionnees par dautres processus non differes. Pour que la charge de la grappe naugmente
pas de mani`ere trop importante, il est necessaire de stopper les processus differes en
cours dexecution afin quils liberent les ressources quils utilisent si ces ressources sont
requisitionnees.
Pour decider de larret dun processus, nous avons trois aspects `a etudier :
comment detecter que nous devons arreter un processus differe,
quel processus est `a arreter,
et comment larreter.
Pour ce faire, nous allons etudier lordonnanceur de Kerrighed et principalement la
fonction migration manager thread() ainsi que les procedes darret dun processus.

4.3.2

Ordonnanceur de Kerrighed : la fonction migration manager thread()

La fonction de lordonnanceur de Kerrighed migration manager thread() est appelee


`a chaque fois que la charge sur un nud devient trop importante. Son fonctionnement
5. Fonction interne `
a Kerrighed.

ES
EN MODE DIFFER
E

4.3. ORDONNANCEMENT DES PROCESSUS GER

37

est le suivant :
Boucle sur :
est reveille lorsque la charge du nud est trop importante : sleep on task (current);
cherche un processus `a migrer : tsk = find a process to migrate ();
cherche un nud pour effectuer la migration :
nodeid = find a node according to the scheduling policy(tsk);
realise la migration : do migrate process(tsk, nodeid);

4.3.3

Quand arr
eter un processus diff
er
e

La fonction migration manager thread() est reveillee `a chaque fois que la charge du
nud est trop importante. Cest donc `a ce moment l`a que doit intervenir la gestion des
processus differes. Nous decidons darreter un processus differe si la charge du nud
courant est trop importante, et quil ny a pas de processus ayant la capacite de migration en cours dexecution ou quil ny a pas dautres nuds disponibles. Au final,
nous decidons darreter un processus si la condition suivante est respectee : (la charge
du nud local est trop importante) ET (il ny a pas de processus pouvant etre deplace
OU il ny a pas de nud disponible dans la grappe).

4.3.4

D
etection dun processus `
a arr
eter

Pour arreter un processus differe, nous parcourons la file des processus eligibles (par
appel `a la fonction find a process delayed running()) et nous recherchons les processus
dont letat (fd flag) est marque comme etant un processus differe.

4.3.5

Arr
et dun processus diff
er
e

Pour arreter un processus nous disposons de plusieurs methodes. En espace utilisateur, il est possible denvoyer un signal (voir section 3.2.1) au processus. Dans une
premi`ere approche, nous nous interessons plus particuli`erement aux signaux :
SIGSTOP,
SIGCONT.
Ces signaux permettent de stopper (SIGSTOP ) un processus et de le reprendre
(SIGCONT ) `a lendroit o`
u il sest arrete.
Probl`
eme : ces signaux sont recus par un processus lorsquun ev`enement exterieur
intervient (exemple, lutilisateur ou lordonnanceur envoie explicitement un signal) et a
pour effet dexecuter un code specifique au processus. Par defaut, un signal SIGSTOP
met le processus concerne dans letat TASK STOP. Le processus qui recoit un SIGSTOP
a (( conscience )) quil recoit un signal, et a (( conscience )) quil sarrete 6 . Dans le cadre du
developpement dun syst`eme transparent `a lutilisation, nous remarquons que le procede
6. La commande ps permet de voir tous les processus stoppes

38

CHAPITRE 4. MISE EN UVRE DANS KERRIGHED

precedemment cite ne convient pas. Le processus doit pouvoir etre arrete, redemarre,
deplace en toute transparence.
Il nous a donc fallu trouver une autre methode : mettre les processus differes dans
letat UNINTERRUPTIBLE (etat qui bloque lexecution dun processus en lenlevant
de la file des eligibles).
Les op
erations de gestion des processus
Comme vu precedemment, Kerrighed g`ere la migration de processus, la sauvegarde
de points de reprise. Pour ce faire, il existe dans la task struct un champ aragorn action
permettant de positionner laction `a realiser avec le processus lors de lenvoi dun signal
Kerrighed (vu en section 3.2.2). Par exemple, si lon realise :
tsk->krg_task->aragorn->aragorn_action = TO_MIGRATE;
et que lon envoie un signal Kerrighed sur ce processus
send_kerrighed_signal(tsk);
alors la prochaine action realisee sur le processus (quand lordonnanceur le decide)
est une migration. Nous procedons de la meme mani`ere en definissant une operation
FORK DELAY STOP PROCESS. Ainsi, lorsque lordonnanceur decide de stopper un
processus differe en cours dexecution, il lui met comme operation `a realiser :
tsk->krg_task->aragorn->aragorn_action = FORK_DELAY_STOP_PROCESS;
et lui envoie un signal Kerrighed. Cela a pour effet de mettre le processus en etat
UNITERRUPTIBLE, de lenlever de la file des processus eligibles et de le mettre dans
la liste des processus differes (en debut de liste).

4.3.6

Synth`
ese

` partir de la description faite en 4.3.2, nous voyons que lorsque la fonction miA
gration manager thread() se reveille cest quelle cherche `a effectuer une migration pour
equilibrer la charge de la grappe. Or, il est possible quelle ny arrive pas dans deux cas :
si elle ne trouve pas de processus `a migrer,
si elle ne trouve pas de nud pouvant recevoir le processus `a migrer.
Cest l`a que doit intervenir la gestion des processus differes.
Voici le principe de notre algorithme :
verifier la charge courante du nud :
si elle est faible : ne rien faire.
sinon, si des processus differes sont en cours dexecution, alors il faut en
stopper.
chercher un processus differe en cours dexecution `a stopper :
tsk = find a process delayed running();
mettre laction FORK DELAY STOP PROCESS dans aragorn action,
lui envoyer le signal darret : send kerrighed signal(tsk);
le rajouter en debut de la liste des processus differes dans un etat non-bloque.

4.4. LA CHARGE VIRTUELLE : VLOAD

39

Ainsi le processus est stoppe et est mis en debut de liste des processus differes, pret
`a etre reveille de nouveau.

4.4

La charge virtuelle : vload

Lorsquun processus est en cours dexecution, il consomme de la ressource processeur.


De ce fait, la charge du nud ainsi que celle de la grappe augmente. Kerrighed utilise
la sonde MOSIX [28, 19, 26] afin de donner une evaluation de la charge du processeur.
Cette charge est calculee (moyenne ponderee) en fonction de la charge passee et de la
charge instantanee selon la formule :
charge(t) = ponderation(charge(t 1), charge instantan
ee)
Cependant, cette charge peut mettre jusqu`a deux secondes avant detre actualisee.
Dans le cas de processus longs (temps dexecution superieur `a 10 secondes) lances en
differe, il est possible de se retrouver dans une situation selon laquelle, un processus
est execute et retire de la file des processus differes. Puis, alors que la charge nest
pas encore mise `a jour, un autre processus est execute et retire de la file des processus
differes, puis un troisi`eme, jusquau moment o`
u la charge se met effectivement `a jour.
Ce nest qu`a partir de l`a que les processus differes encore dans la file sont bloques
(en attendant que les ressources se lib`erent). Mais, certains processus differes ont dej`
a
ete lances. Certes, ils vont etre stoppes par la suite par le mecanisme vu dans le paragraphe 4.3. Cependant, il est possible dans certaines configurations que des centaines
de processus differes sexecutent avant que le syst`eme ne se rende compte quil faut les
stopper. Cela entrane une surcharge inutile ainsi que des phenom`enes dinstabilite du
syst`eme que lon peut eviter en introduisant le mecanisme de charge virtuelle.

4.4.1

Le principe de la charge virtuelle (vload )

Notre objectif est dempecher le reveil successif de processus differes, mais egalement
de reduire le temps de mise `a jour de la sonde, lorsquun processus differe se termine
(et que donc, potentiellement, un autre processus differe peut etre reveille).
Pour realiser cela, nous avons mis en place une variable globale vload qui represente
la charge virtuelle. La somme de la charge virtuelle et de la charge reelle (celle donnee
par la sonde MOSIX) est la charge instantanee qui est utilisee par notre ordonnanceur :
charge virtuelle(t) = charge(t) + vload
Ainsi, lorsquun processus differe est reveille, la charge virtuelle est augmentee dune

unite pendant une duree d. Egalement,


lorsquun processus differe se termine, la charge
virtuelle est diminuee dune unite pendant cette meme duree d.
Cette duree d depend du temps de mise `a jour de la sonde. Dans notre cas, la sonde
met dans le pire cas deux `a trois secondes pour se mettre `a jour. Nous avons donc decide
de fixer cette duree d `a trois secondes.

40

4.4.2

CHAPITRE 4. MISE EN UVRE DANS KERRIGHED

Instrumentation du do exit()

Lappel syst`eme do exit() nettoie de la memoire les differentes structures allouees


par le processus.
Tout comme pour le do fork(), nous avons d
u instrumenter cette fonction afin quelle
envoie un message demandant la diminution de la charge virtuelle dune unite lors de
la fin dun processus differe.

41

Chapitre 5

Evaluation
Nous allons maintenant evaluer le syst`eme de gestion differe des processus. Dans
une premi`ere partie nous decrivons le plan des tests suivis. Nous comparons ensuite les
deux politiques de reveil des processus mis en uvre dans la section 4.2. Enfin, nous
evaluons les performances de la gestion des processus differes sur grappe sans migration
(les processus sont crees sur un nud et y restent jusqu`a leurs terminaisons). et avec
migration (les processus sont crees sur un nud et peuvent se terminer sur un autre
nud).

5.1
5.1.1

Description du plan de tests


Le mat
eriel utilis
e

Nous disposons dune grappe de quatre PC. Ces PC sont equipes de processeurs
cadences `a 1GHz, de 512Mo de memoire vive, 460Mo de partition dechange (soit un

total de 972Mo de memoire) et sont lies entre eux par un reseau Ethernet
100Mb.
Les buts de nos tests sont les suivants :
valider la conjecture faite en 4.2.5 (qui suppose que la solution distribuee est plus
performante que celle semi-centralisee),
montrer quil est plus efficace davoir un syst`eme non charge avec une gestion
regulee des travaux plutot quun syst`eme charge cherchant `a effectuer tous les
calculs en meme temps,
montrer quil est possible dorganiser lexecution des taches pour que les utilisateurs, entre eux, se penalisent le moins possible.

5.1.2

Notre application de simulation

Pour realiser ces tests nous avons concu une application (en langage C) qui simule
la soumission de travaux sur la grappe. Cette application permet donc de creer simultanement plusieurs processus. Ces processus simulent une application de calcul qui
ecrit en boucle dans la memoire de lordinateur. Il est possible de parametrer la duree
des processus crees. Cela nous permet de simuler des processus courts (dont le temps


CHAPITRE 5. EVALUATION

42

dexecution est inferieur `a deux secondes) ainsi que des processus longs (dont le temps
dexecution est superieur `a cinq secondes). Le pseudo-algorithme du programme est
disponible en annexe A.4.
Dans un premier temps, nous etudions les performances du reveil des processus
differes `a linitiative de chaque nud par rapport `a celles `a linitiative dun nud appartenant `a un anneau avec jeton. Puis, nous realisons les tests suivants avec la version
la plus performante du reveil des processus differes. Tout dabord nous testons la gestion
des processus differes sur notre grappe sans utiliser la capacite de migration de Kerrighed. Cela nous permet dobtenir des performances brutes de notre syst`eme sur un seul
nud. Puis, nous effectuons dautres tests avec cette fois-ci la capacite de migration.
Enfin, nous etudions la gestion des processus differes avec lapplication MrBayes dans
le cas dune sequence dexecution particuli`ere.

5.2

Etude
comparative

Nous avons decrit en section 4.2.3 et 4.2.4 deux implementations differentes dune
politique de gestion des processus differes. Nous allons les comparer.
Dans la politique du reveil `a linitiative dun nud appartenant `a un anneau avec
jeton, le nud qui poss`ede le jeton scrute la charge de toute la grappe et decide alors
o`
u et quand il execute un processus de sa file de processus differes.
Dans la politique du reveil `a linitiative de chaque nud, chaque nud ne scrute
que sa propre charge et envoie des messages indiquant un changement detat (actif ou
inactif) aux autres nuds de la grappe.

5.2.1

Etude
th
eorique

Dans le cas dune gestion optimum des ressources, nous devons obtenir avec la gestion des processus differes, des resultats de mani`ere reguli`ere (un processus ne pouvant
sexecuter que si les autres processus qui etaient devant lui dans la file dattente des
processus differes ont ete executes). De plus le dernier resultat obtenu doit letre au
plus tard dans le meme temps que le temps de reference de Kerrighed sans gestion de
processus differes.

5.2.2

Les r
esultats

Nous avons execute simultanement 20 processus ecrivant chacun en memoire 20Mo


de donnees (en utilisant lapplication decrite en section 5.1.2). Nous obtenons les resultats
de la figure 5.1.
En abscisse sont representes les 20 processus. En ordonnee est represente le temps de
fin dexecution des processus. La courbe FD V2 designe le reveil `a linitiative de chaque
nud alors que celle FD V1 designe le reveil `a linitiative dun nud appartenant `a un
anneau avec jeton. La courbe Kerrighed sans FD designe lexecution de lapplication de
simulation avec les meme param`etres sans gestion des processus differes. Cest elle qui


DE MIGRATION
5.3. ETUDE
DES PERFORMANCES SANS LA CAPACITE

43

va nous servir de reference afin de comparer les deux versions de gestion du reveil des
processus differes.

Fig. 5.1 Excecution de 20 processus occupant chacun 20Mo de memoire

5.2.3

Conclusion

On remarque que systematiquement, la solution FD V2 donne des resultats avant


la solution FD V1. Au final, dans cette experience, on constate que la solution FD
V2 est de 6% plus performante que celle FD V1. Le dernier resultat (processus 19
sur le graphe) avec la solution FD V2 est obtenu en meme temps que Kerrighed sans
utilisation de gestion des processus differes. De plus, la gestion des processus differes
donne des resultats dapplication reguli`erement au fur et `a mesure. On en arrive donc `a
une gestion optimum des ressources comme nous venons de le decrire dans le paragraphe
5.2.1.
Nous pouvons reiterer cette experience en faisant varier le nombre de processus (nous
avons fait nos tests en faisant varier le nombre de processus simultanes de 10 `a 50) et
systematiquement la solution du reveil `a linitiative de chaque nud est la plus efficace.

5.3

Etude
des performances sans la capacit
e de migration

Dans cette serie de tests, nous nutilisons pas la capacite de migration. Nous allons
comparer le comportement de notre application de simulation (decrit en section 5.1)
avec et sans la gestion des processus differes. Nous lancons les processus differes ou non
`a partir dun seul nud de la grappe. Concr`etement, cela correspond au cas o`
u, tous les
nuds sauf un sont charges et les utilisateurs lancent leurs processus depuis le nud


CHAPITRE 5. EVALUATION

44

non charge. Ainsi, ce nud va executer ces processus sans pouvoir les migrer (car pas
de ressources disponibles ailleurs).

5.3.1

Processus longs

Nous realisons deux series dexperience, la premi`ere en chargeant le syst`eme moyennement et la seconde en chargeant le syst`eme fortement.

Syst`
eme `
a charge moyenne
La figure 5.2 presente les resultats dexecution de notre application avec 40 processus executes simultanement. Ces 40 processus occupent chacun 20Mo de memoire, ce
qui correspond `a un total de 800Mo de memoire. Or le syst`eme est equipe de 972Mo
de memoire. Donc, `a priori, il ny a aucun probl`eme dexecution simultanee de ces processus. En abscisse nous pouvons voir les 40 processus fils lances, et en ordonnee, nous
pouvons voir le temps dexecution de chacun dentre eux. La ligne ref correspond au
temps dexecution dun processus seul multiplie par 40.

Fig. 5.2 Execution de 40 processus avec et sans gestion differee


Dune mani`ere generale, nous remarquons que lorganisation des taches dans le cas
de la gestion des processus differes permet `a un maximum dutilisateurs dobtenir leurs
resultats rapidement sans engendrer de surco
ut pour lutilisateur du processus 39 par
rapport `a un syst`eme Linux standard qui de plus fournit les resultats dans un ordre
totalement aleatoire et pour certains bien au-dessus du temps de reference theorique.


DE MIGRATION
5.3. ETUDE
DES PERFORMANCES SANS LA CAPACITE

45

Syst`
eme tr`
es charg
e
Nous executons maintenant 50 processus occupant chacun 20Mo de memoire. Dans
ce cas, le syst`eme Linux standard seffondre et est oblige de tuer certains processus en
cours dexecution. Cela sexplique par le fait que la memoire utilisee par les differents
processus (1000Mo) est superieure `a celle disponible dans le syst`eme (972Mo).
La figure 5.3 presente les resultats cette experience. Pour une meilleure lisibilite
nous avons mis les ordonnees en echelle logarithmique. Sur ce graphe, nous obtenons
les resultats 13 et 18 dans des temps (( normaux )). Nous nobtenons pas de resultats
pour les processus 0 et 1, et enfin, les autres resultats sont obtenus avec des temps bien
au-dessus de la reference Linux standard ce qui nest pas le cas pour la meme execution
avec gestion des processus differes.

Fig. 5.3 Surcharge du syst`eme linux standard


En conclusion, lutilisation dun syst`eme Linux standard tr`es charge nam`ene pas `a de
bonnes performances et `a une bonne gestion des ressources. Plus la charge du syst`eme
augmente, et plus notre syst`eme devient efficace en comparaison avec la gestion des
processus standard.

5.3.2

Processus courts

Lors de lexecution de processus courts, nous constatons que le syst`eme perd en


performance (voir la figure 5.4). En effet, lorsque les processus sont tr`es courts et tr`es
nombreux, la sonde devient imprecise et le mecanisme de charge virtuelle egalement.
Pour y remedier une solution quil pourrait etre interessant de travailler, serait de
reveiller automatiquement un processus differe en attente lors de la fin de lexecution
dun autre processus differe, en instrumentant le do exit() dune mani`ere adequate. Cela

46

CHAPITRE 5. EVALUATION

Fig. 5.4 Phenom`ene descalier


eviterait alors le temps dattente necessaire au syst`eme avant de reveiller un nouveau
processus differe. Ce qui permetrait donc de gagner en performance.
Cas du make -j. Le probl`eme que nous venons de decrire concernant la gestion
des processus courts est tout de meme `a relativiser par le fait quil existe une classe
dapplications creant enormement de processus de tr`es courte duree. Sur un syst`eme
Linux standard, cela a pour effet de faire ecrouler les performances du syst`eme. Par
exemple, la compilation dun noyau Linux qui peut se faire par la commande make
-j va creer autant de processus quil peut, avant que le syst`eme ne seffondre. Cette
compilation ne peut donc se faire ainsi. Avec lutilisation de la gestion des processus
differes, tous les processus que le syst`eme ne peut gerer sont mis en liste dattente, et
lexecution se deroule au fur et `a mesure ! Nous avons meme execute plusieurs make -j
simultanement sur une meme grappe et avons obtenu des resultats quun Linux standard
ne peut donner.

5.4

Etude
des performances avec la capacit
e de migration

Nous utilisons maintenant la capacite de migration de Kerrighed. Nous executons 4


processus identiques geres en mode differe sur 4 nuds lances `a partir dun meme nud
initial. Les processus que nous lancons occupent chacun 20Mo de donnees en memoire.
R
esultats. Nous prenons comme reference lexecution de ce processus sur un syst`eme
Linux standard (processus lances simultanement chacun sur un nud). La figure 5.5
montre une comparaison de lexecution de ces processus avec ou sans gestion des processus differes. On constate que la gestion differee apporte un gain significatif dans

`
5.5. SYNTHESE

47

lexecution des processus. Avec elle, nous atteignons pratiquement la valeur de reference
qui est celle de lexecution dun processus sur un syst`eme Linux standard. Cela est d
u au
fait que lordonnanceur des processus differes est tr`es reactif grace `a limplementation de
la charge virtuelle (le temps de decision avant deffectuer une migration dun processus
differe est beaucoup plus court que celui dun processus standard).

Fig. 5.5 4 processus identiques executes simultanement sur une grappe de 4 nuds

5.5

Synth`
ese

Des tests effectues, nous pouvons conclure que :


la politique de reveil des processus `a linitiative de chaque nud de la grappe est
plus performante que celle `a linitiative dun nud appartenant `a un anneau avec
jeton,
il est plus efficace de reguler la charge de travail sur la grappe plutot que de vouloir
tout effectuer en meme temps,
une organisation dans lexecution des taches est profitable `a tous les utilisateurs
de la grappe.
De plus, nous avons detecte un probl`eme de performance qui peut etre ameliore lors
de lexecution de processus courts. Enfin, il aurait ete interessant, dans le cadre de nos
tests avec migration, dexecuter plus que 4 processus `a la fois. Cependant nous navons
pu le faire `a cause dun probl`eme temporaire de stabilite de Kerrighed. Cela reste donc
une perspective de travail.

48

5.6

CHAPITRE 5. EVALUATION

Ordonnancement des applications

Nous montrons maintenant quil est possible dobtenir des cas o`


u la gestion des
processus differes pour des processus navantage pas tous les utilisateurs. Nous profitons
de ce test pour tester lexecution de lapplication MrBayes qui est `a lorigine de la
conception et de la mise en uvre de cette fonctionnalite.
Nous considerons trois utilisateurs. Le premier utilisateur dispose de deux calculs de
MrBayes dune duree de 1 minute et 30 secondes chacun. Le second veut executer un
calcul de 3 minutes, et le troisi`eme un calcul de 6 minutes 1 . Lorsque les trois utilisateurs
lancent leur calcul sur la grappe 2 il est tout `a fait possible que la file dattente se
remplisse avec un processus de lutilisateur 1, puis un de lutilisateur 2, puis un de
lutilisateur 3 et de nouveau un de lutilisateur 1.
Nous obtenons le graphe 5.6 avec en absisse les processus 0 et 3 correspondant `a
ceux de lutilisateur 1. Le processus 1 correspond `a celui de lutilisateur 2 et le processus
2 `a lutilisateur 3.
R
esultats. On se rends compte que pour les trois premiers resultats, lexecution avec
gestion des processus differes est plus performante quun syst`eme Linux standard. En
revanche, dans le cas de la derni`ere application plus courte (1 minute et 30 secondes)
qui se trouve apr`es les autres applications les resultats sont obtenus bien apr`es ceux de
la reference Linux. Lutilisateur 1 se trouve alors penalise car, sil a besoin de ses deux
resultats dapplication pour valider une hypoth`ese, alors, il doit attendre en tout pr`es
de 15 minutes alors que le syst`eme Linux standard lui aurait donne ses deux resultats
au bout de 6 minutes environ.
Conclusion. Ces resultats sexpliquent par le fait quen gestion des processus differes,
les processus sexecutent les uns apr`es les autres dans lordre dans lequel ils sont arrives
dans la file des processus differes. Donc, un processus court se trouvant (( derri`ere )) des
processus longs ne pourra sexecuter que lorsque les premiers seront termines. Ici, le
dernier calcul de MrBayes ne pourra sexecuter au mieux qu`a partir de 10 minutes et
30 secondes.
Afin dy remedier, nous pourrions mettre en place une politique de gestion de la
file dattente des processus differes plus performante. Par exemple, dans la file dattente, nous pourrions regrouper tous les processus dun utilisateur ensemble. Ainsi, un
utilisateur obtiendrait tous ses resultats avant que les calculs dautres utilisateurs se
fassent (ce qui eviterait quun utilisateur puisse avoir differents travaux en file dattente
entrecoupe par des travaux dautres utilisateurs).

1. On est bien loin de la centaine dheures de calcul dont nous avons pu parler dans la section 3.1,
cependant, du point de vue du syst`eme, nous pouvons considerer quun processus est long d`es quil
depasse cinq secondes de temps dexecution.
2. afin de simplifier nos experiences, nous consid`erons une grappe o`
u lon nutilise quun seul nud
comme en section 5.3 sans la capacite de migration.

5.6. ORDONNANCEMENT DES APPLICATIONS

Fig. 5.6 MrBayes avec gestion des processus differes

49

50

CHAPITRE 5. EVALUATION

Conclusion
Kerrighed est un syst`eme dexploitation `a image unique dont le but est de simplifier
lutilisation de ressources distribuees au sein dune grappe. Il est developpe par lequipe
PARIS. Nous avons etudie le comportement de Kerrighed avec des applications de type
bio-informatique. Pour cela, nous avons pris contact avec les membres du laboratoire de
biologie du Molecular Ecology Group situe au Pays de Galles. De nos discussions, il est
ressorti quil existe une classe dapplication dont le temps dexecution est tr`es long et
qui peut saturer les ressources informatiques (MrBayes est un exemple dapplication de
ce type). Or, ces biologistes ne disposent pas de ressources dediees au calcul (ils utilisent
generalement leur machine de bureau).
Il existe des syst`emes `a execution par lots dont le but est de gerer le placement des
travaux au sein de ressources heterog`enes. Les fonctionnalites quoffrent ces syst`emes
sont tr`es proches de celles que peuvent offrir le syst`eme `a image unique Kerrighed
mais `a la difference notable que, Kerrighed ne permet pas la creation de processus de
mani`ere differee (ce qui est essentiel pour tout syst`eme desirant gerer les ressources dont
il dispose). Nous etudions dans quelle mesure il est possible dintegrer ce mecanisme de
creation de processus differes au sein de Kerrighed.
Pour gerer un processus de mani`ere differee, il faut :
le stopper au moment de sa creation et le mettre dans une file des processus
differes,
reveiller les processus en attente dans la liste des processus differes,
ordonnancer les processus differes en cours dexecution et si besoin, stopper des
processus differes en cours dexecution.
Afin de rendre le syst`eme plus reactif, nous avons mis en place un syst`eme de charge
virtuelle qui pallie les latences que la charge reelle peut avoir.
Il existe maintenant dans Kerrighed un mecanisme de gestion des processus differes.
Kerrighed peut gerer de mani`ere plus efficace les ressources dont il dispose. Cela est
confirme par les evaluations que nous avons pu realiser (organisation des travaux dans
le syst`eme, regulation de la charge moyenne du syst`eme, execution de make -j ).
De plus, au cours dun stage dete realise en 2005 toujours au sein de lequipe PARIS,
nous avons pu mettre en uvre un Kerrighed-LiveCD `a lorigine de demonstration
pour lanniversaire des 30 ans de lIRISA. Ce liveCD permet le deploiement ainsi que
lutilisation de Kerrighed de mani`ere tr`es simple via une interface graphique conviviale.
Il serait interessant dimplementer cette nouvelle version de Kerrighed sur le liveCD
ainsi que lapplication MrBayes. Cela fournirait aux biologistes une solution (( cle en
main )) dans laquelle ils pourraient beneficier de la simplicite dutilisation ainsi que de
la gestion efficace de leurs ressources informatiques.
Perspectives. Bien que la gestion des processus differes soit operationelle, differents
domaines peuvent encore etre etudies. Tout dabord celui de la gestion des processus
courts, et aussi celui de la gestion des applications au sein des syst`emes `a image unique.
En effet dans le cadre de la gestion differee des processus, comment eviter que si un
51

52

CONCLUSION

utilisateur lance plusieurs calculs interdependants en meme temps il ne puisse pas y


avoir des calculs dautres utilisateurs qui puissent venir sinserer dans la file dattente
des processus differes entre ses calculs.
Apport personnel Ce stage ma permis de travailler au sein des syst`emes dexploitation distribues. Ce qui me permet maintenant de mieux les apprehender. Au cours de
ce stage jai pu realiser un projet complet avec :
etude des besoins (contact avec les biologistes),
etude de lexistant (etat de lart),
conception de la gestion differee de processus,
mise en uvre de cette fonctionnalite au sein de Kerrighed,
realisation devaluations.
Cela ma conduit naturellement vers du developpement noyau. Ce stage a dune
certaine mani`ere change ma vision de linformatique. En effet, bien que mes etudes mont
montre quil ny a rien de (( magique )) au cur des syst`emes informatiques, je navais
jamais jusqualors realise reellement tout ce qui pouvait se passer dans un syst`eme
dexploitation et de surcroit un syst`eme dexploitation distribue, lorsque lutilisateur,
par exemple, frappe une commande dans sa fenetre de terminal (cependant, je nai
pas la pretention de dire `a lheure actuelle que je comprends tout ce qui sy passe !).
Et pourtant cette succession dactions qui se produit et qui peut paratre effrayante au
premier abord lest beaucoup moins d`es que lon se plonge reellement dans le sujet. Cest
alors que lon se rend compte que le noyau nest en fait quune succession de fonctions
en appelant dautres et malgre la complexite que chacune dentre elle peut avoir, il ny
a reellement rien de (( magique )) !
En outre, avoir travaille un an (stage dete compris) dans cet environnement de
recherche ma donne lenvie de continuer et delargir mon champ de competences dans
le monde de la recherche. Actuellement, nous sommes en train de rediger un article.
De plus lannee prochaine, je minscrirais en master recherche de deuxi`eme annee en
informatique.

CONCLUSION

53

BIBLIOGRAPHIE

VII

Bibliographie
[1] Pawan Agnithotri, Vijay K. Agarwala, Jeffrey J. Nucciarone, Kevin M. Morooney,
and Chita Das. The penn state computing condominium scheduling system. In
Conference on High Performance Networking and Computing - Proceedings of the
1998 ACM/IEEE conference on Supercomputing. IEEE Computer Society, 1998.
[2] Olaf Arndt, Bernd Freisleben, Thilo Kielmann, and Frank Thilo.
Batch
queueing in the winner resource management system, 1999. Also available as
http://citeseer.ist.psu.edu/arndt99batch.html.
[3] A. Baker, Geoffrey C. Fox, and Hon W. Yau. Cluster management software. Review
1.3, NHSE, Northeast Parallel Architectures Center, November 1995. Available as
http://nhse.cs.rice.edu/NHSEreview/CMS.
[4] Daniel P. Bovet and Marco Cesati. Understanding the Linux Kernel. OReilly, 3rd
edition, November 2005.
[5] N. Capit, G. Da Costa, G. Huard, C. Martin, G. Mounie, P. Neyron, and O. Richard. Experiences autour dune nouvelle approche de conception dun gestionnaire de travaux pour grappe. In Actes de CFSE 2003, 2003. Also available as
http://oar.imag.fr/papers/oar cfse03.pdf.
[6] Nicolas Capit, Georges Da Costa, Yiannis Georgiou, Guillaume Huard, Cyrille
Martin, Gregory Mounie, Pierre Neyron, and Olivier Richard. A batch scheduler
with high level components. In Cluster computing and Grid 2005 (CCGrid05),
2005. Also available as http://oar.imag.fr/papers/oar ccgrid05.pdf.
[7] Inc Cluster Resources.
Torque Resource Manager.
Available as
http://www.clusterresources.com/pages/products/torque-resource-manager.php.
[8] IBM Corp. Tivoli Workload Scheduler Loadleveler. Available as http://www306.ibm.com/software/info/ecatalog/fr FR/products/U831706H96140M93.html.
[9] Yves Epelboin. Syst`emes dexploitation des ordinateurs, 2000. Available as
http://www.impmc.jussieu.fr/impmc/Enseignement/ye/informatique/systemes/chap3/324.html.
[10] Joe Freeman.
What does load average
http://web.gat.com/docview/load average.html.

mean?

Available

as

[11] Jerome Gallard. Kerrighed-LiveCD, Reference Manual, October 2005. Available


as http://www.kerrighed.org.

VIII

BIBLIOGRAPHIE

tude du comportement de lapplication bio-informatique


[12] Jerome Gallard.
e
MrBayes sur le syst`eme Kerrighed. Technical report, IRISA / INRIA Rennes,
2006. Available as http://www.kerrighed.org.
[13] Jerome Gallard. Kerrighed-LiveCD. Technical report, IRISA / INRIA, 2006.
Available as http://www.kerrighed.org.
[14] Pascal Gallard. Conception dun service de communication pour syst`emes dexploitation distribues pour grappes de calculateurs: mise en oeuvre dans le syst`eme
`
a image unique Kerrighed. PhD thesis, IRISA, Universite de Rennes 1, IRISA,
Rennes, France, December 2004.
[15] GForge
Inria.
Kerrighed
Project
Info.
Available
as
http://gforge.inria.fr/projects/kerrighed.
[16] Claude
Labit.
Irisa
welcome
page.
Availlable
as
http://www.irisa.fr/irisa/presentation.
[17] Renaud Lottiaux. Gestion globale de la memoire physique dune grappe pour un
syst`eme `
a image unique : mise en oeuvre dans le syst`eme Gobelins. PhD thesis,
IRISA, Universite de Rennes 1, December 2001.
[18] Renaud Lottiaux, Benoit Boissinot, Pascal Gallard, Geofroy Vallee, and Christine
Morin. Openmosix, openssi and kerrighed : a comparative study. Technical report,
IRISA / INRIA, 2004.
[19] David Margery, Renaud Lottiaux, and Christine Morin.
Kerrighed V1.0 : Manuel de reference.
Irisa, Fevrier 2005.
Available as
http://www.kerrighed.org/docs/Reference-Manual.pdf.
[20] Jean-Christophe Pettier. Programmation unix. cours ENSSAT LSI1, 2004.
[21] Jean-Christophe Pettier. Programmation noyau. cours ENSSAT LSI2, 2005.
[22] Kyung Dong Ryu and Jeffrey K. Hollingsworth. Fine-grain stealing for networks
of workstations. Technical report, University of Maryland, 1998.
[23] Jean Seguin. Syst`eme dexploitation et reseau. cours ENSSAT LSI3, 2006.
[24] Condor Team.
Condor Project Homepage.
Available as
http://www.cs.wisc.edu/condor.
[25] Kerrighed Team.
Kerrighed project welcome page.
Available as
http://www.kerrighed.org.
[26] Mosix Team. MOSIX - Cluster and Grid Management, 2006. Available as
http://www.mosix.org.
[27] OpenSSI Team. Openssi. Available as http://openssi.org.
[28] Geoffroy Vallee. Conception dun ordonnanceur de processus adaptable pour la
gestion globale des ressources dans les grappes de calculateurs : mise en oeuvre dans
le syst`eme dexploitation Kerrighed. PhD thesis, IFSIC, Universite de Rennes 1,
France, March 2004.
[29] Paris Webmasters.
Paris project welcome page, 2006.
Available as
http://www.irisa.fr/paris.
[30] Wikipedia.
Batch
processing.
Available
as
http://en.wikipedia.org/wiki/Batch processing.

BIBLIOGRAPHIE

IX

[31] Wikipedia. Bio-informatique. Available as http://fr.wikipedia.org/wiki/Bioinformatique.


[32] Wikipedia.
Load
(computing).
Available
as
http://en.wikipedia.org/wiki/Load average.
[33] Wikipedia. Traitement par lots. Available as http://fr.wikipedia.org/wiki/Batch.

BIBLIOGRAPHIE

Glossaire
Appel syst`
eme (fonction syst`
eme) : designe une fonction qui accomplit une
tache au niveau syst`eme (espace noyau) pour le compte dun processus (espace
utilisateur).
Architecture distribu
ee : voir la definition de grappe de calculateurs.
Charge du syst`
eme (load average) : voir la section 2.2.1.
D
eboguer : action permettant de rechercher et deliminer les erreurs de programmation dun logiciel provoquant un probl`eme lors de son execution.
Espace utilisateur : designe sur les syt`emes dexploitation dotes dun noyau
(comme Linux), la region memoire dediee aux applications `a lexclusion du noyau
lui-meme qui dispose de son propre espace de memoire.
Grappe de calculateurs : voir la section 2.1.
Haute performance : la haute performance concerne toutes les applications
scientifiques parall`eles et englobe rapidite dexecution et fiabilite du syst`eme.
Linux (GNU/Linux) : est un syst`eme dexploitation libre, multit
ache, multiutilisateur de type Unix.
Processeur (Central Processing Unit - CPU ) : est le composant essentiel
dun ordinateur, qui execute les programmes et o`
u sont effectues les principaux
calculs.
Processus (process) : est defini par un ensemble dinstructions `a executer (un
programme), un espace memoire pour les donnees de travail, eventuellement,
dautres ressources, comme des descripteurs de fichiers, des ports reseau, etc. La
section 3.2 donne dautres informations sur ce sujet.
Processus diff
er
e : voir la section 3.3.1.
R
eseau local (Local Area Network - LAN ) : est un reseau informatique `a
une echelle geographiquement restreinte (par exemple, une salle informatique, un
batiment ou un site precis).
Ressource : on definit une ressource comme une unite informatique permettant
un traitement specifique. Par exemple, nous considerons au sein dune grappe
quun nud est une ressource. De plus un nud est compose de memoires, de
processeurs que nous designons egalement comme des ressources.
Supercalculateur (ou calculateur parall`
ele) : est un ordinateur concu pour
atteindre les plus hautes performances possibles avec les technologies connues au
moment de sa creation. Il est compose de nombreux processeurs, dune importante memoire et est souvent utilise pour des simulations scientifique comme pour
la simulation des phenom`enes physiques. Un supercalculateur se differencie dune
grappe par le fait que dans un supercalculateur toutes les ressources sont interconnectees via des bus de communication. Alors que pour une grappe, toutes les
ressources sont independantes et interconnectees par un reseau rapide dans le but
de former une meme unite de traitement.
Syst`
eme `
a ex
ecution par lots (batch scheduling ) : voir la section 2.2.1.
XI

XII

GLOSSAIRE

Syst`
eme `
a image unique (Single System Image - SSI ) : voir la section
2.3.1.
Syst`
eme dexploitation (Operating System - OS ) : assure la liaison entre les
ressources mat`erielles dun ordinateur et les aplications de lutilisateur. Il assure
le demarrage de lordinateur et fournit aux programmes applicatifs des interfaces
standardisees pour les peripheriques.
Syst`
eme multi-processeur (Symmetric multiprocessing - SMP) : est une
architecture qui consiste `a multiplier les processeurs au sein dun ordinateur, de
mani`ere `a augmenter la puissance de calcul. Laugmentation du nombre de processeurs permet dexecuter simultanement un plus grand nombre de processus du
syst`eme en meme temps.

Annexe A

Annexe
A.1

Le champs fd status

La gestion des points de reprise dapplication est plus delicate lorsquil sagit de
processus differes. Nous avons cree un champ specifique (fd status) permettant de gerer
cela. Le champ fd status est du type pfd status :
typedef enum{
PFD_OK,
PFD_BLOCKED
} pfd_status;
Ce champ permet `a un processus differe se trouvant en debut de liste (donc pret `a
etre reveille `a tout moment) de ne pas letre. En effet, pendant quune sauvegarde de
point de reprise dune application est en cours, celle-ci doit etre arrete pendant toute
la duree de loperation. Il ne faut donc pas quun processus de cette application en file
dattente des processus differes puisse etre reveillee.
Voici les fonctions que nous avons rajoutees permettant de gerer ce champ :

A.1.1

int check and block(struct task struct *tsk)

Cette fonction verifie si tsk est dans la liste des processus differes. Elle le bloque si
cest vrai et retourne 1. Sinon, elle retourne 0.

A.1.2

int check and unblock(struct task struct *tsk)

Cette fonction regarde si tsk est dans la liste des processus differes, le debloque si
cest le cas et retourne 1. Sinon retourne 0.

A.1.3

void add a pfd at the end of the list(struct task struct *tsk)

Cette fonction ajoute un processus differe `a la fin de la liste.


XIII

XIV

A.2

ANNEXE A. ANNEXE

Activation de la gestion des processus diff


er
es

Pour active la gestion des processus differes au sein de Kerrighed, il est necessaire
de compiler le noyau Linux ainsi que les modules Kerrighed avec les bonnes options.
Nous avons cree une entree dans les options de configuration du noyau permettant
dactiver ou de desactiver la gestion des processus differes. Pour y acceder, apr`es avoir
recuperer les sources du noyau Linux et de Kerrighed depuis le SVN [15], il faut faire
make menuconfig, et acceder au bon menu en allant dans la section Cluster support,
puis KerEPM, puis Activate Fork Delay et enfin choisir la version de processus differes
desires (version dont le reveil est `a linitiative dun nud appartenant `a un anneau avec
jeton, ou version dont le reveil est `a linitiative de chaque nud).

A.3

R
eveil `
a linitiative dun nud sur un anneau `
a jeton

Afin de savoir quel est letat de lanneau, ou est le jeton etc, nous avons implemente
deux variables. Chaque nud dispose de deux variables globales :
var chan admin : donne letat de lanneau,
jeton : donne letat du jeton.

A.3.1

La fonction handle admin();

Cette fonction est activee `a chaque fois quun message de type ADMIN est recu sur
le canal FD CHAN. Ci-dessous nous presentons les valeurs que ce message peut prendre
ainsi que sa signification :
msg 0 : le nud numero msg demande la creation du jeton,
msg = 1 : pas de jeton dans lanneau,
msg = 2 : jeton cree : un nud a cree le jeton,
msg = 3 : message local pour reveiller le fd management. 1
Nous avons cree une variable globale var chan admin permettant denregistrer les
demandes de creation du jeton par dautres nuds.
Variable var chan admin, administration de lanneau : Cette variable peut
prendre les valeurs suivantes selon les differentes configuration de lanneau :
var chan admin 0 : le nud de numero var chan admin demande la creation
du jeton,
var chan admin = 1 : pas de jeton dans lanneau,
var chan admin = 2 : jeton cree : il y a un jeton dans lanneau !
1. TODO: dans quel cas, passe-t-on par ce bout de code?


` LINITIATIVE DUN NUD SUR UN ANNEAU A
` JETON
A.3. REVEIL
A

XV

Fig. A.1 Machine detat de la fonction handle admin

A.3.2

La fonction handle jeton();

Cette fonction est activee lorsquun message de type JETON est recu sur le canal
FD CHAN. Les valeurs de messages recu sont :
msg 0 : le nud courant recoit le jeton et msg contient la valeur du dernier
nud a avoir consomme le jeton.
Variable jeton, gestion du jeton : de mani`ere analogue `a precedemment, nous
presentons les significations des differentes valeurs que peut prendre cette variable :
jeton 0 : jai le jeton, et le numero que porte le jeton correspond au numero du
dernier nud layant utilise.
jeton = 1 : je nai pas le jeton,

XVI

ANNEXE A. ANNEXE

Fig. A.2 Machine detat de la fonction handle jeton

A.4

Pseudo-algorithme de notre application de simulation

entier nombre_de_processus = recuperer_parametre_utilisateur(0);


entier taille_mem = recuperer_parametre_utilisateur(1);
entier compteur = 0;
BOUCLE_SUR(tant_que compteur < nombre_de_processus)
SI creer_fils() ALORS
//code du fils
mem = allouer_memoire(taille_mem);
ecrire_dans_memoire(mem);
FINSI
compteur = compteur + 1;
FINBOUCLE_SUR
compteur = 0;
BOUCLE_SUR(tant_que compteur < nombre_de_processus)
attendre_terminaison_d_un_fils();
afficher_temps_execution_du_fils();
compteur = compteur + 1;
FINBOUCLE_SUR