Lecture de traces

Fonctionnement du lecteur de traces

Le lecteur de traces TAPE/PVM est bien plus simple que celui de TAPE pré-senté précédemment, tout simplement parce que la structure du fichier d’événe-ments est extrêmement simple ; il n’y a donc qu’une classe effectuant la lecture

de traces, et celle-ci utilise une version corrigée des fonctions de récupération d’événements fournies avec TAPE/PVM.

Le lecteur ayant obligation de fournir des événements ordonnés il commence par trier la trace si celle-ci en a besoin puis effectue une lecture séquentielle de celle-ci au fur et à mesure des demandes d’événements.

Pour simuler les changements d’états d’une application, il faut qu’un événe-ment ne change qu’une fois l’état d’un objet donné : il est ainsi possible de regar-der l’ensemble des états des objets après le traitement de chaque événement pour obtenir un film de l’exécution de l’application. Or le traceur ne génère pas d’événements de début et de fin d’action mais plutôt des événements comportant une date de début et une durée, et qui correspondent donc à deux événements lo-giques. Le lecteur de trace introduit donc les événements logiques manquant lors de la production d’événements. Ces événements de fin, qui sont par convention appelés End*(comme par exemple EndSend pour la fin d’unSend), sont des copies des événements d’origine à ceci près que leur date correspond à la date de l’événement d’origine augmentée de la durée de l’action et qu’ils comportent une indication de leur statut d’événements de terminaison.

L’introduction de ces événements provoque cependant un problème d’ordre des événements puisqu’ils n’appartiennent pas à proprement parler à la trace qui a été triée. Le lecteur de trace utilise donc un échéancier pour interclasser les évé-nements lus dans la trace et ceux qu’il introduit, afin de produire les évéévé-nements dans un ordre correct.

Pour produire un événement, le lecteur de traces effectue donc les opérations suivantes :

– lecture d’un événement dans le fichier d’événements ;

– si l’événement a une durée, création d’un événement de fin lui correspon-dant et insertion de ce dernier dans l’échéancier ;

– insertion de l’événement lu dans l’échéancier ;

– récupération du premier événement de l’échéancier, qui devient l’événe-ment courant.

Outre les événements, le lecteur de trace gère des objets représentant les dif-férentes entités d’une application, i.e. les processeurs, les tâches et les groupes

2.4. SUPPORT DES APPLICATIONS PVM

auxquelles ces dernières appartiennent.

Classes d’événements

Le lecteur de traces transforme les événements contenus dans la trace en objets afin qu’ils soient faciles à manipuler.

La hiérarchie de classes qui est définie correspond à la classification des événe-ments présentée dans le tableau 2.10 page 113. Elle est donnée dans la figure 2.6 page suivante qui indique les différentes classes existantes ainsi que les événe-ments traités par chacune d’entre elles.

2.4.3 Simulation

États des objets manipulés

L’état d’une application PVM est un graphe dont les sommets représentent les tâches de l’application et les arêtes les liens de communication entre ces tâches.

Rappelons que le traceur TAPE/PVM est un traceur logiciel qui effectue une prise de trace au niveau de l’application et non du système (qu’il s’agisse du sys-tème d’exploitation des machines sur lesquelles l’application est exécutée ou sim-plement de PVM lui-même). Les informations que peut fournir le traceur quant aux changements d’états de l’application sont donc limitées : il est possible de sa-voir quant une tâche appelle une fonction PVM et quand cet appel de fonction se termine mais il est impossible de savoir exactement ce qui se passe pendant que la fonction est exécutée.

Nous dirons d’une tâche qu’elle est dans l’état actif lorsqu’elle calcule et dans l’état mort lorsqu’elle a fini de s’exécuter13. Elle sera dite dans l’état système lorsqu’elle est en train d’effectuer une fonction non bloquante de PVM : le temps passé dans cet état indique le surcoût (overhead) lié à l’appel des fonctions

13: Le comportement par défaut du simulateur est de conserver une tâche morte afin qu’il soit possible d’accéder aux statistiques qu’il lui associe, voir plus loin. Il est cependant envisageable de supprimer ces tâches afin de ne pas encombrerl’état (si l’état comporte un nombre très important d’objets il se peut que les performances du simulateur se dégradent).

TapePvmPackingEvent Pk* Upk* Enroll Exit TapePvmTaskEvent TapePvmGroupEvent JoinGroup LvGroup TapePvmGroupOpEvent Barrier TapePvmCommEvent TapePvmPointCommEvent Send PSend

