Chargement

Le r™le du chargeur consiste ˆ prendre un format objet, ˆ en extraire les diffŽrentes sec-tions (t‰ches, objets, symboles Žventuels), ˆ les placer plus ou moins optimalement sur un cluster de processeurs, ˆ indiquer ˆ la Pt‰che de contr™le du syst•me quÕune nouvelle Pt‰che ˆ ŽtŽ crŽŽe, ˆ rŽcupŽrer du syst•me un certain nombre dÕinformations (comme les identificateurs de ports des serveurs disque, imprimante, etc.), et ˆ finalement lancer lÕexŽcution de la Pt‰che.

Nous nous pla•ons Žvidemment dans la situation o• lÕapplication peut •tre lancŽe (cÕest-ˆ-dire quÕau moins minp ou pws processeurs sont disponibles dans le syst•me). Dans toute la suite de ce paragraphe, nous dŽsignerons par Np le nombre de processeurs allouŽs ˆ la Pt‰che (ce nombre ne tient pas compte du processeur de contr™le et du nombre de processeurs mŽmoire qui ont ŽtŽ aussi allouŽs), et par Ne le nombre dÕentitŽs de la Pt‰che quÕil faut charger en mŽmoire (i.e. celles dont lÕattribut aPreload est ˆ un).

Chapitre 5 : Gestion des entitŽs dans ParObj

Allocation

Une fois un cluster de Np processeurs (logiques) allouŽs, le chargeur doit rŽcupŽrer les informations dÕallocations qui sont stockŽes dans lÕune des sections du format objet. Dans ce paragraphe, nous ne dŽcrivons pas comment les algorithmes dÕallocation sta-tique dÕentitŽs aux processeurs fonctionnent, ce nÕest pas le sujet de cette th•se. Cette mati•re ayant fait, et faisant toujours lÕobjet dÕactives recherches au sein de lÕŽquipe ÒSYMPAÓ [Eu90], [MT88], [Me88], [SuI89], [TM90], nous renvoyons le lecteur ˆ ces travaux pour plus dÕinformations. Nous supposerons donc quÕil existe un ou plusieurs

allocateurs disponibles dans la Pt‰che des services syst•me (nous utilisons

volontaire-ment le terme plusieurs, car il nÕexiste pas ˆ lÕheure actuelle dÕalgorithmes dÕallocation efficaces pour nÕimporte quel type dÕapplication).

Dans le cas o• aucune information dÕallocation nÕest fournie, nous supposerons que la politique de placement du syst•me est compl•tement alŽatoire, bien quÕelle doive ce-pendant respecter certaines contraintes telles que placer sur le processeur de contr™le les entitŽs avec lÕattribut aControl, et ne pas sŽparer les entitŽs statiques des entitŽs avec lesquelles elle communique. En cours dÕexŽcution, le syst•me pourra toujours essayer dÕamŽliorer ce placement initial, gr‰ce par exemple, ˆ un algorithme dÕŽquilibrage de charge.

La phase dÕallocation est divisŽ en plusieurs Žtapes qui sont :

1. Le chargeur envoie ˆ un allocateur toutes les informations sur la Pt‰che dont il

dispose (Np, Ne, graphe et cožt de communication entre entitŽs, temps dÕexŽcu-tion des t‰ches et objets actifs, nombre de services syst•me accŽdŽs, etc.). Si un graphe particulier de processeurs physiques est rŽclamŽ (nous lÕappellerons la

grappe prŽdŽfinie et nous le noterons p§), il est aussi envoyŽ ˆ lÕallocateur.

Note : ce dernier graphe nÕest utile que sur des machines parall•les dont le

mŽca-nisme matŽriel ne permet pas toujours dÕŽtablir de multiples connexions entre processeurs (cas du Supernode). Alors fournir un graphe physique, permet dÕindi-quer au syst•me que parmi les configurations possibles, nous prŽfŽrons celle qui se rapproche le plus du graphe que nous fournissons. Enfin, si la machine nÕest pas dynamiquement reconfigurable (i.e. les connexions entre processeurs sont fixŽes au dŽmarrage de la machine), alors le graphe physique ne sert ˆ rien.

