Linux 5.1: Performance-Verbesserungen und neue Speichertechnik

Seite 2: NVDIMMs, a.out vor dem Rauswurf, Jahr-2038-Problem, …

Inhaltsverzeichnis

Intel-Entwickler wollen Optane DC Persistent Memory leichter nutzbar machen.

(Bild: c't 9/2019 )

Linux 5.1 kann die Speicherkapazität nicht-flüchtiger Speichermodule (NVDIMMs) jetzt so einbinden, dass Programme oder der Kernel selbst diese Bereiche wie normalen Arbeitsspeicher ansprechen können. Durch dieses von Intel-Entwicklern vorangetriebene Feature müssen Anwendungen nicht mehr groß angepasst werden, um Persistent Memory (PMEM) zu verwenden, auf dem Daten auch beim Kappen der Stromversorgung erhalten bleiben; zu solch raren und meist teuren Speichermodulen zählt etwa Intels im April vorgestelltes Optane DC Persistent Memory. Details zu diesem NVDIMMs hat c't 9/2019 im Artikel "Zwischen RAM und Flash-Speicher: Das bringt Optane DC Persistent Memory" erläutert, den es auch für heise+-Abonnenten gibt.

Apropos NVDIMMs: Der neue Kernel rüstet auch Unterstützung für ACPI 6.3 nach, das unter anderem einige Verbesserungen für solche nicht-flüchtige Speichermodule (NVDIMMs) gebracht hat.

Linus Torvalds hat eigenhändig Vorbereitungen getroffen, um die Unterstützung für das Dateiformat a.out (Assembler Output) vollständig zu entfernen. Dieses wurde in der Anfangszeit von Linux für ausführbare Dateien und Objektdateien genutzt; vor mehr als 25 Jahren lernte Linux dann aber das ELF abgekürzte Executable and Linking Format, das schnell zum dominierenden Format aufstieg und diese Position nach wie vor unbestritten hält. Daher war auch niemand aufgefallen, dass der Kernel-Code für Speicherabzüge (Core Dumps) von a.out-Executables nicht mehr korrekt arbeitet. Torvalds hat diesen Code daher kurzerhand entfernt; darüber hinaus hat der den a.out-Support bei x86-Kerneln als veraltet/überholt ("deprecated") gekennzeichnet und lahmgelegt, daher lässt er sich in x86-Kernel-Images nicht mehr einbauen.

Linus Torvalds geht höchstpersönlich Code aus der Frühzeit von Linux an den Kragen.

(Bild: git.kernel.org – 08300f4402ab )

Damit will der leitende Kernel-Entwickler schauen, ob sich jemand beklagt, bevor er den zuständigen Code tatsächlich rauswirft. Falls das tatsächlich jemand tut, würde Torvalds womöglich zurückrudern, denn dann wäre das Ganze eine "Regression". Solche versucht Torvalds auf Biegen und Brechen zu vermeiden, daher gilt bei der Linux-Entwicklung schon lange ganz generell: Nur eine Person muss glaubhaft und zeitnah vorbringen, das mit einer neuen Version im Alltagsbetrieb irgendwas nicht mehr geht, was mit der Vorversion funktioniert hat; in dem Fall werden die verantwortlichen Änderungen dann revidiert, sofern das Problem Kernel-seitig nicht anders gelöst werden kann. Der Beklagende muss dabei allerdings zeigen, dass es sich um ein praktisches Problem handelt, und nicht etwa um ein rein theoretisches; außerdem müssen das alte und der neue Kernel-Image möglichst identisch konfiguriert sein. Diese Herangehensweise gilt für alle Kernel-Features mit Ausnahme von jenen im Staging-Bereich, wo es Sonderregeln gibt.

Einen Meilenstein gab es bei den Umbauten zur Beseitigung des Jahr-2038-Problems, das 32-Bit-Prozessoren betrifft: Die Kernel-Entwickler haben einen Schwung neuer Funktionsaufrufe (Syscalls) eingebaut, die alten ähneln, aber 64-Bit-Zeitwerte verstehen (u. a. 1, 2, 3, 4, 5, 6, 7, 8). Auch die Netzwerkentwickler haben zwei ähnlich gelagerte Änderung vorgenommen, um ein Y2K38-Problem in ihrem Code anzugehen (1, 2).

Damit ist Kernel-seitig zwar noch nicht alles Nötige getan, aber das meiste. Entwickler von Systembibliotheken und Anwendungen können ihre Software jetzt an die neuen Funktionsaufrufe anpassen, damit ihre Programme 2038 nicht plötzlich denken, es sei 1970 oder gar 1901; das ist auch überfällig, schließlich wird die Kombination von 32-Bit-ARM-Kernen und Linux aktuell noch in Autos oder anderen Embedded Systems verwendet, die wahrscheinlich auch in 19 Jahren noch im Einsatz sind.

Details zur Problematik und den neuen Syscalls liefert der LWN.net-Artikel "Approaching the kernel year-2038 end game." Einige weitere Details finden sich in den Vortragsfolien und einem Video-Mittschnitt des Vortrags "The End of Time, 19 years to go"; er stammt von Arnd Bergmann, der treibende Kraft hinter den Y2K38-Änderungen im Kernel ist.