Linux 5.1 der neue Kernel

Your Linux Blog

Der neue Kernel 5.1 verspricht vieles. Am 8. oder 15. Juli soll der neue Linux Kernel zur Verfügung stehen. Kleinere Perfomance boosts sowie Sicherheitslücken an der CPU sollen dadurch geschlossen werden.Ihr wollt auf eurem PC das Maximum an Geschwindigkeit herauskitzeln und fürchtet euch nicht vor den ganzen Sicherheitslücken moderner Hauptprozessoren, die seit Anfang 2018 publik wurden? Dann startet den Kernel fortan mit dem neuen Parameter mitigations=off, denn der deaktiviert die vielen Schutztechniken, die der Kernel für diese Lücken erhalten hat und standardmäßig nutzt.
Wie stark das die Performance steigert, hängt von Prozessor und der eingesetzten Software ab: Die Gegenmaßnahmen machen manche Workloads deutlich langsamer, andere nur minimal.

Über den neuen Kernel-Parameter „mitigations=“ kann man Maßnahmen für Prozessorlücken lahmlegen und so die Performance steigern.

Weiterhin gab es folgende Verbesserung

  • Das Jahr 2038 Problem wurde nun endlich beseitigt.
  • Für die ARM Technologie kommen 2 neue Grafiktreiber die die Grafikkerne eine leichte Perfomance steigern kann.
  • Geringerer Stromverbrauch und bessere Perfomance verspricht der „Timer Events Oriented (TEO)“ genannte CPUIdle-Governor
  • Große Fortschritte gab es bei den seit über fünfzehn Jahren vorangetriebene Bemühungen und entwicklungen bei den Linux Security Modules (LSMs). SELinux, AppArmor,Smack kann durch „Stacking“ ab sofort parallel genutzt werden.
  • Linux 5.1 bringt einen ganzen Schwung kleinerer Perfomance – Optimierungen. Darunter „AIRTIME FAIRNESS“, mit dem sich das Funkspektrum von WLANs besser ausnutzen lässt

Überfällige Vorbereitung auf das Jahr 2038

Dieses Problem betrifft nur die 32 bit Prozessoren. Einen Meilenstein gab es bei der Beseitigung und Umbau des Jahr 2038 Problems das nur die 32 bit Prozessoren betrifft. Die Kernel – Entwickler haben einen Schwung neuer Funktionsaufrufe (Syscalls) eingebaut, die die alten ähneln, aber 64-Bit-Zeitwerte verstehen. Auch die Netzwekentwickler haben zwei ähnliche gelagerte Änderung vorgenommen, um ein Y2K38 – Porblem in Ihrem Code anzugehen.

Damit ist Kernel – seitig zwar noch nicht alles Nötige getan, aber Sie sind auf einen guten weg das meiste zu beheben. Entwickler von Systembibiotheken und Anwendungen können nun Ihre Software auf die neuen Funktionsaufrufe optimieren, damit Ihre Programme nicht im Jahre 2038 nicht plötzlich denken es sei da Jahr 1970 oder gar 1901; das ist auch längst überfällig, schliesslich wird die Kombination von 32-Bit-ARM-Kernen und Linux aktuell noch in Autos (Smart Car, Digital Radios, usw) oder anderern Embedded Dystems verwendet, die höchstwahrscheinlich noch in 19 Jahren im Einsatz sind.

Weitere Details zur Problematik und den neuen Syscalls liefert der LWN.net-Artikel „Approching the kernel year-2038 end game„. Einige Details die nicht im Artikel behandelt worden sind werden in einem Video Mittschnitt des Vortrages „The End of Time, 19 years to go„; der Vortrag stammt von Arnd Bergmann, die treibende Kraft hinter den Y2K38-Änderungen im Kernel.

Ein Grafiktreiber für ARM – CHIP, zwei weitere sind auch schon in Anflug

