Premier contact
Pour illustrer la première fonction de perf script
(afficher, sous une forme
lisible par des êtres humains, le contenu d’un fichier perf.data
), nous allons
commencer doucement en analysant le fichier perf.data
produit durant l’étude
de perf annotate
:
cd ~/tp-perf \
&& srun make -j$(nproc) \
&& srun --pty perf record ./scale.bin 2048 10000000 \
&& perf script
Sortie de perf script
Pour chaque échantillon enregistré, perf script
nous affiche…
- Le nom du programme qui s’exécutait à ce moment-là
- L’identifiant de processus (PID) associé
- Le moment où l’enregistrement a été effectué, en secondes depuis le démarrage du système.
- L’événement étudié (par défault le passage des cycles processeur) et le nombre de ces événements qui sont survenus depuis le dernier échantillon.
- Le pointeur d’instruction auquel se trouvait le programme au moment où la
mesure a été effectuée, suivi d’une analyse de ce dernier en termes…
- Du symbole (= la fonction) dans lequel on se trouvait, et du décalage en octets de l’instruction active par rapport à ce symbole.
- Du fichier binaire dont est originaire ce symbole.
Ce n’est qu’un sous-ensemble des données qui peuvent être affichées. Avec
l’option --fields
/-F
, on peut demander l’affichage d’autres informations
comme le numéro de thread (tid
), le numéro de CPU (cpu
), ou une estimation
de la ligne de code source associée basée sur les symboles de déboguage
(srcline
). Consultez perf help script
pour plus de détails. Mais pour cette
première approche, nous allons nous contenter des informations affichées par
défaut.
On constate que durant les premières millisecondes enregistrées, on observe
l’activité de perf
lui-même, et pas encore celle du programme enregistré. Il
sera lancé par un appel système exec
une fois la configuration de
perf record
terminée.
Durant cette brève phase, on note un petit couac de mesure (pointeur
d’instruction à l’addresse 0, ce qui est peu plausible), ainsi que ce qui ressemble
à une première calibration du nombre de cycles processeur que perf
doit
compter entre chaque échantillon pour atteindre la fréquence d’échantillonnage
souhaitée (4 kHz pour l’événement cycles
par défaut dans perf
5.3).
Puis l’on entre dans l’exécution du programme scale.bin
proprement dit, où
l’on voit les données brutes qui ont été traitées par perf annotate
pour
produire du code source annoté. On note au passage que la calibration du nombre
de cycles n’est pas complètement terminée à ce stade, et va se raffiner
progressivement au début de l’exécution du programme.
Une première utilité de perf script
est d’examiner ces données brutes
lorsqu’un outil de plus haut niveau, comme perf annotate
ou perf report
,
produit des résultats qui semblent incohérents.
Exercice : Répétez cette analyse avec des données contenant des graphes d’appels DWARF, comme celles produites dans l’étude de l’exemple TPhysics. Notez que cette visualisation se prête plus facilement à l’étude de piles d’appels brisées, dans l’optique de signaler un bug par exemple.