Der Linux-Desktop wird schneller

[uname]

Vielleicht hat es ja schon jemand gelesen und zum Glück ist heute nicht der 1. April. Bitte noch in Squeeze einbauen.

http://www.pro-linux.de/news/1/16406/de ... eller.html

[TobiSGD]

In Squeeze wird das wohl kaum noch kommen, ist ja gerade frozen. Laut einem anderen Bericht (habe den Link gerade nicht zur Hand) soll das wohl offiziell in 2.6.38 kommen, der Patch läßt sich aber schon in frühere Kernel einbauen.

[Lord_Carlos]

Endlich
Wurde ja auch mal zeit.
Die IO patches sind ja schon in .36 drinne. Wird besser und besser.

[TRex]

Wen juckt der Distributionskernel Ich freu mich auf .38

[mindX]

Sorry,ich steh grad auf dem Schlauch... bitte klärt mich auf
In 2.6.36 aus Experimental ist der Wunderpatch schon drin?
Und nach Release von Squeeze wandert der 2.6.36 incl. Patch nach Sid und dann in die Squeeze-backports?

[Colttt]

hmm.. wird das Debian-team das evtl in den aktuellen Debian-Kernel patchen??

[cirrussc]

Sorry,ich steh grad auf dem Schlauch... bitte klärt mich auf
In 2.6.36 aus Experimental ist der Wunderpatch schon drin?

Nein, so wie ich das verstanden habe, erst in den 38er.

hmm.. wird das Debian-team das evtl in den aktuellen Debian-Kernel patchen??

Das glaube ich eher nicht

[Saxman]

Hat schon jemand den patch getestet?

[storm]

Ich möchte euch nur ungern die Vorfreude nehmen, es könnte aber sein, dass ihr da mehr rein interpretiert als am Ende rauskommt. Die Diskussion zu diesem Patch ist noch nicht ganz abgeschlossen, da vor allem gestern noch aus der redhat-Ecke triftige Einwände kamen, dass eine ähnliche Funktionalität bereits im gegenwärtigen -stable drin ist: cgroups. Zusammen mit dem wohl bald aufkommenden Standardeinsatz von systemd, der das alles im userspace managen soll, wurden in der Diskussion auch Zahlen (benchmark) gezeigt, die mehr für cgroups+systemd sprechen. D.h. aber nicht, dass sich beide Varianten ausschließen. Das Hauptargument war nur, dass beim gleichzeitgen Einsatz von autogroup (in-kernel) und cgroups (userspace) die Prozesse mit einem tty/pts (also autogroup-kontrollierte) die Ressourcenkontrolle für cgroups unangenehm beeinflussen können (wenn cgroups nix vom Einsatz von autogroup mitkriegt).

Zweiter wichtiger Punkt: Arbeitslasten der genannten Zahlenbeispiele. Die genannten Zahlenbeispiele für den angenommenen Erfolg des patches waren allesamt welche, die den Arbeitsalltag eines kernel hackers wiederspiegeln, zB. make -j 10 oder make -j 64 (bei linus) und auf nem anderen Desktop etwas mail lesen und im Netz rumwurschteln. Also bei denen ist im Hintergrund meistens ordentlich Last vorhanden, die natürlich die Reaktivität Latenz des Desktops verschlechtert. Deswegen war/ist Herr Torvalds auch so begeistert. Wer von euch übersetzt denn mehr oder weniger dauernd irgendwelche kernel-Versionen? Ich für meinen Teil nich. Ich finde deshalb auch die Argumentation von Lennart Pöttering (red hat) nachvollziehbar, dass es für den 'normalen ' Desktop-user nicht unbedingt spürbare Verbesserung bringt, obwohl mir persöhnlich Automatismen im Kernel immer mehr zusagen also noch ein weiterer daemon im userspace, bei dem ich mich frage was der die ganze Zeit laufen muss.

ciao, storm

[Alternativende]

Also doch nur viel Lärm um Nichts oder was? Unter Vollast läuft ein Desktop ja eher nie bei normalem Gebrauch.
Wäre gut wenn das mal jemand testen könnte. Ich hoffe da persönlich schon sehr auf systemd und verspreche mir davon auch viel.

[Harakiri]

