Linux 5.2 freigegeben: Änderungsrekord und Geschwindigkeitsverbesserungen
Seite 8: Debug-Daten hinterlegen; größere & flexiblere BPF-Programme
Daten für Performance-Messungen anders hinterlegen
Wie jüngst üblich bringt auch Linux 5.2 wieder einen ganzen Schwung an Verbesserungen rund um die BPF Virtual Machine, auf die mittlerweile zahlreiche Subsysteme des Kernels für verschiedenste Aufgaben zurückgreifen – allen voran für Performance-Analysen, die Ablaufverfolgung (Tracing), das Seccomp-Sandboxing und den Netzwerk-Schnellverarbeitungspfad eXpress Data Patch (XDP).
Für Performance-Analysen, Ablaufverfolgung oder Debugging wichtige Daten wie Header lassen sich jetzt nicht mehr nur im etablierten DWARF-Format hinterlegen, sondern auch mit dem bei Linux 4.18 eingeführten BPF Type Format (BTF). Hauptvorteil des neuen Ansatzes ist geringerer Speicherbedarf: Zum Hinterlegen der C-Typen eines Kernel-Images (vmlinux) soll BTF zehnmal weniger Speicherkapazität benötigen. Das gelingt unter anderem durch Deduplizierung, mit dem der Platzbedarf bei anderen Einsatzzwecken sogar um hundertmal kleiner ausfällt als beim verbreiteten DWARF.
Das soll weitere Einsatzgebiete ermöglichen, denn durch den geringeren Overhead wird es für Distributoren attraktiver, diese Daten in Kernel und Modulen zu belassen, statt sie auszulagern oder komplett zu ignorieren. Ein Linux-Image wird dann selbstbeschreibend ("self-descriptive"). Das ist etwa interessant, damit Tracing-Programme wie perf, bpftrace oder Werkzeuge der BPF Compiler Collection (BCC) alle für ihre Tätigkeiten nötigen Informationen auf jedem System vorfinden und leicht zur Hand haben. Bislang muss man dazu meist Debuginfo-Pakete nachinstallieren, falls der Distributor denn an dieses Nutzungsszenario gedacht hat und solche denn auch bereitstellt.
BPF-Programme nachträglich anpassen
Durch den neuen Support für "Global Data" in BPF beherrschen BPF-Programme jetzt globale Variablen, wie sie C bietet. Hauptziel der Erweiterung: Ein Programm-Binary nachträglich anpassen zu können, damit man BPF-Programme nicht immer wieder neu kompilieren muss, wenn sich ein Konfigurationsdetail ändert.
Bislang muss man BPF-Programme nämlich oft genau für den jeweiligen Einsatzzweck übersetzen, denn bei BPF-Programmen zur Handhabung von Netzwerkpaketen werden beispielsweise Daten wie IP- oder MAC-Adressen im Code definiert. Durch Global-Data-Support lassen sich solche Variablen jetzt nachträglich in der Binärdatei ändern. Ein einmal kompiliertes Programm kann so als "Template Binary" fungieren, das Entwickler oder Werkzeuge wie die Container-Netzwerksoftware Cilium nachträglich verändern, wenn das Programm später andere IP- oder MAC-Adressen nutzen soll.
Das Ganze gelingt mithilfe des bereits erwähnten BTF, mit dem die globalen Daten im Kompilat hinterlegt werden. Solche "compile-once"-Programmvorlagen ermöglichen schneller einsatzbereite BPF-Programme, da man diese nicht mehr ad-hoc individuell kompilieren muss; neben Zeit spart das Ganze somit auch CPU-Ressourcen und funktioniert auch auf Systemen ohne Compiler.
Größere und flexiblere BPF-Programme
Der BPF Verifier, der von der BPF Virtual Machine ausgeführten Code vor der Ausführung überprüft, akzeptiert jetzt komplexeren Code: Bislang durfte ein Programm 4096 Instruktionen aufweisen und bei der Ablaufsimulation maximal 130.000 Instruktionen ausführen (etwa durch If-Verzweigungen). Jetzt ist in beiden Fällen bei 1.000.000 Instruktionen Schluss. Das alte Limit konnte angehoben werden, weil die Entwickler einige "BPF Verifier Scalability" genannte Optimierungen vorgenommen haben, die die Prüfung um ungefähr das Zwanzigfache beschleunigen.
Darüber hinaus gab es noch allerlei andere Umbauten an oder rund um die BPF Virtual Machine (u. a. 1, 2, 3, 4, 5). Unter denen ist beispielsweise auch noch das BPF SK Local Storage, das die Netzwerkprogrammierung mit BPF erleichtern soll, oder der TCP-Syncookie-Check, der die Programmierung von Loadbalancern in der Art von Glb-Director oder Beamer mittels BPF ermöglichen soll.
