Open Source im professionellen Einsatz
Linux-Magazin 06/2014

Zacks Kernel-News

Neues von der Kernel-Mailingliste.

993

Neuer Ausgabemechanismus für Kernel-Oops

VT, das Subsystem des Kernels für virtuelle Terminals, ist eigentlich gar nicht mehr erforderlich. Deaktiviert man es aber zur Compile-Zeit, gibt es ein Problem: Der Linux-Kern kann im Fehlerfall keine Oops-Message mehr an eine Konsole schicken.

Der Informatikstudent David Herrmann hat deshalb ein Patch auf der Mailingliste eingereicht, das die Ausgabe über den Direct Rendering Manager (DRM) erledigt. Dieses DRM-Log meldet seine eigene Konsole an und gibt dort Kernel-Logs und Oops-Meldungen aus.

Die Herausforderung beim Ausgeben von Oops-Informationen liegt darin, dass der Vorgang nicht die komplette Infrastruktur des Betriebssystems voraussetzen kann. Schließlich kommt er zum Einsatz, wenn Linux abstürzt und mit letzter Kraft eine Meldung absetzen möchte. Daher kümmert sich DRM-Log auch um den Umbruch der Zeilen und malt sie passend pixelweise in den Framebuffer, der vielleicht als letzte Spur übrigbleibt.

David schreibt, DRM-Log sei langsam und eigne sich daher nur für den Notfall und fürs Debugging. Auch auf Embedded-Systemen mit wenig Platz wäre es eine Alternative, zumindest im Entwicklungsmodus.

Bruno Prémont vom Linux-Vserver-Projekt fürchtet, die verwendete Schrift könnte je nach Monitor zu klein sein, etwa auf Apples hochauflösendem Retina-Display. Er fände es gut, wenn man die Schrift für DRM-Log konfigurieren könnte. David dagegen findet Schriftarten unnötig aufwändig und möchte lieber alles auf der Pixel-Ebene erledigen. Er gesteht allerdings ein, dass die Größe wichtig ist, und erklärt sich bereit, ganzzahlige Größenschritte zu unterstützen.

Auch Alan Cox hat sich zu Wort gemeldet. Der Kernel-Veteran wünscht sich mehr Geschwindigkeit – nicht unbedingt bei Notfällen, aber beim Debuggen. Daneben schreibt er: "Was mich eigentlich stutzig macht: Warum soll man das an DRM binden? Es verwendet zwar einige von dessen Konstanten, ist aber sonst von DRM und Framebuffer unabhängig."

David räumt ein, dass sein Log nichts DRM-Spezifisches an sich hat. Daneben gibt er sich aber trotzig: "Ich habe schon genug Zeit damit vergeudet, die Aufmerksamkeit der Core-Maintainer für kleinere Reparaturen zu bekommen. [...] Sollte jemand außerhalb von DRM Interesse an dem Feature haben, bin ich gesprächsbereit. Ansonsten möchte ich den Code in DRM lassen, denn dessen Entwickler haben es bereitwillig aufgenommen." Das beendete die Diskussion.

© © Wikipedia.org/Adamantios (CC-BY-SA)Ein Kernel-Oops ist unangenehm, offenbart aber Details aus dem Inneren des Betriebssystemkerns. Jetzt soll es eine neue Ausgabemethode dafür geben.

Probleme bei zahlreichen Mounts

Moderne Systeme, die sehr viele Datenträger einhängen, haben Performanceprobleme des Linux-Kernels offenbart. Bei "einer ernsthaften Menge von Mounts" kommt es laut Al Viro zu "richtig peinlichen Bottlenecks". Unter anderem hat er festgestellt, dass die Funktionen »percpu_alloc()« und »percpu_free()« ineffizient arbeiten. Ihre Zeitkomplexität beziffert er mit O(n2), ihre Ausführungszeit steigt also quadratisch mit der Anzahl der Mounts.

Trotz des kniffligen Problems hat Al einige Details entdeckt, die bei geringen Änderungen spürbare Verbesserungen versprechen. Dazu gehört ein Stück Code, dass unnötigerweise die Länge aller eingehängten Datenbereiche aufsummiert, um einen Offset zu finden.