mein notebook mit 512 mb läuft leider öfter mal unter ordentlich last, da ich facebook farmviller bin
flash eben halt. daher wäre ich über jede kleine verbesserung der "responsiveness" dankbar.

leider habe ich kurz vorher unter der rubrik "neuigkeiten" einen thread zum selben thema eröffnet und diesen eben erst entdeckt. aber einen interessanten link aus dem aptosid-forum habe ich dazu doch noch zu bieten, da dort neben der diskussion auch der kommentar von linus persönlich verlinkt ist: http://aptosid.de/index.php?name=PNphpB ... 7a85d436bf

kurzer auszug:

Sehr interessante Nachricht hab ich heute gelesen. Wahrscheinlich ist es auch bereits Euch bekannt. Smile

http://marc.info/?l=linux-kernel&m=128978361700898&w=2

Es geht darum, dass ein Patch (200 Zeilen) um einiges Wink die Interaktivität auf dem Rechner verbessert.

Hier ist der Kommentar von Linus:
http://marc.info/?l=linux-kernel&m=128979084506774&w=2

Das Video ist hier http://www.phoronix.com/scan.php?page=a ... ideo&num=2

Hier ist ein Patch für 2.6.36 http://pavlinux.ru/krnl/sched_autogroup ... .patch.bz2

[Lord_Carlos]

mein notebook mit 512 mb läuft leider öfter mal unter ordentlich last, da ich facebook farmviller bin
flash eben halt

Vielleicht muss dein Lappy einfach swappen? 512mb ram braucht mein browser alleine.
Im .36 kernel sind so auch schon CPU sheduler und IO Verbesserungen drinne. Kannst du ja mal testen.

Auch: Hast du die Aktuelle flash version? Die vor 1 - 2 Monaten mal rausgekommen ist rockt das haus. Spuerbar besser. Jedenfalls bei Video Wiedergabe.

Der lenny kernel ist was IO und CPU angeht einfach bäh. (Meine subjektive Meinung)

[Harakiri]

ja, es ist definitiv das swappen was spürbar bremst. ich nutze den neuesten flashplayer, aber erfahrungsgemäß sind die meisten flash-spielchen ziemliche ressourcenfresser.

mit anderen worten: man kann da leider nicht viel dran ändern.

immerhin versuche ich im zusammenspiel von kleinigkeiten eine etwas bessere performance zu bekommen. so ist mein desktop xfce, der kernel ist ein 36er aptosid, firefox ist selber kompiliert und so weiter. mit dem neuen "wunderpatch" wäre eine weitere komponente dazu gekommen.

sollte dieser patch tatsächlich etwas bringen, wird er sowieso in den nächsten kernelreleases integriert sein. ich muss einfach etwas geduldiger sein.

[mindX]

Eine ähnliche oder sogar höhere Geschwindigkeitssteigerung wie der Patch soll die Modifikation der bashrc bringen.
http://www.webupd8.org/2010/11/alternat ... patch.html

Hat das schon jemand ausprobiert bzw. kann jemand einschätzen, ob das sinnvoll ist?

[storm]

sollte dieser patch tatsächlich etwas bringen, wird er sowieso in den nächsten kernelreleases integriert sein. ich muss einfach etwas geduldiger sein.

Der patch wird - sollten keine triftigen Gründe mehr auftauchen - auf jeden Fall integriert. Allein die Tatsache, dass auf dem Rechner von Linus Torvalds eine deutlich bessere Interaktivität erreicht wird, ist da ausreichend.
Ob er an deiner Situation etwas ändert, musst du selbst rausfinden.

Hat das schon jemand ausprobiert bzw. kann jemand einschätzen, ob das sinnvoll ist?

Das funktioniert allerdings nur, wenn in deinem Kernel cgroups drin sind:

Code: Alles auswählen

$> zgrep CGROUPS /proc/config.gz
CONFIG_CGROUPS=y

In dem von dir verlinkten Artikel ist da auch nirgendwo ein Hinweis zu finden. Ich kann mich dunkel an den thread auf der kernel-ml erinnern, wo von den systemd-Entwickerln bemängelt wird, dass gegenwärtig keine größere Distribution das Feature in ihrem kernel aktiviert hat. Sinnvoll sollte es sein, da nach Aussage von Poettering systemd und damit auch cgroups in Zukunft bei den großen Distributionen (er führt das nicht explizit auf, welche er meint) per default laufen soll.