Recv PRecv NRecv TRecv

TapePvmGlobalCommEvent

Mcast

TapePvmGroupCommEvent

Bcast

Scatter Gather Reduce

TapePvmEvent

TapePvmDataManagementEvent

FIG. 2.6. – Hiérarchie des classes d’événements de TAPE/PVM. Les classes sur fond rouge sont des classes abstraites.

2.4. SUPPORT DES APPLICATIONS PVM

de la bibliothèque de programmation PVM. En ce qui concerne les opérations de communication une tâche peut être dans l’état inactif lorsqu’elle est bloquée ou dans l’état communicant lorsqu’elle reçoit un message de façon bloquante. Cet état n’a pas de sens pour les émissions de messages puisqu’elles sont non bloquantes.

L’identification des états associés aux liens de communications est nettement plus délicate. En effet l’envoi de message en PVM est non bloquant : la fonction d’émission rend la main à la tâche appelante dès que les données ont été placées dans un tampon système et envoyées au(x) destinataire(s). Si l’on considère éga-lement le fait que les fonctions de réception ne donnent qu’une indication de la présence des données au moment de l’appel comme seule information relative à la transmission des données il est impossible de déterminer le temps effectif pris par la communication dans le cas où le message est déjà présent lors de l’appel de la fonction de réception (figure 2.7 page suivante).

Les conventions suivantes sont donc appliquées pour l’état d’un lien. Un lien est dans l’état inutilisé lorsqu’il ne véhicule pas de données. Un lien entrant (i.e. sur lequel on fait une réception) est dans l’état bloqué lorsqu’une tâche attend des données sur ce lien et dans l’état communicant lorsque les données attendues circulent effectivement. Nous dirons de plus qu’un lien est dans l’état système lorsque des données ont été émises sur ce lien mais pas encore réceptionnées : cela permet de savoir quelles sont les tâches dont les données n’ont pas encore été reçues. Enfin un lien est dans l’état mort lorsque la tâche pouvant émettre sur ce lien l’est elle-même.

Les tableaux 2.11 et 2.12 page 119 récapitulent les différents états que peuvent prendre les tâches et les liens de communication.

Attributs associés aux objets simulés

Chacun de ces objets, et le graphe lui-même, est doté d’attributs permettant de connaître non seulement l’état du système mais également d’autres informations utiles pour l’évaluation des performances ou la compréhension de l’application. Les tableaux 2.13 page 120, 2.14 page 121 et 2.15 page 121 listent les attributs maintenus par le simulateur et le tableau 2.11 page 119 donne la liste des états que peuvent prendre une tâche ou un lien de communication ainsi que le code de couleurs qui sera utilisé dans les figures représentant le fonctionnement du

Calcul Début d’envoi Surcoût Début d’envoi Fin d’envoi Fin de réception Fin de réception Fin d’envoi réception Début de réception Début de Comm. Blocage

FIG. 2.7. – Lorsqu’un message est déjà présent quand une tâche demande à le

recevoir (à gauche) il est impossible de connaître le moment exact de son arrivée et donc le temps passé à communique effectivement. S’il n’est pas encore présent alors il est possible de reconstruire la communication.

simulateur. (Les noms utilisés sont ceux que l’on retrouve au cours de l’utilisation de l’environnement, aussi sont-ils en anglais.)

On notera que l’attribut Traffic d’un lien s’interprète différemment suivant l’état de celui-ci : s’il est dans l’étatOverheadle trafic est le volume de données qui doit encore être réceptionné alors que s’il est dans les étatsIdleouTalkingce

2.4. SUPPORT DES APPLICATIONS PVM Nom Signification Busy Actif Overhead Système Idle Inactif Talking Communicant Dead Mort

TAB. 2.11. – États donnés aux tâches par le simulateur de PVM.

Nom Signification Unused Inutilisé Overhead Système Idle Inactif Talking Communicant Dead Mort

TAB. 2.12. – États donnés aux liens par le simulateur de PVM.

trafic correspond au volume de données de la communication en cours.

Le simulateur est initialisé avec un graphe vide puisqu’aucune information sur la topologie de l’application n’est disponible. Celle-ci apparaîtra au fur et à mesure de l’avancement de la simulation.

Fonctionnement du simulateur

L’annexe A.2 page 200 décrit précisément le traitement effectué par le simu-lateur pour chacun des types d’événements qu’il connaît. Elle illustre également les changements d’états produits par ces événements.