Die Funktion »propagate_ mnt()« , schreibt Al Viro weiter, sei bereits bei ihrer Implementierung als ineffizient bekannt gewesen. Die Entwickler hatten die schlechte Performance wegen der schlichten Logik hingenommen. Das mache sich aber erst jetzt bemerkbar.

Daneben läuft das Lesen von »/proc/mounts« zu langsam, weil der Code jeweils die komplette Liste durchgehen muss, um den Ort eines einzelnen Eintrags zu bestimmen. Al möchte mit einem Cache für mehr Tempo sorgen.

Den Scheduler aufspalten?

Der Intel-Entwickler Yuyang Du möchte den Linux-Scheduler in zwei Teile aufspalten. Er schreibt, Computer besäßen immer mehr CPU-Kerne, selbst in Embedded-Systemen steckten mehrere Cores mit unterschiedlicher Leistung. Soll der Scheduler Prozesse verwalten und gleichzeitig über mehrere Prozessoren verteilen, würde der Code unnötig komplex. Daher schlägt er vor, den Scheduler in zwei zu teilen: eine obere Hälfte für das Prozess-Scheduling und eine untere zur Lastverteilung über die CPUs.

Erschwerend kommt hinzu, dass sich der Scheduler auch noch um Aspekte von Energieverbrauch und Datendurchsatz kümmern muss. Nach Yuyangs Plan soll das jede der beiden Hälften künftig selbstständig und unabhängig von der anderen erledigen. Das soll die Logik einfacher zu verstehen und zu warten machen. Peter Zijlstra gibt sich allerdings skeptisch: "Das wird nie etwas – diese Diskussion hatten wir schon mehrmals."

Morten Rasmussen von ARM ist konkreter und befürchtet, die Logik lasse sich nicht so sauber auftrennen wie erhofft. Er vermutet, Yuyang möchte unterschiedliche Unterteile an die obere Hälfte anstecken, um verschiedene Strategien für Load Balancing umzusetzen.

Dabei gibt Morten zu bedenken, dass sich jede Lastverteilung notwendigerweise auch auf das Prozess-Scheduling auswirkt. Trenne man die beiden voneinander, schränke das die Möglichkeiten stark ein, mit anderen Worten: Die beiden seien untrennbar miteinander verknüpft.

Obwohl Yuyang sich bemühte, dieses Problem mit einem guten Design zu bewältigen, konnte er die Mailingliste nicht von seiner Idee überzeugen.

Experimentelle Kernelmodule

Daniel Vetter von Intel möchte den Kernel als »tainted« markieren, wenn Benutzer experimentelle Module laden. "Die Anwender aktivieren gerne alle möglichen experimentellen Optionen, weil sie sich etwas davon versprechen. Später bekommen wir dann die Bugreports, weil alles abgestürzt ist", schreibt Daniel.

Er möchte den Anwendern klarmachen, dass "sie mit dem Feuer spielen" und den Kernel in diesem Fall als »tainted« (beschmutzt) auszeichnen. Das spiegelt sich dann auch in den Fehlermeldungen wider, die die Kernelentwickler erhalten. Diese werden den Benutzer in der Regel bitten, den Bug mit einem Kernel ohne experimentelle Module zu reproduzieren.

Andrew Morton hält diesen Vorschlag für nützlich sowie ungefährlich und möchte das Feature gerne in den Linux-Kern aufnehmen. Dennoch haben er und Rusty Russel kleinere technische Kritikpunkte. Daniel will ein nachgebessertes Patch einreichen. (Zack Brown/mhu)

Diesen Artikel als PDF kaufen

Express-Kauf als PDF

Umfang: 2 Heftseiten

Preis € 0,99
(inkl. 19% MwSt.)

Linux-Magazin kaufen

Einzelne Ausgabe
 
Abonnements
 
TABLET & SMARTPHONE APPS
Bald erhältlich
Get it on Google Play

Deutschland

comments powered by Disqus

Stellenmarkt

Artikelserien und interessante Workshops aus dem Magazin können Sie hier als Bundle erwerben.