Le retour des frame pointers

Le site de Brendan : pour commencer

• La page d’accueil du blog de Brendan Gregg couvre divers sujets comme les performances système, les outils BPF et les performances Linux.
• Parmi les billets récents figurent le retour des frame pointers, un documentaire sur eBPF, ou encore l’idée que les outils d’observabilité eBPF ne sont pas des outils de sécurité.
• Le blog partage aussi, en plus de contenus techniques, plusieurs conférences et présentations auxquelles Brendan a participé.

Le retour des frame pointers

• Sur les systèmes sans frame pointers, le traçage de pile s’arrête à la couche libc, ce qui fait disparaître les frames de l’application.
• Fedora et Ubuntu ont résolu ce problème en publiant des versions où libc est compilée avec les frame pointers activés par défaut.
• Les frame pointers sont utilisés par des profileurs et débogueurs externes, et visualisés via des flame graphs.

Qu’est-ce qu’un frame pointer ?

• Selon le document ABI x86-64, le registre CPU %rbp peut être utilisé comme « base pointer » de la stack frame.
• Cette technique est largement utilisée pour le traçage de pile, notamment par Linux perf et eBPF.

2004 : suppression des frame pointers

• En 2004, le développeur gcc Roger Sayle a mené un changement visant à arrêter la génération des frame pointers.
• Ce changement a apporté un gain de performance, mais avec l’arrivée d’eBPF, certains débogueurs/profileurs rencontrent aujourd’hui des problèmes à cause de cela.

2005-2023 : l’hiver des profileurs cassés

• La suppression des frame pointers a aussi été appliquée à x86-64, mais cette architecture disposant de davantage de registres, le bénéfice y était limité.
• En conséquence, de nombreux débogueurs/profileurs ont cessé de fonctionner correctement.

2014 : Java in Flames

• En rejoignant Netflix, il a constaté que l’absence de support des frame pointers dans Java cassait toutes les stacks applicatives.
• Pour résoudre ce problème, il a développé un correctif pour le compilateur JVM c2.

2015-2020 : surcharge

• Le surcoût de performance lié à l’ajout des frame pointers partout est généralement inférieur à 1 %.
• Sur certains microbenchmarks, ce surcoût peut atteindre 10 %.

2022 : tentative upstream

• Cela suggère que de grandes entreprises comme Google, Meta et Netflix avaient déjà activé les frame pointers partout.
• Plusieurs difficultés subsistent toutefois pour faire de ce changement une valeur par défaut profitable à tous.

2023, 2024 : les frame pointers dans Fedora et Ubuntu

• Fedora a accepté une proposition visant à réactiver les frame pointers.
• Ubuntu a également activé les frame pointers par défaut dans la version 24.04 LTS.

Après 2034 : au-delà des frame pointers

• Il existe de nombreuses façons de tracer la stack : LBR, BTS, AET, DWARF, eBPF stack walking, ORC, SFrames, shadow stacks, etc.
• À l’avenir, SFrames ou les shadow stacks pourraient être utilisées pour tous les traçages de pile.

Conclusion

• Le retour des frame pointers rend les flame graphs CPU plus pertinents, fait fonctionner pour la première fois les flame graphs Off-CPU et ouvre d’autres nouvelles possibilités.
• C’est aussi une victoire pour les profileurs continus, qui n’auront plus à convaincre leurs clients de modifier l’OS pour fonctionner pleinement.

L’avis de GN⁺

• Le retour des frame pointers semble devoir apporter une aide majeure à l’analyse des performances système et au débogage. C’est un outil essentiel pour diagnostiquer les problèmes et optimiser les performances, en particulier dans les systèmes logiciels complexes.
• Ce changement montre l’importance de la collaboration et des contributions dans la communauté open source. Les décisions de Fedora et d’Ubuntu pourraient influencer d’autres distributions, entraînant une évolution positive de tout l’écosystème Linux.
• Réintroduire les frame pointers revient à trouver un équilibre entre baisse de performance et facilité de débogage. Cette décision peut être mieux comprise grâce à des tests et analyses de performance en conditions réelles d’exploitation.
• Pour les utilisateurs ayant un bagage technique, cette évolution peut être intéressante et fournit des informations utiles aux développeurs ou administrateurs système soucieux des performances.
• S’il existe d’autres technologies ou outils offrant des fonctions similaires aux frame pointers, on peut par exemple utiliser des profileurs matériels comme Intel VTune Profiler ou AMD uProf. Ces outils permettent l’analyse de performance même sans frame pointers.

[GN⁺]

Commentaires Hacker News

• Souvenir de l’époque où l’omission du pointeur de trame de pile a commencé à se généraliser au début des années 2000
  • L’auteur étudiait alors l’informatique, et l’ordinateur qu’il utilisait était ancien et peu performant.
  • Comme le débogage devenait difficile, il a commencé à utiliser Python pour éviter ces problèmes de débogage.
• Efforts de la distribution Fedora pour conserver les pointeurs de trame de pile
  • Il existait la croyance erronée que les pointeurs de trame de pile entraînaient une forte surcharge, alors qu’en réalité elle est inférieure à 1 %.
• Le fait qu’Apple ait toujours gardé des traces de pile exploitables sur l’architecture ARM
  • Certaines fonctions peuvent ne pas créer d’enregistrement de trame, mais les traces de pile restent utiles même sans informations de débogage.
• Expérience chez Google et vingt ans de débats au sein de la communauté
  • Partage d’expérience sur le travail de patch et de maintenance pour appliquer libunwind à gperftools.
• Cas passés où l’option -fomit-frame-pointer a permis d’améliorer les performances
  • Compilation de MySQL et PHP sur des processeurs 32 bits afin de réduire les coûts matériels.
• Méthode de gestion des trames de pile dans le langage de programmation Virgil
  • En l’absence d’allocation dynamique de pile, il est possible de trouver la taille d’une trame par une simple consultation de table.
  • Explication du code implémentant le décodage des métadonnées.
• Idée de gérer deux piles à l’aide de RBP et RSP au lieu de « parcourir » la pile
  • La pile d’appels devient simplement un tableau d’adresses de retour, ce qui réduit le besoin de parcourir la pile.
• Partage d’expériences et de réflexions en faveur des pointeurs de trame
  • L’activation des pointeurs de trame doit être décidée au cas par cas, et le benchmarking est important.
  • Importance pour le système de build d’offrir une fonctionnalité permettant de modifier cela globalement.
  • Attentes autour de SFrame et de son potentiel à résoudre les problèmes actuels.
• Avis selon lequel le profiling a été un problème pendant vingt ans et n’est résolu que maintenant
  • L’absence de pointeurs de trame a été une source de souffrance pour beaucoup, et voir Linux revenir en arrière donne l’impression que leurs efforts sont enfin reconnus.
• Il est paradoxal de se plaindre des performances du mécanisme qui permet justement le profiling système
  • Se plaindre des performances d’un système qui permet d’identifier les problèmes de performances, c’est le summum de l’optimisation prématurée.