Événements prédéfinis

Pour avoir la liste complète des événements système prédéfinis par perf, utilisables via l’option --event (qui s’abbrévie en -e) de toutes les commandes perf qui font un suivi d’événements, vous pouvez utiliser la commande perf list.

Mais comme vous allez rapidement le constater si vous essayez, cette liste est très longue (5933 lignes au moment où j’écris ce TP). Il est donc utile de connaître ses mécanismes de filtrage.

Tout d’abord, les événements sont triés en grandes catégories, que j’aurais personnellement tendance à regrouper encore en catégories de niveau supérieur :

• Avec perf list hw cache, vous pouvez afficher la liste des événements matériels génériques/abstraits. Ces événements sont mesurables sur à peu près tout matériel supporté par perf, et implémentés en utilisant les événements spécifiques à chaque matériel.
• Avec perf list sw tracepoint sdt, vous pouvez afficher la liste des événements logiciels, qui sont générés par le noyau Linux et certaines bibliothèques. Au niveau des sous-catégories…
  • Ceux libellés [Software event] et [Tool event] sont accessibles sur tout ordinateur équipé de perf sans configuration supplémentaire.
  • Ceux libellés [Tracepoint event] et [SDT event] nécessitent des privilèges de traçage (voir l’annexe installation pour plus d’informations sur ce point), qui ont été préconfigurés pour vous sur srv-calcul-ambulant.
    • Ceux libellés [SDT event] nécessitent également des préparatifs avant utilisation, que nous aborderons dans la partie sur perf probe.
• Avec perf list pmu, vous pouvez afficher la liste des événements que votre CPU sait compter via sa Performance Monitoring Unit (PMU). Ils sont très nombreux, particulièrement chez Intel, c’est la majeure partie de la sortie brute de perf list sans filtrage.
• Avec perf list metric metricgroup, vous pouvez afficher la liste des métriques et groupes de métriques. Mais curieusement, cette liste n’est pas hiérarchisée comme la sortie finale de perf list, ce qui la rend moins lisible. Je vous recommande donc plutôt d’utiliser perf list sans arguments ici, en sautant à la fin du texte avec la touche Fin de votre clavier.

Il est aussi possible d’effectuer une recherche au sein de la sortie de perf list, par exemple perf list float retournera tous les événements dont le nom ou la description contient le mot “float”.

Exercice : Quand on vectorise du code sans revoir sa politique d’allocation mémoire, on se retrouve fréquemment avec des problèmes de performances liés à des accès mémoire non alignés.

Contrairement à une croyance populaire tenace, les mauvaises performances observées ne proviennent pas du fait que le compilateur génère des instructions non optimisées pour les accès alignés comme movups. Sur les CPUs actuels, ces instructions ont des performances équivalentes à leurs cousines optimisées pour les accès alignés, qui sont donc plus ou moins obsolètes.

En réalité, le vrai problème est que dans cette configuration, les accès mémoire liés au calcul vectorisé, qui sont très larges, peuvent et vont souvent se retrouver à cheval sur deux lignes de cache, ce qui force le processeur à lire ou écrire deux lignes de cache au lieu d’une. Il en résulte une sur-utilisation des ressources mémoire, qui cause le ralentissement observé.

Dans la section “cache” de la sortie de perf list pmu, trouvez quels événements passer en paramètre à perf stat -e pour établir avec certitude si vous avez ou non affaire à ce problème.