zurück zum Artikel

Kernel-Log: Flinker mit Prozessgruppen

Trends & News | Kernel-Log

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 der vergangenen Woche sorgte ein nur zirka 200 Zeilen umfassender Patch [1] 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 [2]; verstärkte Aufmerksamkeit erhielt eine überarbeitete Version des Patches, nachdem Torvalds sie vor einer Woche in sehr deutlichen Worten lobte [3] 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 [4] 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 [5] 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 [6] können.

Über die Vor- und Nachteile der beiden Ansätze und ihrer Implementierungsdetails wurde in einer langen Diskussion [7] teilweise recht harsch gestritten. Auch Torvalds sparte an einigen Stellen nicht mit deutlichen Worten, brachte die Diskussion aber später auch wieder zur Ruhe [8], 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 [9], den Kernel-Patch zur Auto-Gruppierung für 2.6.38 zu integrieren; dabei hat er aber ein Problem im Code [10] 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.

Zum Start dieser Arbeitswoche hat Linus Torvalds die dritte Vorabversion von Linux 2.6.37 veröffentlicht und sich in der begleitenden Freigabe-Mail [11] erfreut darüber gezeigt, dass es so ruhig gewesen sei – dass also die anderen Kernel-Hacker [12] relativ wenig Änderungen zur Aufnahme eingesandt haben.

Am Montag Abend folgte Greg Kroah-Hartman und gab vier neue Stable-Kernel frei: 2.6.27.56 [13], 2.6.32.26 [14], 2.6.35.9 [15] und 2.6.36.1 [16]. Einige Korrekturen für die 36er-Reihe hat er hat er außen vor gelassen und für 2.6.36.2 aufgehoben. Die 35er-Reihe hat mit 2.6.35.9 jetzt ihr "End of Life" erreicht und soll keine weitere Updates erhalten; Anwender dieser Kernel-Serie sollen daher auf den Kernel 2.6.36 umsteigen, schreibt Kroah-Hartman in der Freigabe-Mail zu dieser Version.

Kernel

X-Server und Co.

Kernel-Umland ("Plumbing layer"), Userland-Treiber, Entwicklertools, ...

Weitere Hintergründe und Informationen rund um Entwicklungen im Linux-Kernel und dessen Umfeld finden sich in den vorangegangenen Kernel-Logs [38] auf heise open [39]. Neue Ausgaben des Kernel-Logs [40] werden auf den Identi.ca [41]- und Twitter [42]-Konten "@kernellog" erwähnt; die englischen, bei den Kollegen von "The H [43]" erscheinenden Übersetzungen auf den Identi.ca [44]- und Twitter [45]-Konten "@kernellog2". Gelegentlich zwitschert der Autor des Kernel-Logs unabhängig davon über einige Kernel-Log-Themen bei Identi.ca [46] und Twitter [47] als "@kernellogauthor". (thl [48]).


URL dieses Artikels:
http://www.heise.de/-1140656

Links in diesem Artikel:
[1] http://www.heise.de/glossar/entry/Patch-395546.html
[2] http://thread.gmane.org/gmane.linux.kernel/1050575
[3] http://thread.gmane.org/gmane.linux.kernel/1061204/focus%3D1062310
[4] http://thread.gmane.org/gmane.linux.kernel/1061204/focus%3D1063263
[5] http://thread.gmane.org/gmane.linux.kernel/1061204/focus%3D1064178
[6] http://thread.gmane.org/gmane.linux.kernel/1061204/focus%3D1063497
[7] http://thread.gmane.org/gmane.linux.kernel/1061204/
[8] http://thread.gmane.org/gmane.linux.kernel/1061204/focus%3D1065460
[9] http://thread.gmane.org/gmane.linux.kernel/1061204/focus%3D1063252
[10] http://article.gmane.org/gmane.linux.kernel/1066188/
[11] http://thread.gmane.org/gmane.linux.kernel/1066261
[12] http://www.heise.de/glossar/entry/Kernel-Hacker-397919.html
[13] http://thread.gmane.org/gmane.linux.kernel/1066627
[14] http://thread.gmane.org/gmane.linux.kernel/1066621
[15] http://thread.gmane.org/gmane.linux.kernel/1066623
[16] http://thread.gmane.org/gmane.linux.kernel/1066622
[17] http://training.linuxfoundation.org/lp/sign-up-for-the-free-linux-training-webinar-introduction-to-btrfs
[18] https://www.heise.de/meldung/Next-Generation-File-System-fuer-Linux-205565.html
[19] http://thread.gmane.org/gmane.linux.kernel/1059394
[20] http://thread.gmane.org/gmane.linux.kernel/1056223/focus%3D1058687
[21] http://support.amd.com/us/gpudownload/Pages/index.aspx
[22] http://www.nvnews.net/vbulletin/showpost.php?s=99209e23a1013723450a623f49d4c1dd&p=2343452&postcount=11
[23] https://www.heise.de/meldung/Ubuntu-will-weg-von-X11-1131824.html
[24] http://lists.freedesktop.org/archives/wayland-devel/2010-November/000249.html
[25] http://thread.gmane.org/gmane.linux.kernel/1063399
[26] http://0pointer.de/blog/projects/systemd-update-2.html
[27] http://0pointer.de/blog/projects/systemd-for-admins-4.html
[28] http://thread.gmane.org/gmane.linux.kernel/1062159
[29] http://linux-man-pages.blogspot.com/2010/11/man-pages-331-is-released.html
[30] http://linux-man-pages.blogspot.com/2010/11/linux-programming-interface-is-released.html
[31] http://www.man7.org/tlpi/tlpi_in_detail.html
[32] http://thread.gmane.org/gmane.linux.kernel/1061573
[33] http://www.ibm.com/developerworks/linux/library/l-virtual-networking/
[34] http://www.linuxplumbersconf.org/2010/ocw/events/LPC2010/proposals
[35] http://www.linuxplumbersconf.org/2010/ocw//system/presentations/417/original/kreport.pdf
[36] http://www.linuxplumbersconf.org/2010/ocw/proposals/579
[37] http://www.linuxplumbersconf.org/2010/ocw/proposals/279
[38] http://www.heise.de/open/kernel-log-3007.html
[39] http://www.heise.de/open/
[40] http://www.heise.de/glossar/entry/Kernel-Log-397909.html
[41] http://identi.ca/kernellog
[42] http://twitter.com/kernellog
[43] http://www.h-online.com
[44] http://identi.ca/kernellog2
[45] http://twitter.com/kernellog2
[46] http://identi.ca/kernellogauthor
[47] http://twitter.com/kernellogauthor
[48] mailto:thl%40ct.de