Linuxs Desktop Responsiveness Wunderpatch im Videovergleich

2 Videos zeigen mehr als 1000 Worte:

http://www.phoronix.com/scan.php?page=article&item=linux_2637_video&num=2

Mir fällt die Kinnlade beim Anblick herunter, wie flott und reaktiv der Desktop mit diesem Patch reagiert.

Schaut auf das in den Videos abgespielte Videos, beim ersten Video ohne Patch stockt es richtig, während der Kernel compiliert wird, beim zweiten VIdeo mit Patch wird es flüssig abgespielt als hätte der Kernel nichts zu tun und trotzdem wird im Hintergrund der Kernel compiliert.

Das ist wie damals Windows 95 im Vergleich zu BeOS.

Warum war Linux dann vorher so toll?

nman

uiiiiiii schrieb:

Warum war Linux dann vorher so toll?

Weil in Wirklichkeit niemand seinen Kernel mit "-j64" kompiliert.

(Wenn Du 64 Jobs erstellst, die um Ressourcen konkurrieren, dann tut das natürlich weh.)

Zur Ergänzung: http://www.webupd8.org/2010/11/alternative-to-200-lines-kernel-patch.html

Der Typ hat 12 Kerne oO
Ich dachte -j richtet sich nach der Anzahl der Kerne.
Das hießt ich kann irgendeine Zahl schreiben und es werden dann -jX-Threads erstellt?

nman

interessant!! schrieb:

Ich dachte -j richtet sich nach der Anzahl der Kerne.
Das hießt ich kann irgendeine Zahl schreiben und es werden dann -jX-Threads erstellt?

Ja. (Der Genauigkeit halber: Jobs, nicht Threads. Aber Du meinst schon das richtige.)

Typischerweise richtet sich der User bei der Auswahl der Jobanzahl nach der Anzahl der Kerne. Das musst Du aber natürlich nicht.

Ach ja, und ad 12 Kerne: Ich habe mir das Video nicht nochmal angesehen, könnten durchaus auch nur sechs Kerne mit Hyperthreading sein (halte ich für recht wahrscheinlich). Falls es doch 12 sind, hat er vmtl. eben zwei Sechskern-CPUs in seinem System. Sechskern-Phenoms kosten so derzeit irgendwas zwischen 150 und 250€, sind also durchaus leistbar.

nman schrieb:

interessant!! schrieb:

Ich dachte -j richtet sich nach der Anzahl der Kerne.
Das hießt ich kann irgendeine Zahl schreiben und es werden dann -jX-Threads erstellt?

Ja. (Der Genauigkeit halber: Jobs, nicht Threads. Aber Du meinst schon das richtige.)

Typischerweise richtet sich der User bei der Auswahl der Jobanzahl nach der Anzahl der Kerne. Das musst Du aber natürlich nicht.

Ach ja, und ad 12 Kerne: Ich habe mir das Video nicht nochmal angesehen, könnten durchaus auch nur sechs Kerne mit Hyperthreading sein (halte ich für recht wahrscheinlich). Falls es doch 12 sind, hat er vmtl. eben zwei Sechskern-CPUs in seinem System. Sechskern-Phenoms kosten so derzeit irgendwas zwischen 150 und 250€, sind also durchaus leistbar.

Vielen Dank für die Erklärung.
Hab da was gefunden:

For the two videos I recorded them off a system running Ubuntu 10.10 (x86_64) with an Intel Core i7 970 "Gulftown" processor that boasts six physical cores plus Hyper Threading to provide the Linux operating system with twelve total threads.

Kann mir jemand auf 'Deutsch für OS-Laien' erklären, wo genau der Unterschied jetzt ist (im Kernel)?

SeppJ

fragefragefrage schrieb:

Kann mir jemand auf 'Deutsch für OS-Laien' erklären, wo genau der Unterschied jetzt ist (im Kernel)?

Vorher: Wenn Prozesse gleiche Priorität haben, haben sie gleichen Anteil an den Computerressourcen erhalten. Wenn man sehr viele prozessorintensive Prozesse (im Video 64 Compilerprozesse) mit der Standardpriorität erstellt hat (mit der in der Regel auch das Dektopsystem läuft), hat die grafische Oberfläche weniger Ressourcen bekommen als sie für schnelle Benutzerinteraktion braucht.

Nachher: Prozesse alle aus einem Terminal gestartet werden, werden zusammen als ein Prozess behandelt. Die 64 Prozesse im Video bekommen also grob 50% der Systemressourcen, die Desktopoberfläche die anderen 50% (unter der Annahme das gerade sonst nichts läuft). Da die Desktopoberfläche weit weniger als 50% der Ressourcen braucht, können die Compilerthreads trotzdem einen Großteil der Ressourcen verbrauchen (die sie auch dankbar annehmen), weshalb sie nicht viel langsamer ablaufen als vorher. Im Falle eines Falles, hat die Desktopoberfläche aber ein Anrecht auf 50% der Ressourcen (vorher auf 1/65 der Gesamtressourcen), weshalb sie sehr viel schneller reagiert.

SeppJ schrieb:

Nachher: Prozesse alle aus einem Terminal gestartet werden, werden zusammen als ein Prozess behandelt. Die 64 Prozesse im Video bekommen also grob 50% der Systemressourcen