ciao, storm

[mindX]

Danke für die Erläuterungen!

Ich hab hier Squeeze mit Debian-Standardkernel laufen... der bashrc-Tweak sollte gehen, oder?

Code: Alles auswählen

$ uname -r
2.6.32-5-amd64

$ grep CGROUPS /boot/config-2.6.32-5-amd64 
CONFIG_CGROUPS=y 

$ cat /proc/cgroups
#subsys_name	hierarchy	num_cgroups	enabled
cpuset	0	1	1
ns	0	1	1
cpu	0	1	1
cpuacct	0	1	1
devices	0	1	1
freezer	0	1	1
net_cls	0	1	1

[storm]

Du hättest es schon lange probieren können! *g
Im Ernst: damit solltest du nix kaputt machen, also ist testen gefahrlos. Hast du irgend ein Kriterium, woran du den möglichen Erfolg des tweaks messen kannst/willst? Also Darstellungsfehler beim Fensterziehen oder Soundaussetzer?

PS: dein kernel ist schon etwas älter, als der auf lkml diskutierte. Das kann durchaus bedeuten, dass der Entwicklungsstand von cgroups zu der Zeit noch nicht so weit war.

ciao, storm

[Harakiri]

Hast du irgend ein Kriterium, woran du den möglichen Erfolg des tweaks messen kannst/willst? Also Darstellungsfehler beim Fensterziehen oder Soundaussetzer?

in der tat frage ich mich ob es sowas wie eine "kernel-benchmark" gibt mit der man performance-verbesserungen darstellen könnte. auf meinem desktop nutze ich nämlich squeeze mit selbstgemachten kernel seed und 2.6.35 zen kernel. läuft alles schön, aber performance messwerte konnte ich bislang keine erhalten, weil ich noch nicht rausgefunden habe wie ich es messen kann.

Das funktioniert allerdings nur, wenn in deinem Kernel cgroups drin sind

okay, beim nächsten kompilieren wird das berücksichtigt

[storm]

Jetzt mal Butter bei die Fische oder um Herrn Torvalds zu zitieren [1]: Numbers talk, bullshit walks.
Da so ein Gewese um diesen patch gemacht wird, hab ich mal in einem eher schnellen, unsauberen Weg versucht rauszufinden, ob denn was für mich dabei ist. Über die Testmethoden hab ich nicht länger als 5 min nachgedacht, entsprechend wenig aussagekräftig sind die Zahlen. Aber bei sowas unspezifischen wie der Latenzzeit oder Interaktivität ist es meiner Meinung nach auch nicht gerade einfach ein aussagekräftiges und universelles Ergebnis zu erhalten. Manche Nutzer merken eine schlechte Latenzzeit erst wenn es Aussetzer beim Audio oder Video gibt, andere stören sich schon am schlichten Ruckeln der Bewegung und Grafikfehlern beim "Fensterziehen" oder beim Aufklappen eines Menüs. Natürlich gibts auch Methoden und fertige tools um die Performance des Prozess-Schedulers zu überprüfen, aber die Zahlen muss man a) interpretieren können und b) müssen sie nicht zwangsläufig mit der gefühlten Interaktivität zu tun haben.

Heut nachmittag hab ich den 2.6.36 (vanilla) mal kopiert und zusätzlich zum normalen 2.6.36 jeweils eine Version mit autogroup-Patch und eine mit BFS [2] gebaut. Die config der Kernel unterscheidet sich nur in den Punkten, die zusätzlich durch die Patches eingebracht wurden, sonst ist alles gleich. Jeder Kernel wurde als debian-Paket gebaut und installiert. Eigentlich wollte ich nach dem Booten jedes Kerns wenigsten 1h warten und in der Zwischenzeit den Speicher (buffer/cache) etwas auffüllen (zB. mit dem Durchsuchen eines Bilderarchivs mit rund 30GB und dem Erstellen einer exif-Statistik). Das hab ich aber aus Zeitgründen verworfen und außerdem bezweifel ich, dass dieses künstliche "Verschmutzen" des Speichers der Realität (auf meiner Kiste) nahe kommt. Stattdessen wurde jeder Kernel gebootet, die (für mich) normale Desktop-Situation hergestellt. Das beinhaltet fluxbox, ein paar terminals, mocp, opera und conky. Als Gerätschaften für die Testerei hab ich mplayer und glxgears verwendet. Den mplayer ein Mal im benchmark-Modus und ein Mal normal, beide Varianten mit der gleichen Videodatei (480x272, 25fps, h264/aac, 43 min).glxgears war hier lediglich zum Erzeugen der cpu-Last und als Indikator für deren Schwankung gedacht [in diesem Fall ist glxgears sehr wohl als benchmark zu sehen, da es rein cpu-gebunden ist], aber insgesamt taugt es da auch nicht richtig, da der sample-Intervall für die fps-Berechnung nicht einstellbar ist. Vorgehen war also

