Wie gerade mal 200 Zeilen Code doch wieder mal eine Menge Probleme lösen können :) Freue mich schon auf Tests mit dem neuen Kernel und einer brauchbaren Distribution :p
Schade das die Infos im Artikel wieder so unvollständig sind. WELCHE Änderung bewirkt das jetzt genau? Es wäre nämlich interessant, wie sich diese Anpassung generell verhält. Ein schnellerer Desktop ist schön, allerdings sollte so eine Veränderung nicht die gesamte Industrie vergraulen, weil wichtige Hintergrundapplikationen plötzlich auf Kosten des Desktops langsamer werden.
DIESE Info ist auch aus den Links nicht zu beziehen.
Von Kernel-Kenner am Mi, 17. November 2010 um 14:37 #
Diese Infos stehen doch im Artikel drin. In den Scheduler wurden automatische Task-Gruppen implementiert. Wenn du noch mehr Infos willst, dann schaue dir die Links an. In diesen stehen alle Infos, die Du brauchst - nämlich der komplette Patch, der zu 100% alle nur erdenklichen technischen Informationen enthält.
Entschuldige, dass wir im Rahmen eines besseren Leseverständnisses nicht noch genauer auf den Patch eingehen und ihn nicht »Schritt für Schritt« erklären. Wir sind allerdings der Meinung, dass dies den Rahmen einer Nachricht sprengen würde und nur wirklich eine Minorität interessiert. Sofern du interessiert bist, so seist du noch ein mal eingeladen den oberen Link anzuklicken, in dem definitiv alle Antworten stehen – der eigentliche Patch.
Gruss, demon
Dieser Beitrag wurde 2 mal editiert. Zuletzt am 17. Nov 2010 um 14:51.
Das wäre gar nicht notwendig gewesen, ein Satz wie
"Der Scheduler verteilt nur intelligenter die Last zwischen den einzelnen Prozessen, damit sich ein System insgesamt flüssiger anfühlt. Zudem lässt sich die implementierte Funktionalität zur Laufzeit des Systems aus -und einschalten."
hätte vollkommen gereicht (Quelle: das Posting drunter). So ist die Jubel-Aussage des Artikels einfach nur "es wird alles ganz toll schneller".
Ich glaube du redest dir da etwas ein. Der von dir zitierte Text hat gar keine echte Aussage. Die Verteilung von Rechenzeit ist immer Aufgabe eines Schedulers, und da nicht wirklich erklärt ist was er nun tut, was bringt die Aussage "Ein- und Ausschalten"?
Demon hat recht, das Thema ist sehr technisch und im Detail nur für wenige Interessant. Diese sollten dem Link folgen, und sich dort in das Thema einlesen.
Zudem: Der Scheduler wurde doch in den letzten Jahren schon mehrfach ausgetauscht / optimiert, dazu gibts einen eigenen Punkt in der Linux Kernel Documentation: http://www.kernel.org/doc/#History_of_the_Linux_Process_Scheduler
Wer das also bisher nicht bemerkt hat, für den ist auch dieser Austausch nur eine von vielen Änderungen.
> Die Verteilung von Rechenzeit ist immer Aufgabe eines Schedulers, und da nicht wirklich erklärt ist was er nun tut, was bringt die Aussage "Ein- und Ausschalten"?
Die Aussage "Ein -und Ausschalten" ist aus dem Zusammenhang gerissen und Bezog sich auf die ursprüngliche Antwort meinerseits zur Frage ob die Industrie einen solchen Schritt akzeptieren würde. Da sich der Taskgruppenautomatismus sehr leicht zur Laufzeit des Systems beinflussen lässt (sprich Ein -oder Ausschalten), dürfte es damit keine Probleme geben. Es ist halt nur ein weiteres, optionales Feature.
> weil wichtige Hintergrundapplikationen plötzlich auf Kosten des Desktops langsamer werden.
Der Patch verlangsamt nichts. Der Scheduler verteilt nur intelligenter die Last zwischen den einzelnen Prozessen, damit sich ein System insgesamt flüssiger anfühlt. Zudem lässt sich die implementierte Funktionalität zur Laufzeit des Systems aus -und einschalten.
Sagen wirs mal so: Aktuelle Scheduler fühlen sich auf aktuellen Desktopsystemen besser an.
Sie sind aber mitnichten unter jedem Umstand auf jeder Hardware die beste Wahl.
Auf sehr langsamen, alten, speicherarmen oder andersartig speziellen Systemen wähle ich nach wie vor selber meinen Scheduler. Z.B. läuft auf meinem Simpad und Amiga 3000 der primitivste Scheduler mit künstlich verlängerten Schedule-Times - alle moderneren Scheduler mit normalen Zeiten erzeugen so eine Art "Lag" - auf meinem EEE ein Simple-Elevator weil damit Youtube besser läuft. Der gleiche Scheduler ist aber auf meinem Athlon wiederum Mist weil der nur einen Kern hat.
Es geht darum, dass nun jedes tty eine eigene Task Group ist, was dazu führt dass Rechenintensive KONSOLENapplikationen wie make in einer eigenen Gruppe laufen und dadurch die restlichen Anwendungen weniger beeinflussen - das trifft aber nur dann zu, wenn man die Anwendung in der Konsole gestartet hat. Das kann man auch ohne Kernel patch mit einem 5 Zeilen Eintrag in der .bashrc erreichen, für den normalen Nutzer bringt das aber gar nichts.
Von Kernelkenner am Mi, 17. November 2010 um 14:45 #
Eine theoretische Frage. Und was ist der Init? Jede Applikation ist eine Konsolen- bzw. ein Child einer Konsolenapplikation. Es spielt also keine Rolle, ob man das make in der Konsole oder unter X gestartet hat.
Von Kernel-Kenner am Mi, 17. November 2010 um 15:18 #
Ja, dafür ist ja auch der Scheduler schließlich da. Er soll die Prozesse so legen, dass sie sich nicht gegenseitig behindern oder gar stoppen. Der Linux-Kern hat aber keinen speziellen Scheduler für Konsole und X, denn auch X hat eine tty-Zuweisung. Einfach mal ps ausführen. Im Übrigen: Alle Systeme, die ohne tty-Zuweisung laufen, werden automatisch der root tast group zugewiesen. Und ja, wie Mike und Torvalds schreiben, ist der Patch vor allem für Desktop-User von besonderer Bedeutung. Also im Klartext: Für X-Anwender.
Ja es stimmt alle X-Anwendung sind in _einer_ TTY. Und das ist genau der Knackpunkt.
Dieser Patch verteilt das sheduling auf alle cgroups, Automatisch werden dises Gruppen nach ihrer tty zugewiesen.
Starteten man n Programme über die Graphische Oberfläche, laufen diese n Programme in einer Autogroup. Also alles wie bisher, jetzt auch schon.
Nun das Killer feature dieses Patches: Starte ich 2 Totem in einer Konsole (2 Tabs), Starte einen Compile Job in einer anderem Xterm, werden diese Prozesse (Und ihre Kinder) nun gleichmässig verteilt. Das geht aber nur, da jede Anwendung durch jede neue Konsole ein neues TTY erhalten hat.
Der Kernel kann schlicht und einfach Graphische Anwendungen nicht sinnvoll Groupieren. Deswegen dieser Hack auf TTY Basis, für Konsolenkämpfer. Heh wenn's geht warum nicht, ich bin mir nur nicht sicher ober sowas in den Kernel gehört. (Warum macht das nicht das gnome-terminal/Xterm?)
Das ist nicht für Desktop User, das ist für Entwickler (und Gentoo Background Compile Jobs )
Das Grundproblem ist das der Kernel einfach nicht sieht: - was eine Graphische Anwendung ist - was ein Hintergrund Daemon ist - was eine Shell session ist (nun mit dem tty-Hack, wird das abgefangen)
Das ist ein Probelm, was einfach im Kernel gelöst werden kann.
Ich bin mir nicht sicher ob dieses ganze cgroup Konzept, wirklich die richtige Lösung ist.
Aber es funktioniert (besser). Und da wir so oder so für alle nicht Konsolen Anwendungen, extra Handling brauchen - aus dem Userspace - wollen wir dieses Konzept verfolgen, warum sollten wir dann noch die Spezial Fall tty Anwendung im Kernel abfangen?
Ich sehe das genauso! Klar, dass die Kernel-Entwickler alle jubilieren, schließlich haben die immer irgendwo einen terminal offen, der grad etwas kompiliert / anderweitig last erzeugt.
Allerdings nützt es nichts für GUI Anwendungen, die ja auch sehr rechenintensiv sein können (z.B. handbrake), außer man startet sie in einem terminal (und beendet diesen nicht!!).
Siehe auch dazu diesen slashdot Beitrag: http://linux.slashdot.org/comments.pl?sid=1870628&cid=34241622
Naja, werde mal noch mehr lesen, vielleicht gibts da auch schon Ideen dazu!
Ich zitiere einfach mal einen Kommentar zu diesem Artikel :
Ja, dafür ist ja auch der Scheduler schließlich da. Er soll die Prozesse so legen, dass sie sich nicht gegenseitig behindern oder gar stoppen. Der Linux-Kern hat aber keinen speziellen Scheduler für Konsole und X, denn auch X hat eine tty-Zuweisung. Einfach mal ps ausführen. Im Übrigen: Alle Systeme, die ohne tty-Zuweisung laufen, werden automatisch der root tast group zugewiesen. Und ja, wie Mike und Torvalds schreiben, ist der Patch vor allem für Desktop-User von besonderer Bedeutung. Also im Klartext: Für X-Anwender.
Von Vater Rhein am Mi, 17. November 2010 um 22:18 #
Mit handbrake hast du dir jetzt aber mal kein gutes Beispiel rausgesucht. Das kann man leicht in einer Konsole starten (HandBrakeCLI oder so ähnlich) und den Prozess mit screen oder disown in den Hintergrund befördern nachdem man die Priorität auf "niedrigst" gestellt hat.
> Ähm nein, das wollte er so sicher nicht. > -20 stimmt schon. Tipp: Nicht alles ist das, > nach was es auf den ersten Blick aussieht.
Schwachsinn nice -n -20 ist Realtime Also genau das was man hier nicht will, nämlich dem Compiler alle Ressourcen zu geben so dass sich nichtmal mehr der Mauspfeil bewegt
"nice -n 19" startet den Prozess mit niedrigster Priorität, also sei ruhig wenn du nichts verstehst
Von Vater Rhein am Mi, 17. November 2010 um 23:00 #
Ich empfehle dir, mal die Anleitung zu lesen bevor du dümmlichts rumranzt.
info coreutils 'nice invocation'
Und danach liest du nochmal das monierte Posting durch und wirst sehen, dass "nice -20" das gleiche ist wie "nice -n 20" --> aber mein Hinweis, dass manche Dinge nicht das sind, nach was sie aussehen, scheint dir wohl ebenso abhanden gekommen zu sein wie dein Anstand.
Ach ja, noch ein Tipp da du es nicht alleine finden wirst: Steht unter "obsolete syntax".
On Sun, Nov 14, 2010 at 5:13 PM, Mike Galbraith wrote: > > Which is what I just did. If the oddball case isn't a big deal, the > patch shrinks, which is a good thing. I just wanted to cover all bases.
Yeah. And I have to say that I'm (very happily) surprised by just how small that patch really ends up being, and how it's not intrusive or ugly either.
I'm also very happy with just what it does to interactive performance. Admittedly, my "testcase" is really trivial (reading email in a web-browser, scrolling around a bit, while doing a "make -j64" on the kernel at the same time), but it's a test-case that is very relevant for me. And it is a _huge_ improvement.
It's an improvement for things like smooth scrolling around, but what I found more interesting was how it seems to really make web pages load a lot faster. Maybe it shouldn't have been surprising, but I always associated that with network performance. But there's clearly enough of a CPU load when loading a new web page that if you have a load average of 50+ at the same time, you _will_ be starved for CPU in the loading process, and probably won't get all the http requests out quickly enough.
So I think this is firmly one of those "real improvement" patches. Good job. Group scheduling goes from "useful for some specific server loads" to "that's a killer feature".
Von Freerunner_gast am Mi, 17. November 2010 um 17:38 #
Laut Twittermeldung des Android Kernelhackers @IntersectRaven ist der eigentliche Patch für 2.6.38, es gäbe allerdings schon Backports (unter anderem einen auf seinen eigenen Nexus One Kernelrelease 2.6.35.8).
Theoretisch ja. Der Patch ändert nicht soviel am Code. Ich habe z.B. für den Backport auf 2.6.36 nur zwei kleine Fehler korrigieren müssen. Dauerte nur eine Minute.
Probiere den Patch für 2.6.36 einfach mal auf den Quellcode des Ubuntu-Kernels aus.
Von Schlangenöl am Mi, 17. November 2010 um 21:24 #
unter anderem einen auf seinen eigenen Nexus One Kernelrelease 2.6.35.8 Was soll das bringen? Auf dem Telefon hat man doch normalerweise nicht mehre Konsolen offen oO
Von erdalronahi am Mi, 17. November 2010 um 21:24 #
Dieser .bashrc-Eintrag macht mein System tatsächlich erheblich flüssiber, besonders den Browser. Könntest Du mal erläutern, was das macht und wieso das die gleiche Wirkung haben soll, wie dieser Kernel-Patch?
Der gestartete Bash und seine Kinder laufen in einer eigenen Cgroup; dein Browser (und alle anderen X-Anwendungen) laufen in der Root-Cgroup. Der Sheduler verteilt nun fair zwischen diesen beiden Gruppen. Der Browser fühlt sich flüssiger an, da er im einfachsten Fall (ein Browser + ein Bash mit make -j 64) 50% vom Kuchen bekommt, der Make-Job mit seinen 64 Kindern aber auch 50% (auf 64 Kinder verteilt).
Achtung diese Bash Eintrag räumt nach Terminierung der Shell, nicht hinter sich auf. Auf LKML ist ein erweitertes Skript zu finden, das dies erledigt. Dieses Skript sollte aber nur als Demo angesehen werden, Alltags tauglich ist das nicht.
Etwas OT: Mich wuerde mal interessieren, woran es liegt (Software- oder Hardware-Architektur), dass IO-Hardware das System teilweise komplett lahmlegt. Z.B. Aktuelles Archlinux, Standard-Kernel, Phenom2 Quadcore ist komplett traege, wenn ich mein DVD- oder Bluray-Laufwerk nutze. Woran liegt das und ist sowas software-technisch ueberhaupt in den Griff zu kriegen?
Interessiert mich auch. Brennend. Weil es unheimlich stört. Oder wird das mit diesem Patch auch erledigt? (Mit dem genauen Zusammenspiel von CPU und IO kenn ich mich nicht aus).
SATA oder IDE? gib mal dmesg in einer Konsole ein oder tail -f /var/log/messages! hdparm und sdparm können helfen ob evtl. das Laufwerk im PIO Mode und nicht DMA benutzt.
Diese Probleme hatte ich früher auch (SuSE 9.x), bei aktuellen Distris hab ich so ein Problem nicht mehr gesehen. Das liegt aber auch am Kernel/IO Scheduling und laut diversen Aussagen an den Laufwerken/Firmware selber. Ich selber hab hier 1x opensuse 11.3 und ubuntu 10.04 LTS am laufen.
ne dma wird bei mir schon benutzt, aber dennoch scheints halt irgendwo einen flaschenhals zu sein, wobei ich nicht weiss, inwieweit ein betriebssystem da was ausrichten kann oder es z.b. einfach an der hardwarearchitektur liegt... das problem tritt auch unter windows auf, was allerdings noch kein nachweis dafuer ist, dass es mit softwaremitteln alleine nicht zu beheben ist
Auch unter Win? Ja dann kann es ja auch an deiner Hardware Config liegen! Check mal dein BIOS auf Updates oder die Firmware des Laufwerk. Falls IDE, ist das Laufwerk an das gleiche Kabel wie deine Festplatte?
Der Entwickler ist jetzt mächtig stolz; ich kenne das Gefühl, wenn man durch eine richtig durfte Idee das Gesamtsystem stark verbessert.
Das grandiose hierbei ist: Der Status quo ist ja schon gut und wesentlich besser als bei Windows. Wenn es jetzt noch besser wird, kann Microsoft ganz einpacken.
Also Microsoft wird sicher noch nicht die Knie schlottern. Es muss noch viel passieren, damit Linux auf dem Desktop seine Verbreitung stärker ausbauen kann. Nur, dass es besser ist (nach unserer Meinung zumindest ;-)), reicht halt nicht aus, damit User, deren Lebensmittelpunkt nicht der Rechner ist, umschwenken. Aber falls die nächsten Kerneländerungen und besonders der Patch auch nur annähernd halten, was sie versprechen (man ließt gegenwärtig von Wunderdingen, die der Patch vollbringen soll), besitzt die ganze Geschichte schon einen gewissen Charme. Mein aktuelles Ubuntu hat ein spürbar höheres Arbeitstempo als ein Windows 7. Messbar sogar beispielsweise beim Peacekeeper Browser Benchmark, bei dem ich mit der gleichen Chrome Version auf dem gleichen Rechner bei Ubuntu weit über 1000 Punkte mehr erreiche als bei Windows. Falls die Arbeitsgeschwindigkeit wirklich dermaßen rapide ansteigt, ist es sicherlich eine schelmische Freude, den Unwissenden (Leute die Windows benutzen und noch nie von Linux gehört haben) den Satz hinzuwerfen: "Hey, probier das mal aus." und das gefühlte Resultat ist, als ob der Rechner ein gewaltiges Hardwareupgrade bekommen hat. Dabei ist es nur ein kostenloses Betriebssystem.
Ich gebe zu, dass sich das alles sehr toll anhört und auch ich erst einmal begeistert war. Allerdings habe ich den Thread auf der Linux-Kernel-Mailingliste durchgelesen und dort wird (wie schon oben beschrieben) zu recht hingewiesen, dass sich für den "Normaluser", der keine Konsolenfenster offen hat, nicht viel (besser gesagt gar nichts) ändern wird. Trotzdem ist der Patch natürlich nicht nutzlos und sicher sinnvoll; nämlich genau für solche Leute, die rechenintensive Programme per Konsole starten. Wunder sollte man als "Normaluser" aber nicht erwarten.
In welchem Thread soll es stehen? In dem, in dem ich gelesen habe wurde nämlich von allen genau der Gegenteil behauptet. Weiter oben steht auch geschrieben, warum. Und noch weiter oben ist ein Video, in dem man sieht, dass der Patch gerade bei Normalusern für Verbesserung sorgt.
In diesem Thread steht es. Er ist leider recht lang und man braucht einige Zeit um an die interessanten Stellen zu kommen. Und man muss die persönlichen Flames überlesen.
Das mit dem Video bestätigt nur meine Aussage. Dort wird ein "make -j64" (oder ähnlich) in einem Konsolenfenster gestartet. Dann macht der Patch wirklich Sinn! Würdest du stattdessen eine rechenintensive (GUI-)Software aufrufen, die z.B. ein Video recodiert, dann wirst du keine Vorteile haben. Er schadet dann aber auch nicht.
Bei deinem Verweis auf oben weiß ich nicht genau was du meinst. Evt. das mit Init und Child-Prozesse? Ein kleiner Auszug aus "ps fax":
1 ? Ss 0:00 init [5] 2464 ? S 0:00 /bin/sh /usr/bin/firefox 7111 pts/0 Ss 0:00 /bin/bash
An der 2. Spalte sieht man, dass init oder firefox mitnichten in einem eigenen tty laufen, im Gegensatz zum Prozess 7111.
Also das ist ja jetzt Blödsinn. Es ist doch völlig irrelevant, ob ein Befehl im Terminal ausgeführt wird oder man für einen Befehl ne schöne GUI drüber programmiert. Macht keinen Unterschied bei der Geschichte, um was es hier geht. Ein Prozessor (bzw. ein Prozessorkern) kann nun mal gleichzeitig nur eine Aufgabe erledigen. Bei mehreren Prozessen werden die Fragmente verschiedener Prozesse hintereinander ausgeführt. Der Patch sorgt dafür, dass das besser organisiert wird. Und ob GUI oder nicht ist dem Betriebssystem wirklich sch... egal.
Ja es stimmt alle X-Anwendung sind in _einer_ TTY. Und das ist genau der Knackpunkt.
Dieser Patch verteilt das sheduling auf alle cgroups, Automatisch werden dises Gruppen nach ihrer tty zugewiesen.
Starteten man n Programme über die Graphische Oberfläche, laufen diese n Programme in einer Autogroup. Also alles wie bisher, jetzt auch schon.
Nun das Killer feature dieses Patches: Starte ich 2 Totem in einer Konsole (2 Tabs), Starte einen Compile Job in einer anderem Xterm, werden diese Prozesse (Und ihre Kinder) nun gleichmässig verteilt. Das geht aber nur, da jede Anwendung durch jede neue Konsole ein neues TTY erhalten hat.
Der Kernel kann schlicht und einfach Graphische Anwendungen nicht sinnvoll Groupieren. Deswegen dieser Hack auf TTY Basis, für Konsolenkämpfer. Heh wenn's geht warum nicht, ich bin mir nur nicht sicher ober sowas in den Kernel gehört. (Warum macht das nicht das gnome-terminal/Xterm?)
Das ist nicht für Desktop User, das ist für Entwickler (und Gentoo Background Compile Jobs )
Ich probiere den patch jetzt nochmals auf dem Desktop aus (auf meinem Handy läuft er seit dem 16.11.2010 dank IntersectRaven Kernel) - und da bringt er ordentlich was.
Naja, ich weiß nicht ob sich BFS sooo warm anziehen muss. Irgendwie halte ich den BFS scheduler für den "gründlicheren" Ansatz, da er einfach wesentlich einfacher aufgebaut ist als CFS und niedrige Latenz "by design" ermöglicht.
Mache ich auch, sobald ich wieder zu Hause eingetroffen bin. Anbei: Ich hab gerade nochmal kurz den gleichen Kernel mit BFS Scheduler geflashed und - obwohl sched autosched eine wahnsinnig gute Performance gegenüber dem konventionellen CFS bietet - ist der BFS nochmal gefühlt geschmeidiger (Homescreen Swype mit aktiviertem NexusKang LWP). Vielleicht bin ich aber auch nur ein wenig voreingenommen.
Dieser Beitrag wurde 1 mal editiert. Zuletzt am 18. Nov 2010 um 14:53.
Torvalds ist von dem Patch natürlich begeistert, da sich bei ihm sichtbare Verbesserungen zeigen. Das ist ja auch kein Wunder, denn er lässt ja ganz bestimmt meistens irgendwelche Kernel im Hintergrund kompilieren, was sein Rechnersystem massiv beansprucht und seinen Desktop beim Internetsurfen und Emailen entsprechend verlangsamt. Nur: Welcher Desktopnutzer hat normalerweise ein derartiges Nutzerprofil? Siehe hierzu u.a.: http://marc.info/?l=linux-kernel&m=128993935321081&w=2 Ich bin hier auf diese Argumente aufmerksam geworden: http://debianforum.de/forum/viewtopic.php?f=33&t=124909#p798104 Siehe auch Blubbs obigen Kommentar.
Von hans wurrst am Di, 23. November 2010 um 02:09 #
Also ich schaffe es alleine durch surfen im Internet meinen Rechner in die Knie zu zwingen. Top-Verbraucher sind Flash, insbesondere durch Flash-Werbung und viele offene Tabs...
Oder was ist mit Indexdiensten, zB updatedb oder andere lokale Suchdienste für Dateien? Wenn die einmal anfangen zu rödeln, können Single-Processor-Systeme schonmal für eine Zeit nahezu unbenutzbar werden.
Aber klar, wenn man nie hohe Auslastungen hat, wird der Patch wahrscheinlich nur begrenzte Relevanz haben...
Dieser Patch wird Dir im Hinblick auf Dein eigenes Nutzungsszenario nicht helfen könen. Siehe http://marc.info/?l=linux-kernel&m=128993935321081&w=2 (Der Link wurde oben schon angegeben.) "(...) Well, this feature is pretty much interesting only for kernel hackers anyway. It is completely irrelevant for normal desktop people. Because a) normal users don't use many terminals anyway and that very seldom and b) if they do that they do not create gazillion of processes from one of the terminals and only very few in the other. Because only then this patch becomes relevant. (...)"
See my other response. You don't care AT ALL, because by your judgement, all desktop is is a web browser and a word processor.
So why are you even discussing this? It's irrelevant for you. cgroups will _never_ matter for what you are talking about, and that has nothing to do with ttys, automation, scripting or anything else.
Because your definition of "desktop" seems to be "only interactive apps". So this i all irrelevant.
Which is fine by me. It's not what the patch is supposed to affect.
Da kann man sich sehr freuen.
Ich auch! Das dürfte meinem "Veteranen" hier einen gehörigen Geschwindigkeitsschub verpassen (z. B. beim Webradio mitschneiden)!
Grueße
Ignatz
Wie gerade mal 200 Zeilen Code doch wieder mal eine Menge Probleme lösen können :)
Freue mich schon auf Tests mit dem neuen Kernel und einer brauchbaren Distribution :p
T-Virus
Es gibt einige lästige "Papercuts", die man darauf zurückführen kann und die mit dem Patch der Vergangenheit angehören könnten.
Bei mir ruckeln z.B. Videos leicht, wenn ich Hintergrund irgendwas läuft oder auch nur, wenn man den Fensterfokus wechselt.
Hätte den Patch lieber heute als morgen
Schade das die Infos im Artikel wieder so unvollständig sind. WELCHE Änderung bewirkt das jetzt genau? Es wäre nämlich interessant, wie sich diese Anpassung generell verhält. Ein schnellerer Desktop ist schön, allerdings sollte so eine Veränderung nicht die gesamte Industrie vergraulen, weil wichtige Hintergrundapplikationen plötzlich auf Kosten des Desktops langsamer werden.
DIESE Info ist auch aus den Links nicht zu beziehen.
Diese Infos stehen doch im Artikel drin. In den Scheduler wurden automatische Task-Gruppen implementiert. Wenn du noch mehr Infos willst, dann schaue dir die Links an. In diesen stehen alle Infos, die Du brauchst - nämlich der komplette Patch, der zu 100% alle nur erdenklichen technischen Informationen enthält.
Entschuldige, dass wir im Rahmen eines besseren Leseverständnisses nicht noch genauer auf den Patch eingehen und ihn nicht »Schritt für Schritt« erklären. Wir sind allerdings der Meinung, dass dies den Rahmen einer Nachricht sprengen würde und nur wirklich eine Minorität interessiert. Sofern du interessiert bist, so seist du noch ein mal eingeladen den oberen Link anzuklicken, in dem definitiv alle Antworten stehen – der eigentliche Patch.
Gruss,
Dieser Beitrag wurde 2 mal editiert. Zuletzt am 17. Nov 2010 um 14:51.demon
Das wäre gar nicht notwendig gewesen, ein Satz wie
"Der Scheduler verteilt nur intelligenter die Last zwischen den einzelnen Prozessen, damit sich ein System insgesamt flüssiger anfühlt. Zudem lässt sich die implementierte Funktionalität zur Laufzeit des Systems aus -und einschalten."
hätte vollkommen gereicht (Quelle: das Posting drunter). So ist die Jubel-Aussage des Artikels einfach nur "es wird alles ganz toll schneller".
Ich glaube du redest dir da etwas ein. Der von dir zitierte Text hat gar keine echte Aussage. Die Verteilung von Rechenzeit ist immer Aufgabe eines Schedulers, und da nicht wirklich erklärt ist was er nun tut, was bringt die Aussage "Ein- und Ausschalten"?
Demon hat recht, das Thema ist sehr technisch und im Detail nur für wenige Interessant. Diese sollten dem Link folgen, und sich dort in das Thema einlesen.
Zudem: Der Scheduler wurde doch in den letzten Jahren schon mehrfach ausgetauscht / optimiert, dazu gibts einen eigenen Punkt in der Linux Kernel Documentation: http://www.kernel.org/doc/#History_of_the_Linux_Process_Scheduler
Wer das also bisher nicht bemerkt hat, für den ist auch dieser Austausch nur eine von vielen Änderungen.
> Die Verteilung von Rechenzeit ist immer Aufgabe eines Schedulers, und da nicht wirklich erklärt ist was er nun tut, was bringt die Aussage "Ein- und Ausschalten"?
Die Aussage "Ein -und Ausschalten" ist aus dem Zusammenhang gerissen und Bezog sich auf die ursprüngliche Antwort meinerseits zur Frage ob die Industrie einen solchen Schritt akzeptieren würde. Da sich der Taskgruppenautomatismus sehr leicht zur Laufzeit des Systems beinflussen lässt (sprich Ein -oder Ausschalten), dürfte es damit keine Probleme geben. Es ist halt nur ein weiteres, optionales Feature.
> weil wichtige Hintergrundapplikationen plötzlich auf Kosten des Desktops langsamer werden.
Der Patch verlangsamt nichts. Der Scheduler verteilt nur intelligenter die Last zwischen den einzelnen Prozessen, damit sich ein System insgesamt flüssiger anfühlt. Zudem lässt sich die implementierte Funktionalität zur Laufzeit des Systems aus -und einschalten.
> Der Patch verlangsamt nichts.
Sagen wirs mal so: Aktuelle Scheduler fühlen sich auf aktuellen Desktopsystemen besser an.
Sie sind aber mitnichten unter jedem Umstand auf jeder Hardware die beste Wahl.
Auf sehr langsamen, alten, speicherarmen oder andersartig speziellen Systemen wähle ich nach wie vor selber meinen Scheduler. Z.B. läuft auf meinem Simpad und Amiga 3000 der primitivste Scheduler mit künstlich verlängerten Schedule-Times - alle moderneren Scheduler mit normalen Zeiten erzeugen so eine Art "Lag" - auf meinem EEE ein Simple-Elevator weil damit Youtube besser läuft. Der gleiche Scheduler ist aber auf meinem Athlon wiederum Mist weil der nur einen Kern hat.
Es geht darum, dass nun jedes tty eine eigene Task Group ist, was dazu führt dass Rechenintensive KONSOLENapplikationen wie make in einer eigenen Gruppe laufen und dadurch die restlichen Anwendungen weniger beeinflussen - das trifft aber nur dann zu, wenn man die Anwendung in der Konsole gestartet hat.
Das kann man auch ohne Kernel patch mit einem 5 Zeilen Eintrag in der .bashrc erreichen, für den normalen Nutzer bringt das aber gar nichts.
Eine theoretische Frage. Und was ist der Init? Jede Applikation ist eine Konsolen- bzw. ein Child einer Konsolenapplikation. Es spielt also keine Rolle, ob man das make in der Konsole oder unter X gestartet hat.
Da ging es wohl nur darum das System CPU/Prozess/Thread mäßig auszulasten
Ja, dafür ist ja auch der Scheduler schließlich da. Er soll die Prozesse so legen, dass sie sich nicht gegenseitig behindern oder gar stoppen. Der Linux-Kern hat aber keinen speziellen Scheduler für Konsole und X, denn auch X hat eine tty-Zuweisung. Einfach mal ps ausführen. Im Übrigen: Alle Systeme, die ohne tty-Zuweisung laufen, werden automatisch der root tast group zugewiesen. Und ja, wie Mike und Torvalds schreiben, ist der Patch vor allem für Desktop-User von besonderer Bedeutung. Also im Klartext: Für X-Anwender.
Ja es stimmt alle X-Anwendung sind in _einer_ TTY. Und das ist genau der Knackpunkt.
Dieser Patch verteilt das sheduling auf alle cgroups, Automatisch werden dises Gruppen nach ihrer tty zugewiesen.
Starteten man n Programme über die Graphische Oberfläche, laufen diese n Programme in einer Autogroup. Also alles wie bisher, jetzt auch schon.
Nun das Killer feature dieses Patches: Starte ich 2 Totem in einer Konsole (2 Tabs), Starte einen Compile Job in einer anderem Xterm, werden diese Prozesse (Und ihre Kinder) nun gleichmässig verteilt. Das geht aber nur, da jede Anwendung durch jede neue Konsole ein neues TTY erhalten hat.
Der Kernel kann schlicht und einfach Graphische Anwendungen nicht sinnvoll Groupieren. Deswegen dieser Hack auf TTY Basis, für Konsolenkämpfer. Heh wenn's geht warum nicht, ich bin mir nur nicht sicher ober sowas in den Kernel gehört. (Warum macht das nicht das gnome-terminal/Xterm?)
Das ist nicht für Desktop User, das ist für Entwickler (und Gentoo Background Compile Jobs
)
Weil Zeitscheibenmanagement Aufgabe des Kernel ist. Mal ganz abgesehen davon dass sowas nicht in eine Termapp gehört.
Der Sheduler bleibt doch was er ist.
Das Grundproblem ist das der Kernel einfach nicht sieht:
- was eine Graphische Anwendung ist
- was ein Hintergrund Daemon ist
- was eine Shell session ist (nun mit dem tty-Hack, wird das abgefangen)
Das ist ein Probelm, was einfach im Kernel gelöst werden kann.
Ich bin mir nicht sicher ob dieses ganze cgroup Konzept, wirklich die richtige Lösung ist.
Aber es funktioniert (besser). Und da wir so oder so für alle nicht Konsolen Anwendungen, extra Handling brauchen - aus dem Userspace - wollen wir dieses Konzept verfolgen, warum sollten wir dann noch die Spezial Fall tty Anwendung im Kernel abfangen?
Ich sehe das genauso! Klar, dass die Kernel-Entwickler alle jubilieren, schließlich haben die immer irgendwo einen terminal offen, der grad etwas kompiliert / anderweitig last erzeugt.
Allerdings nützt es nichts für GUI Anwendungen, die ja auch sehr rechenintensiv sein können (z.B. handbrake), außer man startet sie in einem terminal (und beendet diesen nicht!!).
Siehe auch dazu diesen slashdot Beitrag:
http://linux.slashdot.org/comments.pl?sid=1870628&cid=34241622
Naja, werde mal noch mehr lesen, vielleicht gibts da auch schon Ideen dazu!
Ich zitiere einfach mal einen Kommentar zu diesem Artikel :
Ja, dafür ist ja auch der Scheduler schließlich da. Er soll die Prozesse so legen, dass sie sich nicht gegenseitig behindern oder gar stoppen. Der Linux-Kern hat aber keinen speziellen Scheduler für Konsole und X, denn auch X hat eine tty-Zuweisung. Einfach mal ps ausführen. Im Übrigen: Alle Systeme, die ohne tty-Zuweisung laufen, werden automatisch der root tast group zugewiesen. Und ja, wie Mike und Torvalds schreiben, ist der Patch vor allem für Desktop-User von besonderer Bedeutung. Also im Klartext: Für X-Anwender.
Mit handbrake hast du dir jetzt aber mal kein gutes Beispiel rausgesucht. Das kann man leicht in einer Konsole starten (HandBrakeCLI oder so ähnlich) und den Prozess mit screen oder disown in den Hintergrund befördern nachdem man die Priorität auf "niedrigst" gestellt hat.
man kann ihn auch einfach manuell in eine cgroup stecken..
mir ist schon klar, dass "man" es kann (genauso wie manuelle cgroups), aber hier ging es ja darum, dass es automatisch passiert...
> Es geht darum, dass nun jedes tty eine eigene Task Group
Dann hätte es doch auch gereicht den make-Aufruf mit nice zu starten...
nice -20 make -j64 ruckelt bei mir nichtmal aufm Amiga.
Ich nehme an du wolltest:
nice +20 make -j64
denn -20 würde bedeuten du möchtest, dass make hier die höchste Prio erhält, siehe nice man page oder auch:
http://en.wikipedia.org/wiki/Nice_%28Unix%29
Ähm nein, das wollte er so sicher nicht. -20 stimmt schon. Tipp: Nicht alles ist das, nach was es auf den ersten Blick aussieht.
> Ähm nein, das wollte er so sicher nicht.
> -20 stimmt schon. Tipp: Nicht alles ist das,
> nach was es auf den ersten Blick aussieht.
Schwachsinn nice -n -20 ist Realtime
Also genau das was man hier nicht will, nämlich dem Compiler alle Ressourcen zu geben so dass sich nichtmal mehr der Mauspfeil bewegt
"nice -n 19" startet den Prozess mit niedrigster Priorität, also sei ruhig wenn du nichts verstehst
Ich empfehle dir, mal die Anleitung zu lesen bevor du dümmlichts rumranzt.
info coreutils 'nice invocation'
Und danach liest du nochmal das monierte Posting durch und wirst sehen, dass "nice -20" das gleiche ist wie "nice -n 20" --> aber mein Hinweis, dass manche Dinge nicht das sind, nach was sie aussehen, scheint dir wohl ebenso abhanden gekommen zu sein wie dein Anstand.
Ach ja, noch ein Tipp da du es nicht alleine finden wirst: Steht unter "obsolete syntax".
Es gibt keinen Nice-Wert von +20! Bei 19 ist bereits Schluß.
Hier ein Auszug aus "man 1 nice"
Nicenesses range from -20 (most favorable scheduling) to 19 (least favorable).
Was bedeutet, dass die 20 intern als 19 behandelt werden. Wayne?
..dann wartet das System noch länger auf Benutzereingaben als vorher:-)
Hier gibt es ein Video, wo man den signifikaten Performanceschub sieht http://www.phoronix.com/scan.php?page=article&item=linux_2637_video&num=2
Wenn ich schon den Domain-Namen sehe weiss ich schon: Das kann nur Müll sein
Okay, die Nachricht stammt von Phoronix. Aber wenn schon Linus Torvalds selbst von dem Patch begeistert ist, dann wird das Teil ja wohl was bringen :
http://marc.info/?l=linux-kernel&m=128979084506774&w=2
On Sun, Nov 14, 2010 at 5:13 PM, Mike Galbraith wrote:
>
> Which is what I just did. If the oddball case isn't a big deal, the
> patch shrinks, which is a good thing. I just wanted to cover all bases.
Yeah. And I have to say that I'm (very happily) surprised by just how
small that patch really ends up being, and how it's not intrusive or
ugly either.
I'm also very happy with just what it does to interactive performance.
Admittedly, my "testcase" is really trivial (reading email in a
web-browser, scrolling around a bit, while doing a "make -j64" on the
kernel at the same time), but it's a test-case that is very relevant
for me. And it is a _huge_ improvement.
It's an improvement for things like smooth scrolling around, but what
I found more interesting was how it seems to really make web pages
load a lot faster. Maybe it shouldn't have been surprising, but I
always associated that with network performance. But there's clearly
enough of a CPU load when loading a new web page that if you have a
load average of 50+ at the same time, you _will_ be starved for CPU in
the loading process, and probably won't get all the http requests out
quickly enough.
So I think this is firmly one of those "real improvement" patches.
Good job. Group scheduling goes from "useful for some specific server
loads" to "that's a killer feature".
Linus
Weiß schon jemand in welchen Kernel das implementiert wird? Oder wird man diesen patch selbst irgendwie kompilieren müssen?
Ich hab gelesen, dass es wahrscheinlich der 2.6.38 werden soll... aber vielleicht weiss hier jemand was genaues.
Laut Twittermeldung des Android Kernelhackers @IntersectRaven ist der eigentliche Patch für 2.6.38, es gäbe allerdings schon Backports (unter anderem einen auf seinen eigenen Nexus One Kernelrelease 2.6.35.8).
Ich habe den Patch auch mal auf 2.6.36 zurückportiert :
http://www.glasen-hardt.de/wp-content/uploads/2010/11/sched_automated_per_tty_task_groups_2.6.36.patch
Was heißt das genau? Kann ich den Patch auch für mein aktuelles Ubuntu haben? Wäre ja ne coole Sache.
Theoretisch ja. Der Patch ändert nicht soviel am Code. Ich habe z.B. für den Backport auf 2.6.36 nur zwei kleine Fehler korrigieren müssen. Dauerte nur eine Minute.
Probiere den Patch für 2.6.36 einfach mal auf den Quellcode des Ubuntu-Kernels aus.
gentoo linux-2.6.36-pf1 # patch -p1 < ../patch-2.6.36.diff
patching file Documentation/kernel-parameters.txt
patching file drivers/char/tty_io.c
patching file include/linux/sched.h
Hunk #1 succeeded at 510 (offset 4 lines).
Hunk #2 succeeded at 579 (offset 4 lines).
Hunk #3 succeeded at 1990 (offset 85 lines).
patching file init/Kconfig
Hunk #1 succeeded at 665 (offset 13 lines).
patching file kernel/fork.c
patching file kernel/sched_autogroup.c
patching file kernel/sched_autogroup.h
patching file kernel/sched.c
Hunk #1 succeeded at 81 (offset 3 lines).
Hunk #2 succeeded at 616 (offset 3 lines).
Hunk #3 succeeded at 1927 (offset 3 lines).
Hunk #4 succeeded at 7757 (offset 3 lines).
Hunk #5 succeeded at 8287 (offset 3 lines).
Hunk #6 succeeded at 8312 (offset 3 lines).
patching file kernel/sysctl.c
Hunk #1 FAILED at 384.
1 out of 1 hunk FAILED -- saving rejects to file kernel/sysctl.c.rej
unter anderem einen auf seinen eigenen Nexus One Kernelrelease 2.6.35.8
Was soll das bringen? Auf dem Telefon hat man doch normalerweise nicht mehre Konsolen offen oO
Eine Konsole und dann make -j1001 oder halt 1001 mal make& reicht.
alternativ kannst du auch einfach
if [ "$PS1" ] ; then
mkdir -m 0700 -p /cgroup/cpu/$$
echo 1 > /cgroup/cpu/$$/notify_on_release
echo $$ > /cgroup/cpu/$$/tasks
fi
zu deiner .bashrc hinzufügen, tut das gleiche.
Dieser .bashrc-Eintrag macht mein System tatsächlich erheblich flüssiber, besonders den Browser. Könntest Du mal erläutern, was das macht und wieso das die gleiche Wirkung haben soll, wie dieser Kernel-Patch?
Würde mich auch interessieren!
Danke
Der gestartete Bash und seine Kinder laufen in einer eigenen Cgroup; dein Browser (und alle anderen X-Anwendungen) laufen in der Root-Cgroup. Der Sheduler verteilt nun fair zwischen diesen beiden Gruppen. Der Browser fühlt sich flüssiger an, da er im einfachsten Fall (ein Browser + ein Bash mit make -j 64) 50% vom Kuchen bekommt, der Make-Job mit seinen 64 Kindern aber auch 50% (auf 64 Kinder verteilt).
Achtung diese Bash Eintrag räumt nach Terminierung der Shell, nicht hinter sich auf. Auf LKML ist ein erweitertes Skript zu finden, das dies erledigt. Dieses Skript sollte aber nur als Demo angesehen werden, Alltags tauglich ist das nicht.
Hier der komplette Beitrag
..
Etwas OT:
Mich wuerde mal interessieren, woran es liegt (Software- oder Hardware-Architektur), dass IO-Hardware das System teilweise komplett lahmlegt.
Z.B. Aktuelles Archlinux, Standard-Kernel, Phenom2 Quadcore ist komplett traege, wenn ich mein DVD- oder Bluray-Laufwerk nutze. Woran liegt das und ist sowas software-technisch ueberhaupt in den Griff zu kriegen?
Interessiert mich auch. Brennend. Weil es unheimlich stört. Oder wird das mit diesem Patch auch erledigt? (Mit dem genauen Zusammenspiel von CPU und IO kenn ich mich nicht aus).
der Patch bezieht Gruppiert lediglich Programme auf einem tty, die IO Sitiation wird sich dadurch nicht verbessern.
SATA oder IDE? gib mal dmesg in einer Konsole ein oder tail -f /var/log/messages! hdparm und sdparm können helfen ob evtl. das Laufwerk im PIO Mode und nicht DMA benutzt.
Diese Probleme hatte ich früher auch (SuSE 9.x), bei aktuellen Distris hab ich so ein Problem nicht mehr gesehen. Das liegt aber auch am Kernel/IO Scheduling und laut diversen Aussagen an den Laufwerken/Firmware selber. Ich selber hab hier 1x opensuse 11.3 und ubuntu 10.04 LTS am laufen.
Auf jeden Fall mehr Infos
ne dma wird bei mir schon benutzt, aber dennoch scheints halt irgendwo einen flaschenhals zu sein, wobei ich nicht weiss, inwieweit ein betriebssystem da was ausrichten kann oder es z.b. einfach an der hardwarearchitektur liegt...
das problem tritt auch unter windows auf, was allerdings noch kein nachweis dafuer ist, dass es mit softwaremitteln alleine nicht zu beheben ist
Die haben zu .36 und .37 eine Menge IO-Flaschenhälse weg bekommen. Vielleicht bringt das ja schon etwas.
Auch unter Win? Ja dann kann es ja auch an deiner Hardware Config liegen! Check mal dein BIOS auf Updates oder die Firmware des Laufwerk. Falls IDE, ist das Laufwerk an das gleiche Kabel wie deine Festplatte?
Der Entwickler ist jetzt mächtig stolz; ich kenne das Gefühl, wenn man durch eine richtig durfte Idee das Gesamtsystem stark verbessert.
Das grandiose hierbei ist: Der Status quo ist ja schon gut und wesentlich besser als bei Windows. Wenn es jetzt noch besser wird, kann Microsoft ganz einpacken.
Also Microsoft wird sicher noch nicht die Knie schlottern. Es muss noch viel passieren, damit Linux auf dem Desktop seine Verbreitung stärker ausbauen kann. Nur, dass es besser ist (nach unserer Meinung zumindest ;-)), reicht halt nicht aus, damit User, deren Lebensmittelpunkt nicht der Rechner ist, umschwenken.
Aber falls die nächsten Kerneländerungen und besonders der Patch auch nur annähernd halten, was sie versprechen (man ließt gegenwärtig von Wunderdingen, die der Patch vollbringen soll), besitzt die ganze Geschichte schon einen gewissen Charme. Mein aktuelles Ubuntu hat ein spürbar höheres Arbeitstempo als ein Windows 7. Messbar sogar beispielsweise beim Peacekeeper Browser Benchmark, bei dem ich mit der gleichen Chrome Version auf dem gleichen Rechner bei Ubuntu weit über 1000 Punkte mehr erreiche als bei Windows. Falls die Arbeitsgeschwindigkeit wirklich dermaßen rapide ansteigt, ist es sicherlich eine schelmische Freude, den Unwissenden (Leute die Windows benutzen und noch nie von Linux gehört haben) den Satz hinzuwerfen: "Hey, probier das mal aus." und das gefühlte Resultat ist, als ob der Rechner ein gewaltiges Hardwareupgrade bekommen hat. Dabei ist es nur ein kostenloses Betriebssystem.
Ich gebe zu, dass sich das alles sehr toll anhört und auch ich erst einmal begeistert war. Allerdings habe ich den Thread auf der Linux-Kernel-Mailingliste durchgelesen und dort wird (wie schon oben beschrieben) zu recht hingewiesen, dass sich für den "Normaluser", der keine Konsolenfenster offen hat, nicht viel (besser gesagt gar nichts) ändern wird. Trotzdem ist der Patch natürlich nicht nutzlos und sicher sinnvoll; nämlich genau für solche Leute, die rechenintensive Programme per Konsole starten. Wunder sollte man als "Normaluser" aber nicht erwarten.
In welchem Thread soll es stehen? In dem, in dem ich gelesen habe wurde nämlich von allen genau der Gegenteil behauptet. Weiter oben steht auch geschrieben, warum. Und noch weiter oben ist ein Video, in dem man sieht, dass der Patch gerade bei Normalusern für Verbesserung sorgt.
In diesem Thread steht es. Er ist leider recht lang und man braucht einige Zeit um an die interessanten Stellen zu kommen. Und man muss die persönlichen Flames überlesen.
Das mit dem Video bestätigt nur meine Aussage. Dort wird ein "make -j64" (oder ähnlich) in einem Konsolenfenster gestartet. Dann macht der Patch wirklich Sinn! Würdest du stattdessen eine rechenintensive (GUI-)Software aufrufen, die z.B. ein Video recodiert, dann wirst du keine Vorteile haben. Er schadet dann aber auch nicht.
Bei deinem Verweis auf oben weiß ich nicht genau was du meinst. Evt. das mit Init und Child-Prozesse? Ein kleiner Auszug aus "ps fax":
1 ? Ss 0:00 init [5]
2464 ? S 0:00 /bin/sh /usr/bin/firefox
7111 pts/0 Ss 0:00 /bin/bash
An der 2. Spalte sieht man, dass init oder firefox mitnichten in einem eigenen tty laufen, im Gegensatz zum Prozess 7111.
Vor lauter Aufregung den Link vergessen...
http://marc.info/?l=linux-kernel&m=128807686003032&w=2
Also das ist ja jetzt Blödsinn. Es ist doch völlig irrelevant, ob ein Befehl im Terminal ausgeführt wird oder man für einen Befehl ne schöne GUI drüber programmiert. Macht keinen Unterschied bei der Geschichte, um was es hier geht.
Ein Prozessor (bzw. ein Prozessorkern) kann nun mal gleichzeitig nur eine Aufgabe erledigen. Bei mehreren Prozessen werden die Fragmente verschiedener Prozesse hintereinander ausgeführt. Der Patch sorgt dafür, dass das besser organisiert wird. Und ob GUI oder nicht ist dem Betriebssystem wirklich sch... egal.
Zitat David:
Ja es stimmt alle X-Anwendung sind in _einer_ TTY. Und das ist genau der Knackpunkt.
Dieser Patch verteilt das sheduling auf alle cgroups, Automatisch werden dises Gruppen nach ihrer tty zugewiesen.
Starteten man n Programme über die Graphische Oberfläche, laufen diese n Programme in einer Autogroup. Also alles wie bisher, jetzt auch schon.
Nun das Killer feature dieses Patches: Starte ich 2 Totem in einer Konsole (2 Tabs), Starte einen Compile Job in einer anderem Xterm, werden diese Prozesse (Und ihre Kinder) nun gleichmässig verteilt. Das geht aber nur, da jede Anwendung durch jede neue Konsole ein neues TTY erhalten hat.
Der Kernel kann schlicht und einfach Graphische Anwendungen nicht sinnvoll Groupieren. Deswegen dieser Hack auf TTY Basis, für Konsolenkämpfer. Heh wenn's geht warum nicht, ich bin mir nur nicht sicher ober sowas in den Kernel gehört. (Warum macht das nicht das gnome-terminal/Xterm?)
Das ist nicht für Desktop User, das ist für Entwickler (und Gentoo Background Compile Jobs
)
Zitat ende
für mich klingt das einleuchtend
Das wäre doch auch eine Idee, dann könne man rechenintensive Programme einfach auf einen anderen Desktop schieben und hätte Ruhe
++
Bitte implementieren.
Selten konnte man in einem Artikel so viel Euphorie rauslesen...
http://aur.archlinux.org/packages.php?ID=43689
Mal sehen, wie er sich im Vergleich zum BFS Scheduler schlägt. Letzterer war DIE Entdeckung des Jahres, gerade, was das Blockieren durch IO angeht.
Ich habe meine Zweifel, das dieser cgroup Hack da mithalten kann, bin aber gespannt
Für alle die mit BFS nicht anzufangen wissen:
http://de.wikipedia.org/wiki/Brain_Fuck_Scheduler
Ich probiere den patch jetzt nochmals auf dem Desktop aus (auf meinem Handy läuft er seit dem 16.11.2010 dank IntersectRaven Kernel) - und da bringt er ordentlich was.
Naja, ich weiß nicht ob sich BFS sooo warm anziehen muss.
Irgendwie halte ich den BFS scheduler für den "gründlicheren" Ansatz, da er einfach wesentlich einfacher aufgebaut ist als CFS und niedrige Latenz "by design" ermöglicht.
Du kannst ja mal die Resultate posten. Würde sicherlich viele interessieren.
Mache ich auch, sobald ich wieder zu Hause eingetroffen bin. Anbei: Ich hab gerade nochmal kurz den gleichen Kernel mit BFS Scheduler geflashed und - obwohl sched autosched eine wahnsinnig gute Performance gegenüber dem konventionellen CFS bietet - ist der BFS nochmal gefühlt geschmeidiger (Homescreen Swype mit aktiviertem NexusKang LWP). Vielleicht bin ich aber auch nur ein wenig voreingenommen.
Dieser Beitrag wurde 1 mal editiert. Zuletzt am 18. Nov 2010 um 14:53.Torvalds ist von dem Patch natürlich begeistert, da sich bei ihm sichtbare Verbesserungen zeigen.
Das ist ja auch kein Wunder, denn er lässt ja ganz bestimmt meistens irgendwelche Kernel im Hintergrund kompilieren, was sein Rechnersystem massiv beansprucht und seinen Desktop beim Internetsurfen und Emailen entsprechend verlangsamt.
Nur: Welcher Desktopnutzer hat normalerweise ein derartiges Nutzerprofil?
Siehe hierzu u.a.:
http://marc.info/?l=linux-kernel&m=128993935321081&w=2
Ich bin hier auf diese Argumente aufmerksam geworden:
http://debianforum.de/forum/viewtopic.php?f=33&t=124909#p798104
Siehe auch Blubbs obigen Kommentar.
Also ich schaffe es alleine durch surfen im Internet meinen Rechner in die Knie zu zwingen. Top-Verbraucher sind Flash, insbesondere durch Flash-Werbung und viele offene Tabs...
Oder was ist mit Indexdiensten, zB updatedb oder andere lokale Suchdienste für Dateien? Wenn die einmal anfangen zu rödeln, können Single-Processor-Systeme schonmal für eine Zeit nahezu unbenutzbar werden.
Aber klar, wenn man nie hohe Auslastungen hat, wird der Patch wahrscheinlich nur begrenzte Relevanz haben...
Dieser Patch wird Dir im Hinblick auf Dein eigenes Nutzungsszenario nicht helfen könen.
Siehe
http://marc.info/?l=linux-kernel&m=128993935321081&w=2
(Der Link wurde oben schon angegeben.)
"(...)
Well, this feature is pretty much interesting only for kernel hackers
anyway. It is completely irrelevant for normal desktop people. Because
a) normal users don't use many terminals anyway and that very seldom and
b) if they do that they do not create gazillion of processes from one of
the terminals and only very few in the other. Because only then this
patch becomes relevant.
(...)"
Dazu passt am besten die Antowrt von Torvalds...