Und wie überträgt sich der Effekt, wenn überhaupt, dann in die "echte" Welt? Denn so wie sich das anhört bringt das ja nur was im Spezialfall, wenn ich über das Terminal Prozesse starte die viel CPU brauchen ?

SeppJ

fragefragefrage schrieb:

Und wie überträgt sich der Effekt, wenn überhaupt, dann in die "echte" Welt?

Für manche Leute ist das die echte Welt.

Denn so wie sich das anhört bringt das ja nur was im Spezialfall, wenn ich über das Terminal Prozesse starte die viel CPU brauchen ?

Siehe oben.

Wenn man solche Scherzchen nicht macht, reagiert der Linuxdesktop ja ohnehin schnell. Ist ja nur, dass er es nicht macht, wenn man solche komischen Sachen treibt.

nman

fragefragefrage schrieb:

Und wie überträgt sich der Effekt, wenn überhaupt, dann in die "echte" Welt?

Potentiell sehr gut auf viele Anwendungsfälle.

Denn so wie sich das anhört bringt das ja nur was im Spezialfall, wenn ich über das Terminal Prozesse starte die viel CPU brauchen ?

Lies Dir mal das hier durch, da wird erklärt, wie Control Groups funktionieren.
http://www.mjmwired.net/kernel/Documentation/cgroups.txt

Dann sollte auch klar sein, dass Auto-sgroups in vielen Fällen praktisch sein könnte. Das tty könnte ja durchaus auch ein pts sein.

hustbaer

Ich kann mir vorstellen dass das z.B. praktisch ist, wenn man sich auf nem produktiven Server einloggt, der gerade von Clients total zugemüllt wird.
Wenn alle Client-Requests in der selben Gruppe laufen, wird man wesentlich besser arbeiten können, als wenn die hunderten oder tausenden Requests die ganze CPU-Zeit weglutschen.

Allerdings kann man damit denke ich auch einiges kaputt machen. Könnt mir vorstellen, dass es Systeme gibt, wo bestimmte Dinge - die eigentlich nicht so wichtig wären - in lauter eigenen Gruppen landen. Wenn dann sämtliche Client-Requests eines Servers zusammen nur eine Gruppe haben, könnten diese anderen Dinge auf einmal ungewollt viel CPU-Zeit bekommen.

Also ein Patch den man denke ich mit einiger Vorsicht anwenden sollte - also das System danach gut beobachten.

(Bei Heimanwendern geht's natürlich "um nix", d.h. die werden den Patch wohl ohne grosse Sorge anwenden können)

Morris Szyslak

Wenn ich dem GUI-Prozess höhere Priorität gäbe, hätte das den gleichen Effekt?

SeppJ

Morris Szyslak schrieb:

Wenn ich dem GUI-Prozess höhere Priorität gäbe, hätte das den gleichen Effekt?

Nicht gleich, aber ähnlich.

nman

Morris Szyslak: Was ist denn auf einem modernen Betriebssystem "_der_ GUI-Prozess"? X? Der Window-Manager? Der Compositer? Dein Browser? Dein Media-Player?

hustbaer: Der Patch wird ohnehin in Mainline landen, da wird noch viel getestet werden. Aber prinzipiell sollte der recht gut degraden und auch in unpraktischen Situationen keine allzu bösen Auswirkungen haben.

Morris Szyslak

nman: ja, und WOW. Und wieso modernes Betriebssystem? Ich dache wir sprechen von Linux

nman

Und wieso modernes Betriebssystem? Ich dache wir sprechen von Linux

Gut getrollt. Nein, warte, überhaupt nicht. Modern ist in diesem Kontext alles, was nicht einen einzelnen "GUI-Prozess" hat. Es ist nicht so trivial, einfach schnell mal eben der GUI hohe Priorität zu geben.

Du kannst natürlich auch alles manuell herumnicen, geht aber völlig am Thema vorbei.

hustbaer

Morris Szyslak schrieb:

Wenn ich dem GUI-Prozess höhere Priorität gäbe, hätte das den gleichen Effekt?

So lange die GUI genug Resourcen "übrig lässt" hätte es einen ähnlichen Effekt.
Die bessere GUI Performance ist IMO eher ein Abfallprodukt dieser Änderung.

Stell dir mal vor du hast eine Box, auf der laufen zwei Dienste. Einer macht alles in einem Prozess, und legt da drinnen einen Thread pro Core an. Der andere macht für jeden Fliegenschiss nen eigenen Prozess, und hat unter Last dann 100e Prozesse gleichzeitig laufen.
Beides Szenarien die unter Linux nicht unüblich sind.

Haben nun beide Dienste viel Last, dann bekommt der der "brav" mit nur einem Prozess mit einem Thread pro Core arbeitet viel weniger Rechenzeit.

Mit dem Patch bekommen beide Dienste etwas gleich viel.

Und dieses Szenario kann man nicht mehr "geradbiegen" indem man dem "braven" Dienst eine höhere Priorität verpasst, da der "böse" Dienst dann u.U. gar keine Rechenzeit mehr bekommt.

Morris Szyslak

Danke für die Erklärung.

Ed: Ich gebe zu, ich hatte die Doku dazu nicht gelesen. Deshalb hatte ich aus den bisherigen Beschreibungen den Eindruck gewonnen, dass es nur um Beschleunigung der Nutzerschnittstelle geht. Hab das jetzt nachgeholt.