Kernel-Log: Flinker mit Prozessgruppen

Durch die automatische Gruppierung von Prozessen sollen Videos in Zukunft nicht mehr ruckeln und die Desktop-Oberfläche bedienbar bleiben, auch wenn viele Prozesse die CPU gehörig ins Schwitzen bringen. Derweil schreitet die Entwicklung von 2.6.37 voran und neue Stable-Kernel bringen Korrekturen für die Vorgänger. 2.6.35 hat indes sein Lebensende erreicht.

In Pocket speichern vorlesen Druckansicht 51 Kommentare lesen
Lesezeit: 10 Min.
Von
  • Thorsten Leemhuis
Inhaltsverzeichnis

In der vergangenen Woche sorgte ein nur zirka 200 Zeilen umfassender Patch für Gesprächsstoff in Linux-Kreisen. Er soll die Interaktivität von Desktop-Applikationen in bestimmten Situationen, bei denen die CPU voll ausgelastet wird, erheblich steigern. Begonnen hatte die Diskussion um den Ansatz der Code-Änderung bereits vor einem Monat; verstärkte Aufmerksamkeit erhielt eine überarbeitete Version des Patches, nachdem Torvalds sie vor einer Woche in sehr deutlichen Worten lobte und davon sprach, dass sein System beim Kompilieren eines Kernels deutlich interaktiver sei.

Die bessere Reaktionsgeschwindigkeit erreicht der Patch, indem er für mit setsid() erstellte Sessions (etwa Daemonen, echte Terminals oder Pseudo-TTYs wie Xterm) automatisch eine eigene, über Cgroups verwaltbare Prozessgruppe erstellt und dadurch beeinflusst, wie der Prozess-Scheduler die verfügbare Prozessorzeit verteilt. Am besten lässt sich das mit einem vereinfachten Beispiel verdeutlichen, bei dem ein Multimedia-Player ein Video auf einer Single-Core-System wiedergibt, während man parallel in einem Xterm einen Kernel mit 9 simultanen Jobs (make -j 9) kompiliert.

Im Normalfall würde der Scheduler jedem Job 10 Prozent der Zeit zuteilen. Das ist unter Umständen zu wenig für eine flüssige Video-Wiedergabe. Wenn die Desktop-Oberfläche Tastatur- und Mauseingaben verarbeiten soll, müsste auch sie sich noch dazwischenquetschen, sodass die Zeit dann durch elf Prozesse aufgeteilt würde.

Durch den Patch landen die im Pseudo-Terminal gestarteten Compiler-Prozesse in einer eigenen Gruppe; die Prozesse der Desktop-Umgebung und der darüber gestartete Multimedia-Player stecken in einer anderen. Sofern in beiden Gruppe Prozesse laufen, die die CPU voll fordern, gewährt der Prozess-Scheduler jeder Gruppe 50 Prozent der Prozessorzeit. Innerhalb der Gruppe wird die Zeit wieder gerecht verteilt – jeder Compiler-Job erhält dann nicht mehr 10, sondern nur noch 5,6 Prozent der CPU-Zeit. Dadurch steht der Gruppe mit Desktop und Video-Player mehr Rechenzeit zur Verfügung, was für eine flüssige Video-Wiedergabe ausreichen sollte und noch genug Luft lässt, damit die Desktop-Oberfläche flott auf Eingaben via Maus und Tastatur reagiert.

Bei flotten CPUs dürfte die Player-Software allerdings die ihr zur Verfügung stehende CPU-Zeit gar nicht komplett verwenden und daher die Kontrolle an den Scheduler zurückgeben, wenn es gerade nichts weiteres zu tun gibt. Der verteilt die Zeit dann an andere Jobs, sodass die Gruppe mit den Prozessen zum Kompilieren des Kernels letztendlich mehr als 50 Prozent der CPU-Zeit erhält – das Kompilieren sollte dadurch nicht viel länger dauern als ohne die automatische Gruppierung.

Dieses Verhalten lässt sich aber auch bei älteren Kerneln und ohne den Patch konfigurieren. Dazu sind bei konfigurierten CPU-Cgroups lediglich zwei Aufrufe in den Startdateien der Bash nötig, wie Pulseaudio- und Systemd-Entwickler Lennart Poettering erklärt. Eine vergleichbare Lösung direkt in Systemd hält er für eleganter und flexibler als die automatische Gruppierung durch den Kernel. Den dazu nötigen Code implementierte Poettering wenige später und integrierte ihn in Systemd, damit es zusammen mit einer Erweiterung für das Gnome-Terminal die Gruppen ähnlich anlegt, wie es der Kernel-Patch auch tun würde. Ted Ts'o ('tytso') merkte an, dass man die Spezifikation für Desktop-Dateien sogar so anpassen könnte, dass auch andere Applikationen automatisch eine eigene Gruppe erhalten können.

Über die Vor- und Nachteile der beiden Ansätze und ihrer Implementierungsdetails wurde in einer langen Diskussion teilweise recht harsch gestritten. Auch Torvalds sparte an einigen Stellen nicht mit deutlichen Worten, brachte die Diskussion aber später auch wieder zur Ruhe, indem er erklärte, dass nichts dagegen spricht, beide Ansätze zu verfolgen.

Genau darauf scheint es zumindest derzeit hinauszulaufen, denn der Verwalter des Prozess-Schedulers hat angedeutet, den Kernel-Patch zur Auto-Gruppierung für 2.6.38 zu integrieren; dabei hat er aber ein Problem im Code gefunden, an dessen Beseitigung noch gearbeitet wird. Die Auto-Gruppierung lässt sich durch eine Konfigurationsoption ein- und ausschalten, sodass Distributionen, die ausschließlich auf die Systemd-Lösung setzen wollen, die zuständigen Kernel-Funktionen problemlos deaktivieren können.

Den meisten Anwendern dürfte ohnehin egal sein, welche der beiden Ansätze nun unter der Haube arbeitet – Hauptsache, die Desktop-Oberfläche reagiert flott und Videos und ruckeln nicht, selbst wenn andere Prozesse die CPU ins Schwitzen bringen.