2. LÕallocateur retourne un graphe physique optimal (notŽ o§) ˆ Np processeurs (avec leurs connexions) o• le cožt des communication entre entitŽs est le plus faible, et le schŽma de placement de ces entitŽs (graphe logique) sur les diffŽrents processeurs du graphe oß. Si un pß Žtait fourni, oß est Žgal ˆ pß.

Nous supposerons dans la suite de lÕalgorithme quÕun graphe physique est nŽces-saire. Dans le cas contraire, il suffit dÕignorer les phases 3. et 4. de lÕalgorithme.

3. Le chargeur appelle alors le topographe rŽseau (un autre service syst•me) dont le

Chapitre 5 : Gestion des entitŽs dans ParObj

Ce programme retourne un graphe (§) qui ressemble le plus possible au graphe oß. ß peut •tre le m•me que oß (surtout si cÕest lÕutilisateur qui lÕavait fourni), mais il peut aussi •tre radicalement diffŽrent (considŽrez par exemple le cas o• lÕutilisateur a rŽclamŽ cinq acc•s directs vers le gestionnaire de fichiers et que seul un acc•s est disponible).

4. Si ß est diffŽrent de oß, le chargeur appelle de nouveau lÕallocateur (avec ß comme param•tres). LÕallocateur retourne alors le graphe de placement des Ne entitŽs sur le graphe ß.

5. Le chargeur appelle alors le configurateur de la machine (qui fait partie de la

Pt‰che de reconfiguration de la machine) dont le r™le est dÕŽtablir les connexions physiques entre les diffŽrents processeurs de la grappe ß et de calculer les tables de routage qui doivent •tre placŽes sur chaque processeur de la grappe, afin que le routage des messages soit sans interblocage (Cf. [MMS91] pour plus dÕinforma-tions).

Cette configuration est envoyŽe ˆ la Pt‰che de contr™le syst•me pour quÕelle conserve la correspondance entre le cluster logique et la configuration physique. Le cluster de la Pt‰che est donc maintenant configurŽ.

Le chargeur demande aussi ˆ la Pt‰che de contr™le syst•me de crŽer la Pt‰che uti-lisateur sur ce cluster. Bien que la Pt‰che soit enregistrŽe, elle nÕest toujours pas active et donc nÕest pas encore visible par les autres Pt‰ches de la machine.

6. Enfin, le chargeur active dÕune mani•re rŽcursive le µ-noyau de chaque proces-seur (sÕil Žtait dormant), installe les diffŽrentes tables de routages, charge (sÕils nÕŽtaient pas disponibles) et dŽmarre les diffŽrents serveurs (serveurs de noms,

serveurs dÕentitŽs, serveur mŽmoire, etc.) de ParObj.

Les Ne entitŽs de la Pt‰che peuvent maintenant enfin •tre chargŽes !

Placement

Le chargeur, gr‰ce au graphe logique de placement des entitŽs, installe alors chaque en-titŽ dans la mŽmoire du processeur correspondant, convertit lÕenen-titŽ en quelque chose de comprŽhensible pour le processeur si la machine parall•le est hŽtŽrog•ne, et rŽalise aussi les Žventuelles relocations de code et de donnŽes des entitŽs.

Une fois ces opŽrations effectuŽes, le chargeur exŽcute pour chaque entitŽ, un certain nombre dÕappels syst•mes (par exemple task_create(), pour crŽer une t‰che, puis thread_create() pour crŽer ses diffŽrentes Pt‰ches, port_create() pour crŽer un port, etc.) qui ont pour effet dÕinformer le serveur dÕentitŽ de chaque processeur quÕil doit allouer dans sa table une nouvelle structure appelŽe bloc de contr™le dÕentitŽ (ECB). Cette structure contient un certain nombre dÕinformations pour la gestion de lÕentitŽ et sera expliquŽe en dŽtail dans le chapitre 5.2.4 suivant.

