\documentclass[a4paper]{report}

%\usepackage[top=2cm,bottom=3cm,left=3cm,right=3cm]{geometry}

\usepackage{pdfswitch}
\usepackage[latin1]{inputenc}
\usepackage[french]{babel}
\usepackage{alltt}
\usepackage{remark}
\usepackage{url}
\usepackage{xspace}
\usepackage{boxedminipage}


\def\linuxversion{2.6.10}

\DeclareRobustCommand{\FFxT}{F\kern-.1667em\lower.5ex\hbox{X}%
  \kern-.125emT\spacefactor1000}

\makeatletter
\DeclareRobustCommand{\FxT}{F\kern-.18em%
        %{\sbox\z@ x%
         %\vbox to\ht\z@{%
           \lower.5ex
           \hbox{\check@mathfonts%
                              \fontsize\sf@size\z@%
                              \math@fontsfalse\selectfont%
                              X}%
                          %\vss}%
        %}%
        \kern-.27em%
        T\spacefactor1000}
\makeatother

\title{FxT : manuel d'utilisation}

\author{Vincent Danjean}


% \newenvironment{etapes}{
%   \newcommand{\etape}[1]{\item \textbf{##1}}
%   \begin{enumerate}
%   }{
%   \end{enumerate}
% }
\newcounter{etapes}
\newenvironment{etapes}{
  \setcounter{etapes}{0}
  \newcommand{\etape}[1]{%
    \stepcounter{etapes}%
    \paragraph*{\arabic{etapes}.~##1}\hspace{0cm}%
    \bigskip%
  }
}

\newenvironment{options}{
  \newcommand{\option}[2]{\item[\code{##1}]~\\##2}
  \begin{description}
  }{
  \end{description}
}

\newcommand{\name}[1]{\textsc{#1}}
\newcommand{\code}[1]{\texttt{#1}}
\newenvironment{shell}{%
  \begin{alltt}%
  }{%
  \end{alltt}%
}

\newcommand{\note}[2][]{\par\smallskip\noindent\llap{\textbf{Note
      \ifthenelse{\equal{#1}{}}{}{(#1) }:} }#2\par\medskip}

\newcommand{\FXT}{\FxT\xspace}
\newcommand{\FKT}{\name{FKT}\xspace}
\newcommand{\FUT}{\name{FUT}\xspace}
\newcommand{\marcel}{\name{Marcel}\xspace}
\newcommand{\mad}{\name{Madeleine}\xspace}
\newcommand{\linux}{\name{Linux}\xspace}
\newcommand{\pmm}{\name{PM}$^2$\xspace}
\newcommand{\Paje}{\name{Pajé}\xspace}

\newcommand{\ie}{\emph{i.e.}\xspace}
\newcommand{\cf}{\emph{c.f.}\xspace}
\newcommand{\etc}{etc.\xspace}

\newcommand{\fktrecord}{\code{fkt\_record}\xspace}
\newcommand{\fxtprint}{\code{fxt\_print}\xspace}
\newcommand{\sigmund}{\code{sigmund}\xspace}

\begin{document}

\title{{
    \huge Fast Traces
    \\[1em]
    \Huge \FxT
    \\[1em]}
  Manuel d'utilisation}

\maketitle

\tableofcontents

\newpage

\chapter{Présentation}
Aujourd'hui, il est très difficile d'observer et de comprendre
finement les performances des applications reposant sur des supports
d'exécution multithreadés, en particulier lorsque la plateforme de
threads utilisée est complexe (ordonnancement multi-niveaux). \FXT
est un environnement permettant d'observer précisément le
comportement des applications multithreadées donnant ainsi accès à des
informations telles que le nombre de cycles consommés par une fonction
donnée ou l'ordonnancement exact des threads utilisés.

\FXT est composé de deux parties indépendantes (\FKT et \FUT) pour la
récolte de traces ainsi que d'outils pour l'analyse et l'exploitation
des traces récoltés.

\paragraph{\FKT}
\emph{Fast Kernel Trace} permet de récolter des événements relatifs au
noyau \linux grâce à un ensemble de macros insérées dans le code
source du noyau. Cette récolte est réalisée de manière très efficace
et non intrusive.

\paragraph{\FUT}
\emph{Fast User Trace}, très similaire à \FKT, permet de faire la même
chose (récolte d'événements) en mode utilisateur.

On peut les utiliser indépendemment l'un de l'autre.

\paragraph{Les outils} Un ensemble d'outils permettent de manipuler et
d'exploiter les traces générées par \FKT et \FUT. On peut ainsi les
parcourir mais aussi les fusionner pour générer une 
unique \emph{supertrace} décrivant pour chaque événement sur quel
processeur, dans quel thread noyau et dans quel thread utilisateur il
s'est exécuté. Il est alors possible de générer une trace au format du
logiciel \Paje afin de visualiser ces traces de manière graphique et
interactive.



\bigskip
Pour de plus amples informations sur le fonctionnement interne de \FKT et
\FUT, le lecteur se réfèrera à \cite{DanWac05TSI}.

\newpage
\chapter{Installation}
  
\section{Récupérer les logiciels}
\FXT est disponible sur le site
\url{http://savannah.nongnu.org/projects/fkt}. Pour bénéficier
pleinement de \FXT avec des programmes utilisant des processus légers
utilisateurs,
vous aurez également besoin d'une version récente de \marcel disponible
sur le site \url{http://runtime.bordeaux.inria.fr/marcel/}.
%Remarque~:
%\FXT pourrait également fonctionner avec d'autres bibliothèques de
%threads utilisateur, mais aucune autre que \pmm n'a pour l'instant été interfacée
%avec \FXT.

L'installation de FKT nécessite de patcher le noyau. L'installation de
FUT et de la libfxt ne nécessite pas de patcher le noyau.

\section{FKT}
\label{sec:install_fkt}
Les étapes nécessaires pour installer \FKT dans un noyau \linux sont
décrites ici. On supposera par la suite que les fichiers du projets
\FXT ont été rapatriées dans un répertoire appelé \code{FxT/}
ci-dessous.

\note{à ce jour, seule l'architecture \code{x86} contient les routines
assembleurs de \FXT. Un travail de portage serait nécessaire pour
utiliser \FXT sur d'autres architectures.}

\note[bis]{Pour une machine dédiée où un programme utilisateur
  n'utilisera pas plus de threads noyaux que de processeurs (par
  exemple, un programme utilisant la bibliothèque \marcel), \FXT n'est
  pas réellement nécessaire pour observer le comportement des
  threads.}


\begin{etapes}
  
  \etape{Récupérer les sources d'un noyau \linux}

  Le noyau original \linuxversion{} est parfait. Une version patchée
  devrait également convenir, au moins pour la partie générique. Les
  patches de recueil d'événements pourront ne pas s'appliquer
  directement~; il faudra alors les corriger manuellement.

  La partie générique devrait s'appliquer sur n'importe quel noyau 2.6
  récent, mais les patches de recueil d'événements doivent parfois
  être modifiés. Dans ce cas, vérifiez toujours qu'une nouvelle
  version de \FXT n'est pas disponible avec les patches adaptés à
  votre noyau.

  Le répertoire contenant les sources du noyau \linux sera appelé
  \code{linux/} par la suite.

  \etape{Installer la partie générique de \FKT}

  Placez-vous dans le répertoire contenant \FXT.
\begin{shell}
  cd FxT/
\end{shell}
 
  Modifiez \code{Makefile.config} pour indiquer où se situe votre
  répertoire contenant les sources du noyau \linux, ainsi que la
  version des patches à essayer (indiquez la version exacte de votre
  noyau si elle est disponible, la plus proche sinon).  Les versions
  de patches disponibles sont les numéros de version des répertoires
  \code{linux-patches-...} dans le répertoire de \FXT.

  Installez les fichiers génériques (indépendant de la version du
  noyau) à l'aide de la commande suivante~:
\begin{shell}
  make install-fkt
\end{shell}
  Ceci copiera les fichiers \FKT, \ie les fichiers
  \code{arch/i386/kernel/fkt\_header.S}, \code{include/linux/fkt.h},
  \code{kernel/fkt.c} et \code{kernel/fkt-mod.c}. Tous ces fichiers
  sont indépendants de la version du noyau.

  Il faut ensuite modifier (patcher) quelques fichiers du noyau. Cela
  s'effectue avec la commande~:
\begin{shell}
  make install-sys
\end{shell}
  Si le noyau utilisé correspond exactement à celui déclaré dans
  \code{Makefile.config} (même numéro de version, aucun patch
  supplémentaire), alors cette étape doit se dérouler sans
  aucun problème. Dans ce cas contraire, il sera peut-être nécessaire
  corriger l'application des patches en les appliquant à la main. La
  figure \ref{fig:patchsys} peut aider à ce travail dans ce cas.

  \begin{figure}[htbp]
    \begin{center}
      \begin{boxedminipage}{.9\linewidth}
        \newcommand{\fichier}[1]{\item[\textnormal{\code{#1}}]}
        \newcommand{\raison}[1]{~\\ #1}
        \begin{itemize}
          \fichier{arch/i386/config.in} %
          \fichier{arch/i386/Kconfig} %
          \fichier{arch/i386/defconfig}%
          \fichier{arch/i386/kernel/Makefile}%
          \fichier{kernel/Makefile} %
          \raison{ajoute \FKT au système de compilation. En cas de
            problème, l'application du patch est très simple à
            réaliser manuellement.
            % just added the compilation of fkt, it can be easily done
            % by hand if it didn't merge.
          }

          \fichier{include/linux/pagemap.h} %
          \fichier{mm/filemap.c} %
          \fichier{fs/read\_write.c} %
          \raison{ajoute quelques fonctions utilitaires. Pour les
            anciens noyaux 2.4, \code{sendfile} est également modifiée
            pour appeler \FKT comme il se doit. Facile à appliquer
            manuellement.
            % added helper functions, easy to apply by hand, but also
            % tinkered in sendfile functions to have fkt's called (not
            % needed in 2.6 kernels) Also removed the useless copy of
            % fkt pages.
          }

          \fichier{include/linux/mm.h}
          \fichier{include/linux/page-flags.h}
          \fichier{mm/page\_alloc.c} %
          \raison{définit un nouveau drapeau pour les pages \FKT
            afin d'avoir un compteur de référence non null si elle
            sont \code{Reserved}.
            % defined a new flag for FKT pages to see its usage
            % counter vary even if they are Reserved.
          }

          \fichier{include/linux/fs.h}
          \fichier{include/linux/buffer\_head.h} %
          \fichier{fs/buffer.c} %
          \raison{ajoute quelques fonctions utilitaires, facile à
            appliquer manuellement. Quelques prises de traces sont
            également insérées, mais elles ne sont utiles que pour le
            déboggage de l'écriture des traces \FKT.
            % added helper functions, easy to apply by hand. It also
            % adds some probes, but they are only useful for debugging
            % fkt flushing.
          }

          \fichier{kernel/sched.c} %
          \fichier{fs/exec.c} %
          \fichier{include/linux/sched.h} %
          \fichier{kernel/pid.c} %
          \raison{ajoute des prises de traces nécessaires aux
            outils d'analyse pour suivre les fonctions \code{fork()},
            \code{exec()}, \code{switch\_to()} et \code{wait4()}.
          % added probe for the analysis tool to follow fork()s,
          % exec()s, switch_to()s and wait4()s
          }

          \fichier{arch/i386/kernel/entry.S} %
          \raison{ajoute des prises de traces pour tous les appels
            systèmes ainsi que quelques appels systèmes pour
            enregistrer des événements sur demande des programmes
            utilisateurs. Ces modifications doivent être fusionnées en
            faisant bien attention en cas de problèmes.
            % added probes to every system call, and a few system
            % calls to be able to add probes to user programs.  As
            % long as user programs probes are not needed, the last
            % hunk failing is no hurt. But previous hunks should be
            % handled carefully if they didn't merge.
          }

          \fichier{include/asm-i386/unistd.h} %
          \raison{ajoute les appels systèmes cité au-dessus
            % just system calls adding, same remark as above.
          }

          \fichier{include/asm-i386/hw\_irq.h} %
          \raison{ajoute des prises de traces pour les IRQs. À traiter
            avec attention en cas de problèmes.
            % added probes to every irq. To be handled carefully if it
            % didn't merge.
          }

          \fichier{include/linux/interrupt.h} %
          \raison{ajoute une \code{softirq} pour \FKT. Facile à
            appliquer manuellement.
            % added a softirq for fkt, really easy to merge.
          }

          \fichier{kernel/timer.c} %
          \raison{
            ajoute des prises de traces pour nanosleep. Peut être
            ignoré en cas de problèmes.
            % added probes to nanosleep, can be skipped if it didn't
            % merge.
          }
          
        \end{itemize}
      \end{boxedminipage}
    \end{center}
    \caption{Résumé des modifications apportées aux sources}
    \label{fig:patchsys}
  \end{figure}

  \etape{Insertion de prises de traces supplémentaires (facultatif)}
  \label{sec:install_fkt_patches}

  Si l'on désire instrumenter plus en détail le noyau, il existe déjà
  des ensembles d'instrumentation prêtes à l'emploi. \emph{Cette étape
    est complètement facultative.} Il est inutile d'appliquer ces
  patches si les événements enregistrés ne sont pas intéressants pour
  vous.

  Ces ensembles d'instrumentation ne sont disponibles que pour le
  noyau 2.4.21 à l'heure actuel. Si vous utilisez un autre noyau, vous
  aurez probablement à gérer des conflits manuellement lors de
  l'application de ces patches.

  Pour appliquer ces ensembles d'instrumentation, il faut donc
  positionner \code{KERN\_VERSION} à 2.4.21 dans
  \code{Makefile.config}, puis utiliser une ou plusieurs des commandes
  suivantes~:

\begin{shell}
  make install-fs
\end{shell}
ajoute des prises de traces pour les opérations du système de
fichier~: \code{lseek}, \code{read}, \code{write}, \code{ext2\_getblk},
\code{ll\_rw\_blk}
%will add probes to file system operations: lseek, read, write, ext2_getblk,
%ll_rw_blk
\begin{shell}
  make install-net
\end{shell}
ajoute des prises de traces dans la pile TCP/IP. Différentes couches
peuvent être sélectionnées grâce au masque d'enregistrement (\cf
\ref{usage} à la page \pageref{usage})
%  will add probes to the whole tcp/ip stack. Different layers can then be
%selected or not according to the recording keymask (see README).
\begin{shell}
  make install-netdriver-3c59x or acenic or tulip
\end{shell}
ajoute des prises de traces dans le pilote de la carte réseau correspondante
%will add probes to the relevant network device driver.
\begin{shell}
  make install-scsigen
\end{shell}
ajoute des prises de traces dans le pilote SCSI generique et le
pilote CD SCSI
% will add probes to the generic scsi driver and scsi cd driver.

  \etape{Compilation du noyau}

  Une fois adapté, le noyau \linux doit être compilé en validant le
  support pour \FKT.

  Allez dans le répertoire \code{linux} et configurez votre noyau~:
\begin{shell}
  cd linux/
  make config \emph{(ou} make oldconfig \emph{ou} make xconfig\emph{)}
\end{shell}
Vous devez valider le support (éventuellement en module) pour \FKT
(\texttt{CONFIG\_FKT}). \texttt{CONFIG\_FKT\_TIME\_ONLY} permet de
réduire la taille des traces en n'enregistrant pas les paramètres,
mais ce mode est à réserver à ceux qui veulent profiler le noyau (et
non pas profiler des applications en espace utilisateur).

Il faut ensuite compiler son noyau et l'installer. Par exemple, avec :
\begin{shell}
  make dep \&\& make clean \&\& make bzImage
  make install
\end{shell}

  \etape{Pour les utilisateurs}

  Il est également nécessaire de créer le fichier périphérique
  \code{/dev/fkt}, par exemple avec la commande:
\begin{shell}
  mknod /dev/fkt b 60 0    
\end{shell}

  Pour les personnes ayant choisit de compiler \FKT en module, elles
  pourront ajouter à leur fichier \code{/etc/modules.conf} la ligne :
\begin{shell}
  alias block-major-60 fkt-mod
\end{shell}
  de sorte que le module puisse être chargé automatiquement.

  Pour restreindre l'utilisation de \FXT aux utilisateurs d'un certain
  groupe \code{group}, il est possible de modifier les permissions du
  fichier \code{/dev/fkt} :
\begin{shell}
  chgrp somegroup /dev/fkt
  chmod 440 /dev/fkt
\end{shell}

\end{etapes}

\section{FUT et les utilitaires}
  \FUT et les utilitaires de \FXT ont besoin de quelques
  bibliothèques externes. Vous devrez probablement installer, si ce
  n'est pas déjà fait, le package contenant la bibliothèque
  \code{libbfd} (probablement le package \code{binutils-dev}).

  Il suffit ensuite d'utiliser le classique
\begin{shell}
  ./configure
  make 
  make install
\end{shell}
  Cela construit tous les fichiers nécessaires à l'utilisation de \FUT
  ainsi que les utilitaires qui permettront de récolter et analyser
  les traces.

  Pour plus de facilité d'utilisation, vous pourrez installer les
  programmes dans un répertoire de votre \code{PATH} ainsi que les
  bibliothèques (fichiers \code{libfxt.*}) dans un répertoire lu par
  le linker (\code{/usr/local/lib}, \code{/usr/lib}, \ldots) ou
  présent dans votre variable d'environnement \code{LD\_LIBRARY\_PATH}.

\chapter{Prise de traces}
\FXT permet d'obtenir des traces précises du déroulement de
l'exécution de flots d'exécution. Ce chapitre explique brièvement
comment placer des mesures dans les application et comment obtenir les
traces.

\section{FKT}

\FKT permet d'observer le comportement du noyau. Il y a deux objectifs
à cela : observer le fonctionnement du noyau lui-même et obtenir des
traces utiles pour l'observation de programmes en espace utilisateur.

\subsection{Instrumentation du noyau}
L'installation des patch de \FKT (\cf partie \ref{sec:install_fkt})
dans les sources du noyau \linux insère les prises de traces nécessaires à
l'observation des programmes en espace utilisateur. À savoir, des
traces sont récoltées pour
\begin{itemize}
\item chaque changement de contexte ;
\item chaque création/destruction d'un flot d'exécution (processus ou
  thread noyau) ;
\item chaque changement d'espace virtuel (\code{execve}) pour
  enregistrer le nom des nouveaux processus ;
\item chaque transition noyau/utilisateur (appels systèmes,
  interruption matérielle, \etc).
\end{itemize}
Il est possible d'instrumenter plus finement le noyau. Quelques
patches sont fournis avec la distribution (\cf partie
\ref{sec:install_fkt_patches}), mais pour des besoins particuliers il
est parfaitement possible d'instrumenter soit-même le noyau en
utilisant les mêmes techniques que celles développées ci-après pour
les programmes en espace utilisateur. 

\subsection{Récolte des traces noyaux avec \fktrecord}
Pour enregistrer les traces récoltées par le noyau, l'utilitaire
\fktrecord est fourni. Il s'utilise de la manière suivante :
\begin{shell}
   fkt_record [options..] [--] [program p1 p2 p3 ...]
\end{shell}
Si le programme n'est pas donnée, \fktrecord démarre un fils qui se
contentera de consommer du CPU.

Les options possibles sont :
\begin{options}
  \option{-f output\_file}{sauve la trace dans le fichier
    \code{output\_file}. Si cette option n'est pas fournie, \fktrecord
    utilise le contenu de la variable d'environnement
    \code{TRACE\_FILE} et en cas d'absence il crée le fichier
    \emph{trace\_file}}
%
  \option{-k mask}{masque à utiliser pour la récolte d'événements. Par
    défaut, \fktrecord utilise la valeur 1 qui enregistre
    uniquement\footnote{Les changements de contexte sont
      \emph{toujours} enregistrés par \FKT, quelque soit le masque
      actif.} les transitions noyau/utilisateur (appels systèmes, irq,
    \etc)}
%
  \option{-S System.map}{si ce fichier est indiqué, son contenu est
    fusionné avec celui de \code{/proc/kallsyms} ou
    \code{/proc/ksyms} en vérifiant qu'il n'y a pas d'incohérence. En
    effet, les symboles du noyau sont enregistrés au début de la trace
    pour permettre l'analyse de la trace par la suite}
%
  \option{-s size}{taille des blocks. Par défaut, la taille des blocks
    du système de fichier est utilisée. Option à réserver aux
    experts.}
%
  \option{-p pow}{alloue $2^{pow}$ page mémoire pour contenir les
    traces avant écriture sur disque. Par défaut, 7 pages sont
    allouées. Il peut être nécessaire d'augmenter cette quantité si on
    enregistre de grosses quantités de traces en un très bref
    instant.}
%
  \option{-n}{aucun programme n'est lancé. La prise de trace
    s'arrêtera lorsque l'utilisateur interrompra (avec \texttt{\^~C}
    par exemple) le programme \fktrecord.}
\end{options}

\section{FUT et \pmm}
\FXT fournit des outils pour permettre l'instrumentation des
programmes utilisateurs, mais ils ne sont pas aisés à manipuler
directement. C'est pourquoi il est conseiller d'utiliser une
bibliothèque de processus léger intégrant déjà le support pour \FXT.
\pmm et sa bibliothèque de thread \marcel sont parfaitement intégrés
avec \FXT.

\subsection{Instrumentation des programmes}
Les traces utilisateurs proviennent de l'instrumentation des
programmes. \pmm propose plusieurs manière de le faire.
\begin{description}
\item[Instrumentation manuelle~:] un ensemble de macro est disponible
  pour prendre des traces automatiquement. Il est possible
  d'enregistrer tout types d'événements. Les macros nécessitent un
  code unique (qui identifie le type d'événement) et acceptent un
  nombre variable de paramètres, actuellement de 0 à 5, mais ce nombre
  peut être augmenté jusqu'à 254 sans difficultés. L'ensemble de ces
  macros est disponible dans le fichier \code{fut.h}.
\item[Instrumentation automatique~:] en utilisant l'option
  \code{-finstrument-function} de \code{gcc}, les fonctions des
  fichiers objets compilés ainsi auront automatiquement une trace
  générée à l'entrée et une à la sortie.
\end{description}

En outre, deux fonctions sont à utiliser dans le programme principal~:
\begin{shell}
  void profile_activate(int FUT_ENABLE, int fut_mask, int fkt_mask);
  void profile_stop();
\end{shell}
La première permet de démarrer et choisir les masques d'événements
pour FKT et FUT, la seconde permet de stopper les traces et de les
sauver sur le disque.
\pmm sauve les traces dans les fichiers
\code{/tmp/prof\_file\_user|kernel\_\emph{login}[\_\emph{node}]}.

\note{le n\oe ud n'est sauvé dans le fichier que si \pmm est utilisé
  en réseau (\ie avec \mad).}
\note[bis]{\pmm active lui-même FKT si nécessaire. Il n'y a alors pas
  besoin d'utiliser le programme \fktrecord.}

\subsection{Récoltes des traces avec \pmm}

Pour récolter les traces avec un programme \pmm, il suffit de le
lancer avec une \emph{flavor} contenant le support \FXT. Pour cela, au
moment du choix des options de la \emph{flavor}, il faut :
\begin{itemize}
\item inclure le module \code{profile}
\item prendre l'option \code{FKT} du module \code{profile} si l'on
  veut utiliser \FKT en plus de \FUT
\item choisir l'option \code{gcc-instrument} pour chacun des modules
  \pmm que l'on veut instrumenter automatiquement avec \code{gcc}
\item choisir l'option \code{profiling} pour chacun des modules \pmm
  afin d'utiliser les instrumentations manuelles déjà présentes
\end{itemize}
L'exécution du programme ainsi compilé générera automatiquement les
traces (à condition de bien démarrer et arrêter la prise de traces
avec \code{profile\_activate} et \code{profile\_stop}.

\chapter{Exploitation des traces}
Une fois les traces recueillies, il est nécessaire de les analyser.
\FUT fonctionnant sur deux architectures différentes (64bits et
32bits), il est nécessaire de prendre en compte cet aspect pour
utiliser les programmes : le format des traces binaires récoltées ne
sera pas compatible.

\section{Analyse des traces récoltées}
Dans un premier temps, l'utilitaire \fxtprint permet de convertir une
trace binaire récoltées en une trace au format texte.
\begin{shell}
  fxt_print [-f trace_file] [-d] [-o]
\end{shell}
Les options disponibles sont les suivantes :
\begin{options}
  \option{-f trace\_file}{lit la trace dans le fichier
    \code{trace\_file}. Si cette option n'est pas fournie, \fxtprint
    utilise le contenu de la variable d'environnement
    \code{TRACE\_FILE} et en cas d'absence il lit le fichier
    \emph{trace\_file}}
%
  \option{-d}{permet de demander à \fxtprint de ne pas essayer de nommé
    les événements et les fonctions, mais d'afficher les identifiants
    (codes) tels qu'ils sont stockés dans la trace (utile surtout pour
    le débogage pour inspecter précisément le contenu d'une trace)}
%
  \option{-o}{permet de demander à \fxtprint d'afficher non plus la
    date des événements, mais le temps écoulé depuis le premier
    événement (les dates sont décalées de sortes que le premier
    événement survienne à la date 0)}
\end{options}
Cette conversion de la trace au format binaire en une trace ASCII doit
être faite sur la même architecture que la machine qui a récolté les
traces.


\section{Visualisation graphique}

Les traces en ASCII peuvent ensuite être visualisées. Pour cela, elles
doivent être mises en forme, éventuellement fusionnées (si on utilise
\FUT et \FKT), triées (les événements ne sont pas nécessairement
enregistrés dans le bon ordre), \etc C'est le programme utilitaire
\code{sigmund} qui est responsable de cela :
\begin{shell}
  fxt_print [--user user_trace_file] [--kernel kernel_trace_file] [--paje]
\end{shell}
\begin{options}
  \option{--user user\_trace\_file}{indique une trace utilisateur
    (\FUT) à traiter. Cette trace doit avoir déjà été convertie en
    ASCII avec \fxtprint }
%
  \option{--kernel kernel\_trace\_file}{indique une trace noyau (\FKT)
    à traiter. Cette trace doit avoir déjà été convertie en ASCII avec
    \fxtprint }
%
  \option{--paje}{génère une trace complète au format \Paje}
\end{options}

\sigmund trie les traces, les fusionne si on lui en fourni
deux, insère les événements d'ordonnancement manquants (prise de la
main au début des traces et déordonnancement des threads à la fin),
insère des pseudo-événements (création et destruction des
threads/LWPs/processeurs/\ldots), \etc Pour l'instant, il n'est pas
possible de choisir un sous-ensemble d'actions à effectuer. La
prochaine version de \sigmund le permettra.

Enfin, par défaut, \sigmund affiche cette super-trace complète. Avec
l'option \code{--paje}, une étape supplémentaire est générée de façon
à convertir cette super-trace en un format de trace acceptable par le
logiciel de visualisation graphique \Paje. 

\begin{figure}[phtb]
  \centering \hspace*{-2cm}\includegraphics{paje}
  \caption{Visualisation d'une trace avec \name{Pajé}}
  \label{fig:paje}
\end{figure}

Sur la figure~\ref{fig:paje}, on peut observer un extrait du
déroulement d'un programme multithreadé. Sur cet exemple, la machine a
quatre processeurs physiques (il s'agit d'un biprocesseur \name{Xeon
  SMT}).  L'application observée (nommée \texttt{traces}) utilise deux
threads noyaux pour ordonnancer ses quatre threads utilisateurs~:
trois threads sont destinés aux calculs d'un produit de matrice
(nommés \texttt{calcul1}, \texttt{calcul2 } et \texttt{calcul3}) et le
quatrième assure des communications.  Les informations sont
représentées dans trois zones matérialisant les points de vue thread
utilisateur, thread noyau et processeur\footnote{Si tous les threads
  noyaux et tous les processeurs du système sont représentés, seuls
  les threads utilisateurs de l'application espionnée sont
  observables.}.  Détaillons ces différentes vues~:
\begin{description}

\item[Informations sur chaque thread noyau~:]~
  \begin{enumerate}
  \item identité du processeur physique utilisé (lorsque ce thread est
  ordonnancé par le système d'exploitation)~;
\item identité du thread utilisateur qu'il ordonnance (si le thread
  noyau exécute l'application observée)~;
  \end{enumerate}

\item[Informations sur chaque processeur~:]~
  \begin{enumerate}
  \item identité du thread noyau exécuté~;
  \item identité du thread utilisateur exécuté (s'il s'agit de
    l'exécution de l'application observée)~;
  \end{enumerate}

\item[Informations sur chaque thread utilisateur~:]~
  \begin{enumerate}
  \item identité du thread noyau propulseur (lorsqu'il est sélectionné
    par l'ordonnanceur de l'application)~;
  \item identité du processeur physique lorsqu'il est réellement
    exécuté (il doit alors être aussi ordonnancé par un thread noyau)~;
  \item emboîtement des appels de fonction et des événements tracés
    dans l'application.
  \end{enumerate}
\end{description}
  

\chapter{Perspectives}
Le programme \fxtprint et la bibliothèque \code{libfxt} vont être
étendus pour permettre de lire des fichiers de traces produits sur une
machine d'architecture différente.

Le programme \sigmund va également être étendu afin de permettre de
mieux manipuler les flots de traces : filtrages en fonction du type
des événements, de dates, de l'émetteur des événements, \etc. Cela
permettra de choisir facilement et précisément les informations que
l'on souhaite visualiser dans le logiciel \Paje.

Les outils pour instrumenter les applications seront étoffées afin de
permettre de décrire facilement, rapidement et de manière générique
quelle représentation on souhaite dans \Paje pour chaque type
d'événement de l'application.

\bibliographystyle{fr-plain}
\bibliography{FxT}
\addcontentsline{toc}{chapter}{\refname}
\nocite{*}
\end{document}

% LocalWords:  patches patch