Code: Alles auswählen

glxgears  # terminal 1
mplayer -benchmark -nosound -vo null foo.mp4 # terminal 2
mplayer foo.mp4 # terminal 3

glxgears zeigt bekanntlich nur die framerate im 5s-Takt, mplayer im benchmark-Modus spielt das Video so schnell wie möglich ohne Video- oder Audioausgabe. Jedes Mal wenn der benchmark-Modus fertig war, wurden die anderen zwei Programme angehalten und die Zeiten verglichen, die der mplayer gebraucht hat. Zusätzlich ist die fps-Ausgabe von glxgears mit erfasst worden. Jede 'Messung' dieser Zeiten wurde 3 Mal gemacht und gemittelt:

Code: Alles auswählen

            2.6.36-autogroup       2.6.36-bfs          2.6.36 (plain)
t_ges (s)        118,9                108,8                    109,3
Stdev (s)          5,8                  0,7                      2,8
load (1m)          2,4                  2,55                     2,7
glxgears (fps)    ~730                 ~810                     ~750

Das sind natürlich jetzt bewusst keine load-Werte wie die in dem lkml-thread genannten, aber die sollten für den nötigen "Druck" für den scheduler ausreichen. Überraschenderweise ist der autogroup-kernel hier der langsamste, was natürlich für die Interaktivität nicht schlecht sein muss. Schnelleres Schalten (mit geringer Latenzzeit) zwischen den Prozessen verbessert die Interaktivität, verschlechtert aber unter Umständen eben die reine Rechenleistung des einzelnen Prozesses. Insofern nichts, was jetzt vom Hocker reisst. Auch der subjektive Eindruck während der Messung war eher gleich: die vom mocp (audio-player) gespielte Musik hatte keine Aussetzer; das Video wurde auch flüssig und ohne Ruckler angezeigt, in glxgears waren auch keine Ausreißer (fps) oder Ruckler (Bild) zu sehen. Was allerdings auffällt, was auch bei früheren Einsätzen eines Kernels mit dem BFS schon zu sehen war, ist die geringere Standardabweichung bei der Laufzeit des Videos. Auch die von conky angezeigte Kurve für die cpu-Last sieht viel "glatter" aus als beim Standard-Scheduler CFS. Aus meiner Sicht werden die Leute, die über die schlechte Interaktivität des gegenwärtigen Kernels stolpern mit einem BFS-Kernel noch am meisten Freude haben, wenigsten testen sollte man das. Mir ist jetzt nicht bekannt, ob es irgendein repository mit BFS-gepatchten Kernel-Versionen für debian gibt, falls man das nicht selber bauen will, aber ich vermute, dass da bestimmt irgendwo einer so was macht.
Fragen oder Anregungen zum Testen? Falls sonst noch jemand Vorschläge für tools oder Meßgrößen hat: immer raus damit.

ciao, storm


[1] http://lkml.org/lkml/2010/11/16/298
[2] http://ck.kolivas.org/patches/bfs/

[Harakiri]

interessanter test, und nicht unaufwändig wie ich finde. anhand deines links http://ck.kolivas.org/patches/bfs/ habe ich mal einen blick in die bfs-faq.txt geworfen.

was mich erstaunt hat, ist dass bfs für den "Brain Fuck Scheduler" steht.

