Le 11 août 2026, Ian Rogers, de Google, a publié sur la liste de diffusion du noyau une série de correctifs qui donne à l'unité de surveillance de performance du bus Broadcom AXI des cartes Raspberry Pi un vrai pilote perf intégré à Linux. Jusqu'ici, atteindre ces compteurs supposait un pilote hors arbre bricolant des nœuds DebugFS maison. Le nouveau pilote expose les événements uncore de la manière ordinaire, sous /sys/bus/event_source/devices/rpi_axi_pmu/, ce qui veut dire que perf stat et perf record fonctionnent dessus sans outillage spécifique. Sur une carte où le goulot d'étranglement est en général le bus plutôt que les cœurs, c'est précisément la mesure qui manquait.
The short answer
Ian Rogers, de Google, a publié le 11 août 2026 une série de correctifs ajoutant un pilote Linux intégré pour l unité de surveillance de performance du bus Broadcom AXI sur les Raspberry Pi 1 à 4. Il s intègre au sous-système perf standard, expose les événements uncore sous /sys/bus/event_source/devices/rpi_axi_pmu/ et prend en charge le branchement à chaud des processeurs. Les solutions existantes étaient hors arbre et passaient par des nœuds DebugFS maison.
Quiconque a profilé un Raspberry Pi s'est heurté au même mur. Les compteurs processeur disent que les cœurs calent sur la mémoire. Et ensuite ? Il n'a jamais existé de moyen pris en charge de regarder l'autre côté de ce blocage, parce que le matériel capable de vous répondre était planqué derrière un pilote hors arbre et une pile de fichiers DebugFS maison.
Ian Rogers, de Google, a publié le 11 août 2026 des correctifs sur la liste de diffusion du noyau pour corriger cela. La série ajoute un pilote compatible avec l'amont pour les compteurs de performance qu'expose le bus Broadcom AXI, avec intégration au sous-système perf standard de Linux, publication des événements uncore sous /sys/bus/event_source/devices/rpi_axi_pmu/ et prise en charge du branchement à chaud des processeurs.
Ce que ces compteurs voient et que les vôtres ne voient pas
AXI est le protocole d'interconnexion ARM. Sur un SoC Raspberry Pi, c'est la route qu'emprunte chaque bloc pour atteindre la mémoire : les cœurs du processeur, le GPU, le décodeur vidéo, l'interface caméra, le moteur d'affichage. Une unité de surveillance de performance posée sur ce bus compte ce qui le traverse.
C'est un point de vue fondamentalement différent de celui d'un PMU de cœur. Vos compteurs processeur sont à l'intérieur du cœur et peuvent vous dire qu'un chargement a manqué et que le pipeline a calé. Ils ne peuvent pas vous dire s'il a calé parce que votre jeu de travail est trop grand, ou parce qu'un décodage vidéo consommait l'essentiel de la bande passante disponible à cet instant. Ces deux situations produisent des symptômes identiques au niveau du cœur et appellent des correctifs opposés.
Sur un Pi en particulier, la distinction n'a rien d'académique. Ce sont des cartes à bande passante mémoire modeste, partagée par beaucoup de blocs gourmands. Le goulot d'étranglement est bien plus souvent sur le bus que dans les cœurs, et jusqu'ici le bus était justement la partie qu'on ne pouvait pas mesurer.
Hors arbre ne veut pas dire disponible
Il existe une version de cette histoire où rien ne change, puisque des pilotes pour ces compteurs existaient déjà. Cette version est fausse, et la raison mérite d'être précise.
Un pilote hors arbre est du code que vous portez. Il doit être recompilé pour chaque noyau vers lequel vous migrez. Il casse quand une API interne bouge, ce qui arrive constamment puisque le noyau n'offre aucune garantie de stabilité à cet endroit. Il ne peut être supposé présent par quoi que ce soit d'autre, donc chaque script qui l'utilise a besoin d'un plan de repli. Et dans le cas présent, il exposait ses compteurs par des nœuds DebugFS maison, ce qui veut dire que le consommateur aussi était du code à vous : analyser des fichiers dans un format sur mesure au lieu d'interroger perf.
L'amont change la forme de tout cela. Un pilote dans l'arbre est compilé par les noyaux de distribution, est porté par quiconque remanie l'API en dessous, et parle une interface que tous les outils de profilage du système comprennent déjà. perf list énumère les événements. perf stat les compte. Rien de sur mesure n'intervient.
Le travail sur le Pi 5 est celui à surveiller
Les correctifs publiés couvrent les BCM2835 à BCM2711, soit les Raspberry Pi 1 à 4. Un travail distinct est en cours pour le BCM2712 du Raspberry Pi 5, et son périmètre est nettement plus large : surveillance des liens PCIe vers le pont sud RP1, du décodeur HEVC, du moteur d'affichage et de l'interconnexion L3 du DSU.
Cette liste est plus intéressante qu'elle n'en a l'air. Sur un Pi 5, le pont sud RP1 est là où vivent réellement l'USB, l'Ethernet et l'essentiel des entrées-sorties de la carte, atteints par PCIe. Quiconque a cherché pourquoi un Pi 5 en rôle de NAS ou de service réseau chargé ne tient pas ce que les caractéristiques laissent espérer devinait à propos de ce lien. Des compteurs dessus transforment la supposition en mesure. La surveillance de l'interconnexion L3, de même, est le moyen de distinguer un problème de cache d'un problème de bande passante sur une grappe de quatre cœurs.
Comment s'en servir le moment venu
Ce sont des compteurs à l'échelle du système rattachés à un bus, pas à un processus, donc le mode d'emploi diffère de vos habitudes. Comptez avec -a et délimitez par le temps plutôt que par la tâche.
Lancez votre charge, comptez sur tout le système pendant sa durée, et comparez les chiffres du bus à une mesure de référence prise machine au repos. L'attribution par processus n'a pas de sens ici, parce que le bus ne sait pas quelle tâche a émis une transaction, et la demander produira soit une erreur, soit un résultat trompeur.
La question pratique à laquelle cela répond, pour qui déploie ces cartes en production plutôt que sur un bureau, est de savoir si une unité qui ne suit pas est limitée par le processeur ou par la bande passante. Ces deux cas appellent des réponses différentes. L'une se règle par du meilleur code ou un cœur plus rapide, l'autre en déplaçant du travail hors de la carte ou en réduisant ce qui se dispute la mémoire. Se tromper coûte cher au-delà d'un seul appareil, et jusqu'ici la réponse honnête sur un Pi était qu'on ne pouvait pas trancher sans un pilote hors arbre et un week-end.
Si vous voulez provoquer volontairement la pression pendant que vous mesurez, l'interface debugfs pour diriger la pression mémoire sur un système Linux que nous avons examinée récemment se marie naturellement avec ce genre de travail sur compteurs.
Sources et pour aller plus loin
- Raspberry Pi AXI PMU Driver Under Review For The Mainline Linux Kernel, Phoronix, 11 août 2026
- La série de correctifs sur la liste de diffusion du noyau Linux, Ian Rogers, 11 août 2026
- perf Examples, le point d'entrée classique sur l'usage de perf
- Documentation des perf events du noyau Linux
Questions fréquentes
Qu'est-ce qu'un PMU AXI et en quoi diffère-t-il des compteurs de performance processeur que j'ai déjà ?
AXI est le protocole de bus ARM qui relie les cœurs du processeur à la mémoire et à tous les autres blocs de la puce. Un PMU posé sur ce bus compte le trafic qui le traverse : lectures, écritures, transactions en attente, blocages en attente de réponse. Vos compteurs processeur vivent à l'intérieur du cœur et peuvent vous dire qu'un chargement a manqué le cache et que le cœur a calé. Ils ne peuvent pas vous dire pourquoi, parce que la réponse se trouve en général de l'autre côté du bus. Des compteurs uncore comme ceux-ci permettent de distinguer une charge réellement gourmande en mémoire d'une charge affamée parce qu'autre chose, un pipeline caméra ou un décodeur vidéo, sature le même chemin.
Pourquoi l'intégration en amont compte-t-elle si des pilotes hors arbre existent déjà ?
Parce que hors arbre veut dire que c'est vous qui l'entretenez. Un pilote qui vit en dehors de l'arbre du noyau doit être recompilé pour chaque noyau vers lequel vous montez, casse silencieusement quand une API interne bouge, et ne peut être supposé présent par aucun outil ni script que vous écrivez. Cela signifie aussi une interface sur mesure : les pilotes existants exposent les compteurs par des nœuds DebugFS maison, donc tout ce qui les lit est du code que vous avez écrit plutôt que perf. Arriver en amont transforme les compteurs en une source d'événements standard que `perf list` énumère et que `perf stat` lit, sur n'importe quel noyau de distribution, sans étape de compilation. C'est la différence entre une capacité que l'on peut démontrer et une capacité que l'on peut déployer.
Quelles cartes sont couvertes aujourd'hui ?
Les correctifs publiés visent les Broadcom BCM2835 à BCM2711, soit les Raspberry Pi 1 à Raspberry Pi 4. Le Raspberry Pi 5 et son BCM2712 font l'objet d'un travail distinct dont le périmètre est plus large : surveillance des liens PCIe vers le pont sud RP1, du décodeur HEVC, du moteur d'affichage et de l'interconnexion L3 du DSU. Cet ensemble Pi 5 est sans doute le plus intéressant, parce que le pont sud RP1 est là où vivent réellement l'USB, l'Ethernet et l'essentiel des entrées-sorties de cette carte, et que la visibilité sur le lien PCIe est exactement ce qu'on veut quand un Pi 5 fait du stockage ou du réseau.
Comment s'en servir une fois intégré ?
Comme n'importe quel PMU uncore. `perf list` affichera les événements rpi_axi_pmu une fois le pilote chargé, et on les adresse avec la syntaxe habituelle `pmu/événement/`, par exemple `perf stat -a -e rpi_axi_pmu/un_evenement/ -- votre_charge`. Le `-a` compte : ce sont des compteurs à l'échelle du système rattachés à un bus, pas à une tâche, donc un comptage par processus n'a pas de sens pour eux. Vous mesurez ce que tout le SoC fait subir au bus pendant une fenêtre, ce qui est le bon cadre pour les questions auxquelles ces compteurs répondent.
Est-ce utile en dehors des projets de loisir ?
Oui, et sans doute davantage. Les cartes Raspberry Pi font beaucoup de travail de production peu spectaculaire : passerelles en périphérie, affichages de bornes, nœuds caméra, petits automates, bancs de test. Ces déploiements atteignent les limites du bus et de la mémoire bien avant celles du processeur, et la réponse habituelle consiste à deviner, à mettre une carte plus rapide et à espérer. Des compteurs au niveau du bus remplacent cette supposition par un chiffre. Si vous construisez des produits sur ces cartes, pouvoir répondre si une unité est limitée par le processeur ou par la bande passante, avec l'outillage standard sur un noyau standard, change la façon dont vous dimensionnez le matériel.