Die Rückkehr des Frame Pointers

Brendans Website: Erste Schritte

• Die Blog-Homepage von Brendan Gregg behandelt verschiedene Themen wie System-Performance, BPF-Tools und Linux-Performance.
• Zu den jüngsten Beiträgen gehören unter anderem die Rückkehr des Frame Pointers, eine eBPF-Dokumentation und warum eBPF-Beobachtungstools keine Sicherheitstools sind.
• Der Blog teilt neben technischen Inhalten auch verschiedene Konferenzen und Vorträge, an denen Brendan beteiligt war.

Die Rückkehr des Frame Pointers

• Auf Systemen ohne Frame Pointer endet das Stack-Tracking auf der libc-Ebene, sodass Application-Frames fehlen.
• Fedora und Ubuntu lösen dieses Problem, indem sie Versionen veröffentlichen, in denen libc standardmäßig mit enthaltenen Frame Pointern kompiliert wird.
• Frame Pointer werden von externen Profilern und Debuggern verwendet und durch Flame Graphs visualisiert.

Was ist ein Frame Pointer?

• Laut dem x86-64-ABI-Dokument kann das CPU-Register %rbp als "Base Pointer" eines Stack-Frames verwendet werden.
• Diese Technik wird weithin für Stack-Traces genutzt und von Linux perf und eBPF verwendet.

2004: Entfernung des Frame Pointers

• 2004 führte der gcc-Entwickler Roger Sayle eine Änderung ein, die die Erzeugung von Frame Pointern beendete.
• Diese Änderung brachte Leistungsgewinne, doch mit dem Aufkommen von eBPF verursacht sie heute bei einigen Debuggern/Profilern Probleme.

2005–2023: Der Winter kaputter Profiler

• Die Änderung zur Entfernung des Frame Pointers wurde auch auf x86-64 angewendet, doch diese Architektur verfügt über mehr Register, sodass der Gewinn gering war.
• Dadurch funktionierten viele Debugger/Profiler nicht mehr richtig.

2014: Java in Flames

• Als er zu Netflix kam, stellte er fest, dass die fehlende Unterstützung für Frame Pointer in Java alle Application-Stacks unbrauchbar machte.
• Um dieses Problem zu lösen, entwickelte er einen Patch für den JVM-c2-Compiler.

2015–2020: Overhead

• Der Performance-Overhead, wenn man überall Frame Pointer hinzufügt, liegt in der Regel unter 1 %.
• In bestimmten Microbenchmarks kann der Overhead bis zu 10 % erreichen.

2022: Upstream-Versuch

• Es wird angedeutet, dass große Unternehmen wie Google, Meta und Netflix Frame Pointer bereits überall aktiviert haben.
• Es gibt mehrere Schwierigkeiten dabei, diese Änderungen als Standard zu setzen, damit alle davon profitieren.

2023, 2024: Frame Pointer in Fedora und Ubuntu

• Fedora hat einen Vorschlag akzeptiert, Frame Pointer wieder zu aktivieren.
• Ubuntu aktiviert Frame Pointer ebenfalls standardmäßig in Version 24.04 LTS.

Ab 2034: Jenseits des Frame Pointers

• Es gibt verschiedene Methoden, Stacks nachzuverfolgen, darunter LBR, BTS, AET, DWARF, eBPF-Stack-Walking, ORC, SFrames, Shadow Stacks und weitere.
• In Zukunft könnten SFrames oder Shadow Stacks für sämtliches Stack-Tracking verwendet werden.

Fazit

• Die Rückkehr des Frame Pointers macht CPU-Flame-Graphs aussagekräftiger, lässt Off-CPU-Flame-Graphs erstmals funktionieren und eröffnet weitere neue Möglichkeiten.
• Es ist auch ein Gewinn für Continuous Profiler, da sie Kunden nicht mehr von OS-Änderungen überzeugen müssen, damit Profiler vollständig funktionieren.

Meinung von GN⁺