It was designed to be forward looking only, make the most of lower spec machines, and not scale to massive hardware. ie
it is a desktop orientated scheduler, with extremely low latencies for
excellent interactivity by design rather than "calculated", with rigid
fairness, nice priority distribution and extreme scalability within normal
load levels.

bfs kam mir irgendwie bekannt vor, und so habe ich mich an meinen zen kernel von meinen desktop rechner erinnert. im kernel seed vom zen konnte ich nämlich im unterschied zum vanilla die option wählen, dass die latenzzeit für desktopanwendungen (gefühlt) geringer sein soll. das heißt anscheinend, dass es diese methode wohl schon länger gibt?
http://zen-kernel.org/faq-folder/what_is_zen
kurzer auszug

So, in essence, the kernel gears for desktop systems by adjusting tuning knobs and merging projects that suit this purpose in one way or another (for example, the BFS cpu scheduler is added _in addition_ to the default CFS scheduler).

die latenzzeit auf meinem notebook ist spätestens immer dann offensichtlich unangenehm, wenn der desktop quasi für sekunden "einfriert", allem voran der browser und die musikwiedergabe völlig aussetzt. da bfs laut angabe eher für lowend maschinen gedacht ist, sollte sich das also gut auf mein notebook auswirken.

wenn ich am wochenende dazu komme, werde ich für das notebook auch mal einen bfs kernel ausprobieren und schauen wie es sich verhält. allerdings erwarte ich auch keine wunder, denn das system ist eben manchmal schlichtweg ausgelastet.

[mindX]

...Im Ernst: damit solltest du nix kaputt machen, also ist testen gefahrlos. Hast du irgend ein Kriterium, woran du den möglichen Erfolg des tweaks messen kannst/willst?...

Danke! Ich habs nun ausprobiert und erhalte bei Starten eines Terminals und beim Mounten von cgroup Fehlermeldungen. Insofern gehe ich davon aus, dass der tweak nicht erfolgreich war
Was ich mir gewünscht hätte wäre, dass Gnome sich von der Reaktionszeit ähnlich wie KDE3 anfühlen würde.

[Alternativende]

Hmh sobald Squeeze stable wird lässt sich der Patch ja sicherlich recht bald aus testing in Form eines Kernelupdates nachinstallieren.
Ich werde es mir dann mal ansehen, ebenso wie systemd, aber es gibt wenn ich das hier richtig verstehe keinen Grund zur Hysterie für normal User.

[Lord_Carlos]

http://marc.info/?l=linux-kernel&m=128993935321081&w=2
Ich lass das mal hier.

[Harakiri]

Ich habe jetzt seit ein paar Tagen der Zen 35er Kernel auf meinem Notebook laufen. Ohne den besagten Patch, wobei ich noch nicht einmal cgroups beim Kompilieren berücksichtigt habe.

Was der Zen Kernel jedoch hat ist bfs. Das habe ich als Standard aktiviert und habe den Eindruck, dass es dem Desktop in Sachen Latenzzeit hilft. Und es ist wohl deswegen bemerkbar, weil das Notebook öfter an seine Belastungsgrenze gerät, und die Ansprechbarkeit der geöffneten Anwendungen dabei besser ist. Bei einem Multicore-System mit vernünftiger Ramgröße dürfte bfs dagegen wohl eher nicht so ins Gewicht fallen. In diesem Zusammenhang beziehe ich mich auf storms ad hoc-test mit bfs.

Wie sich jedoch der diskutierte Patch von Linus auswirkt bleibt abzuwarten. Wenn es wirklich so wäre wie Poettering es beschreibt, dass sich diese Methode in erster Linie nur in TTY-Sitzungen bemerkbar macht, wäre das ja immerhin auch eine Verbesserung. Nur nicht so "besonders" eben.

[ralli]

Hmm, ich verfolge diese Diskussion eher mit einem schmunzeln. Es erinnert mich daran, das emsig an der Start- und Bootzeit gearbeitet wurde.[Ironie an] Klasse, da ich ja meinen Rechner 100 Mal am Tag starte, dann habe ich doch tatsächlich wertvolle Sekunden gespart[/Ironie aus]. Der tatsächliche Nutzen offenbart sich mir daher nicht wirklich. Das wäre ja fürchterlich, wenn alles läuft, dann gäbe es ja nichts mehr zum Basteln...