Die für Prozessorkern-Designs bekannte Firma ARM (auch verbaut in Raspberry PI und Odroid) hat den Grafiktreiber Komeda beigesteuert, der den Maili D71 und dessen Nachfolger unterstützt, wie die Dokumentation erläutert. Das sind „Display Processors“, ähnlich wie DP500, DP550 und DP650, die Linux mit dem ebenfalls von ARM zugelieferten Treiber Mali-DP schon länger unterstützt. Die genannten Grafikkerne sind vornehmlich für die Bildausgabe augelegt; ihnen fehlt daher eine 3D-Einheit, die bei PC-Grafikchips seit der Jahrtausendwende Usus sind.

ARM liefert Treiber für einen simplen Display Prozessor zu, beteiligt sich aber nicht an der Entwicklung von Treibern für leistungsfähigere Grafikchips.
Hier zum kompletten Artikel

3D-Funktionen sind anderen IP-Cores der Maili-Produktpalette vorbehalten, die geläufiger sind und sich auf so manchem Einplatinencomputer finden. Solche Mali-GPU unterstützt Linux nach wie vor von Haus aus nicht. Das sollen die Kernel-Treiber Lima und Panfrost ändern, die zur Aufnahme in Linux 5.2 vorgesehen sind; darauf bauen gleichnahmige OpenGL-Treiber zur 3D-Beschleunigung auf, die Mesa 19.1 mitbringen wird. Lima unterstützt dabei „Utgard“ – GPUs augelegt, die unter den Mali Bezeichnungen T6xx, T7xx, T8xx respektive G3x, G5x, G7x segeln. Bei der Entwicklung dieser Treiber hat ARM allerdings untätig daneben gestanden. Vielmehr entstanden sie weitgehend mit Hilfe von Hardware- und Treiber-Analysen (Reverse Engineering), daher unterstützen beide nur ausgewählte Grafikkerne und längst nicht alle ihrer Funktionen.

Prozessor passend schlafen schicken

Geringeren Stromverbrauch und zugleich bessere Performance verspricht ein „Timer Events Oriented“ (TEO) genannter CPUIdle-Governor. Wie der bislang auf vielen Systemen genutzten CPUIdle-Regulator „Menu“ entscheidet er bei Untätigkeit darüber, ob und wie tief der Kernel den ganzen Hauptprozessor schlafen schickt, um den Stromverbrauch zu reduzieren. Beide arbeiten sogar mit einer ähnlichen Strategie. Wie der TEO-Entwickler im Commit-Kommentar erläutert, mache der Menu-Governor aber einige fragwürdige Dinge. Das ist indes keine Meinung eines dahergelaufenden Newcomers; wie TEO selbst stammt die Aussage vielmehr vom langjährigen Betreuer des Power-Management-Codes im Kernel, der daher den Code des Menu-Governor gut kennt.

Einer der Hauptunterschiede: TEO verwendet für seine Entscheidungen eine andere Bemessungsgrundlage. Sie soll deutlich besser zur „Tickless“-Arbeitsweise passen, die sich seit Linux 3.10 über die Option CONFIG_NO_HZ_FULL aktivieren lässt, die bei Kernel-Image heutiger Distributionen meist gesetzt ist. Details zu TEO finden sich im Kommentar eines Git-Commits, den darin enthaltenen Dokumentationsänderungen und dem LWN.net-Artikel „Improving idle behavior in tickless systems„.

Ob TEO im Einzelfall besser läuft, hängt allerdings stark von den jeweiligen Umgebungsbedingungen ab. Kein Wunder, denn es gibt Software und Workloads, die speziell auf die Arbeitsweise des Menu-Governor abgestimmt sind; das ist auch der Grund, warum das Problem nicht mit inkrementellen Verbesserungen am Menu-Governor angegangen wurde, wie es die Kernel-Entwickler sonst in solchen Situationen tun; der alte Governor wird daher auch weiter im Rahmen des Kernels gewartet

 

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.