• Die Rückkehr des Frame Pointers dürfte für die Analyse der System-Performance und das Debugging sehr hilfreich sein. Besonders in komplexen Softwaresystemen ist dies ein unverzichtbares Werkzeug, um Probleme zu diagnostizieren und Performance zu optimieren.
• Diese Veränderung zeigt die Bedeutung von Zusammenarbeit und Beiträgen in der Open-Source-Community. Die Entscheidungen von Fedora und Ubuntu könnten auch andere Distributionen beeinflussen und so positive Veränderungen im gesamten Linux-Ökosystem bewirken.
• Die Wiedereinführung von Frame Pointern ist eine Frage der Balance zwischen Performance-Verlust und einfacherer Fehlersuche. Solche Entscheidungen lassen sich durch Performance-Tests und Analysen in realen Produktionsumgebungen besser verstehen.
• Für Nutzer mit technischem Hintergrund dürfte diese Veränderung interessant sein und Entwicklern oder Systemadministratoren, die sich für bessere System-Performance interessieren, nützliche Informationen liefern.
• Falls es andere Technologien oder Werkzeuge mit ähnlicher Funktion wie Frame Pointer gibt, können etwa hardwarebasierte Profiler wie Intels VTune Profiler oder AMDs uProf verwendet werden. Solche Tools ermöglichen Performance-Analysen auch ohne Frame Pointer.

[GN⁺]

Hacker-News-Kommentare

• Erfahrungen aus der Zeit, als sich Anfang der 2000er das Weglassen des Stack-Frame-Pointers zu verbreiten begann
  • Der Autor studierte damals Informatik, und der genutzte Computer war alt und leistungsschwach.
  • Als das Debugging schwieriger wurde, begann er Python zu verwenden und umging so die Debugging-Probleme.
• Bemühungen in der Fedora-Distribution, den Stack-Frame-Pointer beizubehalten
  • Es gab den falschen Glauben, dass der Stack-Frame-Pointer großen Overhead verursache, tatsächlich liegt der Overhead aber unter 1 %.
• Dass Apple auf der ARM-Architektur Stack-Traces stets aussagekräftig gehalten hat
  • Bestimmte Funktionen erzeugen möglicherweise keinen Frame-Record, aber der Stack-Trace bleibt auch ohne Debug-Informationen sinnvoll.
• Erfahrungen bei Google und 20 Jahre Debatte mit der Community
  • Geteilte Erfahrungen mit Patch-Arbeit und Wartung, um libunwind in gperftools einzusetzen.
• Fälle aus der Vergangenheit, in denen mit der Option -fomit-frame-pointer Leistungssteigerungen erzielt wurden
  • Kompilieren von MySQL und PHP für 32-Bit-Prozessoren, um Hardwarekosten zu senken.
• Wie die Programmiersprache Virgil Stack-Frames verwaltet
  • Wenn es keine dynamische Stack-Allokation gibt, kann die Frame-Größe mit einem einfachen Tabellen-Lookup gefunden werden.
  • Erklärung des Codes zur Implementierung der Metadaten-Dekodierung.
• Die Idee, statt den Stack zu „durchlaufen“ zwei Stacks mit RBP und RSP zu verwalten
  • Der Call-Stack würde dann einfach zu einem Array aus Rücksprungadressen, wodurch Stack-Walking seltener nötig wäre.
• Geteilte Erfahrungen und Gedanken zur Unterstützung von Frame-Pointern
  • Ob Frame-Pointer aktiviert werden sollten, muss von Fall zu Fall entschieden werden, und Benchmarking ist wichtig.
  • Wichtig ist, dass Build-Systeme eine Funktion bieten, dies systemweit zu ändern.
  • Erwartungen an SFrame und dessen Potenzial, aktuelle Probleme zu lösen.
• Die Meinung, dass Profiling 20 Jahre lang ein Problem war und erst jetzt gelöst wurde
  • Das Fehlen von Frame-Pointern war für viele schmerzhaft, und dass Linux dies nun zurücknimmt, fühlt sich an wie eine Anerkennung ihrer Mühen.
• Die Ironie der Klagen über die Performance des Mechanismus, der System-Profiling überhaupt erst ermöglicht
  • Sich über die Performance eines Systems zu beklagen, das erst hilft, Performance-Probleme zu identifizieren, ist die ultimative Form verfrühter Optimierung.