Seite 6: Infrastruktur: Support für Raspberry Pi 3B und ARM-Laptops

Inhaltsverzeichnis

Support für Raspberry Pi 3B und 3B+

Linux 4.18 ist die erste Kernel-Version, die die Bastelcomputer Raspberry Pi 3B und 3B+ von Haus aus halbwegs ordentlich unterstützt. Das ist unter anderem Patches zu verdanken, die Unterstützung für den im März vorgestellten Raspberry Pi 3B+ nachrüsten (u. a. 1, 2, 3). Dank einer weiteren Änderung weiß der Kernel jetzt auch dessen seit 4.17 prinzipiell unterstützten GPIO-Expander anzusprechen, der auch auf dem Raspberry Pi 3B (ohne Plus) sitzt. Dadurch lassen sich nun die für WLAN, Bluetooth, HDMI-Erkennung und Aktivitäts-LED benötigten GPIOs steuern. Beim LAN78XX-Treiber für den Gigabit-Ethernet-Controller des B+ lauern aber wohl noch mehr Bugs als gewohnt, wie ein an den Änderungen beteiligter Entwickler uns wissen ließ.

Diese Fortschritte sind vor allem für Distributionen wie Debian, Fedora & Co. wichtig, die Raspis mit ihren regulären ARM- beziehungsweise ARM64-Kerneln unterstützen wollen. Für Nutzer spezialisierter Raspi-Distributionen wie Raspbian sind die Verbesserungen im offiziellen Linux-Kernel nur relevant, wenn sie einen Mainline-Kernel einsetzen möchten: Diese Distributionen verwenden spezielle für Raspis gebaute Kernel, bei denen die Entwickler zahlreiche Raspi-spezifsche Umbauten und Erweiterungen vorgenommen haben. Die fließen vielfach nur träge in offizielle Linux-Versionen ein, weil die Patches gar nicht eingereicht werden oder die Qualitätsansprüchen der Entwickler um Linus Torvalds nicht erfüllen. Manchmal ist das Missfallen so groß, dass unabhängige Programmierer die von Raspbian & Co. verwendeten Erweiterungen und Treiber verwerfen und von Grund auf neuen Code schreiben, um Komponenten der verschiedenen Raspis zu unterstützen.

Support für leistungsstarke ARM-Laptops am Horizont

Der bessere Raspi-3-Support stieß mit Erweiterungen an den ARM Device Trees zum Kernel, die auch Support für den Steam Link von Valve und die Nintendo NES/SuperNES Classic Edition gebracht haben. Bei einigen dieser und anderer erstmals unterstützter SOCs bedeutet das aber nur, dass der Linux-Kernel jetzt irgendwie mit diesen Plattformen klarkommt; zum Alltagseinsatz fehlen jedoch oftmals Treiber für wichtige oder weniger wichtige Komponenten.

Das gilt auch für den ebenfalls neuen Support für den Qualcomm SDM845, der auch als Snapdragon 845 bekannt ist. Olof Johansson erwähnt beiläufig, dass man damit noch nicht viel machen könne, allerdings werde Support für USB, GPU und andere Komponenten langsam eintrudeln; wenn das so weiter gehe, werde der offizielle Kernel diesen SOC bald ziemlich gut unterstützen. Linus Torvalds wurde da gleich hellhörig und fragte, ob das nicht der SoC einiger mit Windows ausgelieferten Notebooks mit ARM-Prozessor sei. Solche halbwegs leistungsstarken und mit x86-Geräten vergleichbare Notebooks wünscht er sich schon länger, wie er 2014 in einem Interview mit c't verriet.

Daraufhin entstand eine Mail-Wechsel, in dem Heiko Stübner anmerkte, auch das mit Rockchip RK3399 ausgestattete Samsung Chromebook Plus dürfte die Wünsche von Torvalds halbwegs erfüllen. Johansson widersprach nicht, erwähnte aber, dass die Situation bei Grafiktreibern beim Snapdragon 845 besser sei, denn für deren Adreno-GPUs gibt es mit Freedreno einen quelloffenen Grafiktreiberstack; bei Geräten mit dem SOC habe er zudem berechtigte Hoffnungen, dass sich Secure Boot ausschalten lasse.

Performance-Schub durch neustartbaren Userspace-Code

Nach vielen Jahren Entwicklungsarbeit bringt Linux 4.18 erstmals einen Funktionsaufruf für "Restartable Sequences" mit. Der Syscall ist für mit mehreren Threads arbeitende Anwendungen gedacht, die mit möglichst wenig Overhead eine Datenstruktur verändern wollen. Mit den Restartable Sequences gelingt das ohne klassisches Locking, indem der Userspace-Code bei der Ausführung darauf spekuliert, dass ihm kein anderer Thread in die Quere kommt; falls das doch passiert, fängt er nochmal von vorn an.