Chapitre 5 : Gestion des entitŽs dans ParObj

Nous avons vu dans le paragraphe ÒDŽsignation des entitŽsÓ que le mŽcanisme de dŽsignation de ParObj utilise des caches et des serveurs pour retrouver les entitŽs. CÕest pourquoi, le chargeur stocke sur le processeur de contr™le associŽ ˆ la Pt‰che, les EID et la localisation correspondante de toutes les entitŽs globales (qui viennent dÕ•tre crŽeŽs) de la Pt‰che. De plus, lorsque lÕinformation est disponible (gr‰ce par exemple au graphe entre entitŽs), le chargeur indique aussi au serveur dÕentitŽs de chaque processeur, la lo-calisation des entitŽs distantes qui sont accŽdŽes par les entitŽs situŽes sur ce proces-seur.

Le chargeur enfin, stocke dans une table (gŽrŽe par le serveur de nom) sur chaque pro-cesseur, le nom logique (qui est le nom par lequel lÕutilisateur accŽdera ˆ lÕentitŽ) des entitŽs qui ont ŽtŽ prŽchargŽes (attribut aPreload ˆ un), mais qui ne sont pas rŽfŽren-cŽes lorsque la Pt‰che dŽmarre.

La figure 5.9 dŽtaille le placement des diffŽrentes entitŽs (7 objets et 4 t‰ches dans lÕexemple) dÕune Pt‰che. Le chargeur ayant eu la connaissance de certaines dŽpen-dances entre entitŽs, a pu par exemple indiquer au serveur dÕentitŽs du processeur P1 que O4 se trouve sur P2. Il a fait de m•me avec les serveurs dÕentitŽs sur P2 et P3 (ainsi ce serveur conna”t la localisation de T1 et de O1). Le processeur de contr™le enfin est informŽ de la localisation de toutes les entitŽs globales de la Pt‰che. CÕest pourquoi T4 et O7 (qui sont statiques) ne figurent pas dans sa table.

P1

O1 ^O2

T4

: µ-noyau : serveur d'entitŽs ^{: t‰che ou} objet global : t‰che ou objet statique P2 O7 O4 T1 O3 P3 O5 ^O6 T2 T3 T1 T2 T3 01 02 03 04 05 06 P2 P3 P3 P1 P1 P2 P2 P3 P3 04 P2 _{T1 P2} O1 T1 Processeur de contr™le contr™le

Pt‰che Utilisateur Pt‰che de contr™le

Localisation 03 04 07 T1 @O1 @O2 @O7 @T1 @T2 @T3 @O5 @O6 T2 T3 O5 O6 01 02 T4 @O1 @O2 @T4

Chapitre 5 : Gestion des entitŽs dans ParObj

Contr™le

Sur le processeur de contr™le associŽ ˆ la Pt‰che, le chargeur crŽe une t‰che de contr™le dont le but est la gestion de la Pt‰che et la synchronisation des diffŽrentes entitŽs exŽcu-tables (t‰ches et objets actifs Žventuels) qui la composent. Cette t‰che a le maximum de droits possibles, par exemple elle peut dŽtruire nÕimporte quelle entitŽ de la Pt‰che. D•s que la phase de chargement est terminŽe, le chargeur dŽmarre la t‰che de contr™le, et indique au syst•me que lÕinstallation de la Pt‰che sÕest correctement passŽe. CÕest alors le r™le de cette t‰che de dŽmarrer simultanŽment les entitŽs exŽcutables, de les suspendre (par exemple ˆ la suite dÕune phase de reconfiguration du cluster de la Pt‰che), de les redŽmarrer, etc., et dÕindiquer au syst•me (i.e. ˆ la Pt‰che de gestion sys-t•me) les changements dÕŽtat de cette Pt‰che.