Autres options
Similarités et différences avec perf stat
Comme d’autres commandes perf
que nous avons vu précédemment, perf trace
supporte les options --delay
/-D
, --cpu
/-C
, --event
/-e
ainsi que la
surveillance d’un processus, thread ou utilisateur système spécifique, avec des
sémantiques similaires. Comme nous avons déjà abordé ces options dans
la partie sur perf stat
, nous ne reviendrons pas
dessus ici.
Contrairement aux commandes perf
que nous avons vu précédemment, l’option
--event
/-e
de perf trace
supporte des motifs négatifs tels que
-e '!futex,!clock_nanosleep'
. Ceux-ci permettent de suivre tous les appels
système à l’exception de ceux qu’on a listés.
Options de filtrage
De cette partie du TP, vous avez probablement compris le principal défi
auquel on fait face quand on utilise perf trace
: survivre à l’énorme flux
d’information qui en sort.
Sans surprise, cette commande possède donc une belle palette d’options pour sélectionner des événements particulièrement intéressants et n’afficher qu’eux. Quelques exemples :
--duration N.M
où N.M est un nombre de millisecondes, permet de n’afficher que les appels systèmes qui durent suffisamment longtemps. Cette option n’est pas utilisable quand on étudie des tracepoints, puisque ceux-ci ne sont que des points temporels sans notion de début et de fin.--failure
permet de n’afficher que les appels système qui ont échoué.--max-events=N
permet d’arrêter l’enregistrement après N événements.--switch-on <event>
et--switch-off <event>
permettent d’attendre qu’un certain événement soit survenu avant de démarrer/arrêter l’enregistrement.--filter
permet de n’afficher que des événements dont les paramètres vérifient certains prédicats logiques.
Clarifions un peu cette dernière option en prenant l’exemple d’un job
perf trace
qui fait un suivi des interruptions matérielles :
srun --pty \
perf trace -a -e irq:irq_handler_entry \
sleep 0.01
Sortie de perf trace
Comme vous pouvez le constater, même sur un enregistrement de 10 millisecondes
effectué sur un système au repos, la sortie est monopolisée par la gestion du
trafic réseau (IRQ 72), interruption très fréquente. Nous pouvons choisir
d’ignorer cette interruption matérielle avec le filtre --filter 'irq != 72'
,
et dans ce cas même un enregistrement de quelques secondes devient lisible.
srun --pty \
perf trace -a -e irq:irq_handler_entry --filter 'irq != 72' \
sleep 10
Sortie de perf trace
Vous trouverez plus de détail sur la syntaxe utilisée par --filter
dans
la section “Event filtering” de la documentation des trace events du noyau.
Suivis des défauts de page
Une option particulièrement intéressante de perf trace
est l’option
--pf
/-F
, qui permet d’analyser les défauts de page. Sous Linux, cette
interruption matérielle qui survient lorsqu’on tente d’accéder à une adresse
mémoire qui n’est pas associée à de la RAM physique est utilisée pour
toutes sortes de choses (swapping, allocation paresseuse de mémoire avec
gestion du NUMA par first touch), et ces astuces d’implémentation peuvent
parfois causer des problèmes de performance difficiles à comprendre. Il est donc
intéressant d’avoir un outil pour en faire le suivi.
Enregistrement des données
Il est aussi possible d’enregistrer les informations produites par perf trace
avec la commande perf trace record
puis de les analyser en différé avec
perf trace -i <fichier perf.data>
. Cela génère du trafic vers le support de
stockage sous-jacent, donc
les précautions discutées précédemment
demeurent valables.