Der Programmierer kann das Verfahren über den neuen Syscall nutzen. Dieser legt einen von Anwendung und Kernel geteilten Speicherbereich an, bei dem der Kernel die Zugriffe durch seine "Per-CPU"-Funktion sichert. In dem geteilten Speicherbereich hinterlegt der Entwickler eine Sequenz von Instruktionen, die eine CPU-lokale Datenstruktur verändert – zum Beispiel ein Element in eine Linked List einfügt. Die eigentliche Änderung darf erst mit letzten, nicht unterbrechbaren (also "atomaren") Instruktionen dieser Sequenz erfolgen. Während der Ausführung des Programmcodes kann allerdings ein anderer Thread auf dieselbe Datenstruktur zugreifen und so die Restartable Sequence unterbrechen. Wenn das passiert, springt der Kernel in den Abbruch-Teil der Restartable Sequence; das Userspace-Programm muss diesen Fall dann handhaben und kann die Sequenz gegebenenfalls neu starten.

Im Idealfall ist so ein Restart der Sequenz aber nicht nötig, sodass die Änderung erfolgt, ohne das der normale Locking-Overhead anfällt. Das kann die Performance in bestimmten Fällen um ein Vielfaches steigern. Das zeigen Messungen des vor allem durch seine Arbeit an LTTng (Linux Trace Toolkit Next Generation) bekannten Entwicklers, der jahrelang auf die Integration der Restartable Sequences hingearbeitet hat. Ihm zufolge läuft ein "Per-CPU statistic counter increment" genannter Micro-Benchmark auf einem 32-Bit-ARM-Prozessor 11 mal schneller, auf einem 64-Bit-x86-System rund 7,7 mal so schnell. Der Commit-Kommentar nennt Testergebnisse spezieller Aufgaben, bei denen sich noch größere Vorteile zeigen; er erwähnt aber auch einen Praxistest von Facebook, bei dem der Gesamtvorteil im einstelligen Prozentbereich lag.

Der Kernel unterstützt Restartable Sequences bislang im Architekturcode für ARM, MIPS, Powerpc und x86. Wie man diesen begrenzten atomaren Kontext für Userspace-Programme verwendet, erläutert ein Kommentar im Kernel-Code. Ein im letzten Herbst veröffentlichter LWN.net-Artikel liefert einige Hintergründe zum Ganzen; nach dessen Publikation wurde die Implementation aber nochmal verändert, wodurch die dort erwähnten "ops vectors" wieder vom Tisch sind.

Speicherminimum, Jahr-2038-Vorbereitungen, …

Der Control Group (Cgroup) Memory Controller bietet jetzt den Parameter memory.min, über den der Admin noch zuverlässiger als bei memory.low sicher stellen kann, dass der Prozessgruppe mindestens die im Parameter festgelegte Arbeitsspeichermenge zur Verfügung steht.

Ftrace kann durch die neuen "trace_marker trigger" Aufgaben ausführen (etwa Histogramme erzeugen), wenn bestimmte Umgebungsbedingungen eintreten.

Neu sind auch die "Power Domain Performance Levels", die das Powermanagement-Subsystem in die Lage versetzen, das Performance/Stromsparniveau des ganzen Systems samt seiner Peripherie-Geräte zu regeln. Diese bei LWN.net näher erläuterte Erweiterung ist unter anderem für SOCs wichtig, bei denen mehrere Komponenten zusammenhängen und daher beispielsweise koordiniert heruntergetaktet oder ausgeschaltet werden müssen, um die Leistungsaufnahme zu reduzieren.

Ferner gab es einige bei LWN.net erläuterte Umbauten (u. a. 1, 2), um 32-Bit-Linux-Kernel Jahr-2038-fest zu machen; abgeschlossen sind diese Arbeiten aber nach wie vor nicht.

Weitere Informationen zu den architekturspezifischen Änderungen nennen die wichtigsten Merge-Commits am Code für ARM (Core, SOC [1, 2], SOC DT, SOC Drivers), ARM64, m68k, m68knommu, microblaze, MIPS, PowerPC, RISC-V, S390, x86 (Boot, Cache, DAX, Debug, Hyperv, RAS). Änderungen rund um die Infrastruktur erwähnen Merge-Commits für ACPI (1, 2), Core RCU, Char, Cgroups, DMA Mapping, Device Tree, Dokumentation, EDAC, EFI, Kbuild (1, 2), Kconfig, KVM (1, 2), Locking Core, PCI, Printk, Perf (1, 2), Power Management (1, 2), IRQ, IOMMU, Scheduler, Selftests, Siginfo, Thermal Core, Thermal Soc, Timer, Trace, VFIO, Vhost. Das sind übrigens nur jene Merges, die der Autor aus dem ein oder anderen Grund für verlinkenswert hielt, weil sie für manche Leser relevante Informationen enthalten. Einige Dutzend andere Merges rund um Architektur oder Infrastruktur haben diese Hürde nicht geschafft. Das gleiche gilt auch für andere Aufzählungen dieser Art, die dieser Text enthält.