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.