Torvalds hat schon Recht. Man könnte doch den Kernel so bauen,daß zumindest gar keine Treiber drauf sind. Erst während der Installation von Distro X "sieht der Kernel" welche Treiber benötigt werden. Falls dann später noch etwas hinzukommt (Drucker z.b.) dann sieht die Distro : Ah, neue Hardware, also neuen Treiber auf Abfrage automatisch(aus einer Datenbank z.b.) installieren. Dann wäre der kernel um einiges schlanker. Ob das aber möglich ist??? Albert
Techn. ist das sicher möglich. Für Maschinen die kein Internet können auch aus dem Repo oder von CD.
Das wird den Speed aber nicht erhöhen. Es ist ja nicht so, das die Treiber das Speedproblem erzeugen. Geladen sind ja nur die man auch braucht.
Das Kernproblem sind sicher die vielen Funktionen. Hier wäre zu entscheiden welche den Speed tatsächlich beeinflußen und welche davon wirklich gebraucht werden. Sowas könnte man über eine Reporting-Funktion mit anschließendem Upload auf einen Zentral-Server machen. Danach könnte man entscheiden welche tatsächlich raus können.
Stimmt. Man könnte ja den Kernel abzweigen. Einer mit "Vollfunktion", der andere "halbvoll" aber mich stört es bis jetzt gar nicht. Warum auch? Die Festplatten werden immer grösser, CPU immer schneller. Also kommt es gar nicht drauf an,ob kernel 50 MB oder 80 MB gross ist... Aber es gibt eben Leuter,die haben ältere Rechner und das macht sich schon bemerkbar...
Die Aufgabe des Kernels ist es im wesentlichen, die Hardware-Ressourcen unter verschiedenen Prozessen zu verteilen, und sich selbst möglichst wenig Rechenleistung zu genehmigen.
Wenn man so auf das Kommando "top" schaut, dann sieht man, dass das System (also im wesentlichen der Kernel) 0.4% der Rechenleistung braucht (Quad-Core Intel 2.8 GHz). Auf einen Single-Core 500 MHz (10 Jahre alt) runtergebrochen würde das heißen, dass der Kernel dort 10% verbrauchen würde. Keine Ahnung, ob man das einfach so umrechnen kann, oder ob ein langsamerer Computer einfach weniger Operationen pro Sekunde BRAUCHT, weil ja auch weniger Task-switches, weniger Scheduler-Entscheidungen usw. berechnet werden müssen.
Jedenfalls finde ich 2% von 0.4% ist wenig genug. Wenn man das Ding auf einem Telefon laufen lassen kann, dann sollte man das eigentlich als Zeichen nehmen, dass es gar nicht so schlecht ist wie es vielleicht aussieht.
Naja, aber man kann sich ja auch einen Kernel selber kompilieren. Auch wenn mittlerweile alle Distributoren per Default tausend Sachen im Kernel aktivieren, die jeweils nur von 0,0001% der User benötigt werden und der Rest als Modul kompiliert wird...es ist noch immer möglich "eigene" Kernel zusammenzustellen und es ist auch dank Arbeit von Seiten der Distributoren auch nicht wirklich aufwändig.
Würde mich daher auch mal interessieren, *wie* der Kernel von Intel gebenchmarked wurde...
Wozu einen neuen Kernel, wenn die Hardware alt ist? Wenn der alte Kernel flotter ist, dann halt den alten behalten. Gibt genug Distis welche die alten Kernel weiter mit Sicherheitsaktualisierungen versorgen.
Von Eismeister am Di, 22. September 2009 um 22:01 #
Man kann sich doch selber nen Kernel bauen. Das ist ganz einfach. Kernel Sourcen deiner distri installieren, stock .config kopieren, make oldconfig, make menuconfig, dann alles raus, was nicht in lsmod auftaucht, und nicht an dynamischen Schnittstellen (USB/Firewire/PCcard etc hängt). Und alles, was nicht rein gehört ist dann auch nicht drinne.
Ist das nicht das Prinzip der Module? Man kann doch beim kompilieren des Kernels auswaehlen, welche Teile direkt in den Kernel integriert werden und welche als Module kompiliert werden, die dann spaeter dynamisch in den kernel geladen werden koennen.
Dies ist schon heute der Regelfall: Durch Treiber die als Kernelmodule kompiliert und bei Bedarf nachgeladen werden. Selbst Treiber die für den Systemstart erforderlich sind, müssen nicht zwangsläufig integriert sein, da sie in die Inital Ramdisk integriert werden können, die der Bootloader an den Kernel übergibt. Falls erforderlich kann man auch selbst einen um nicht benötigte Funktionen bereinigten Kernel kompilieren.
Ein weiterer Gedanke währe so einer Art Programm zu machen oder eine Routine bei der Installation einer Distro, oder einfach ne GUI die die gesamte hardware ermitteln kann, und dem entsprechend einen kernel baut. Eine zusätzliche abfrage des Einstatzgebiets des Rechners währe noch angebracht damit auch die nötigen Features hineinkompiliert werden können.
Ob das dann auch umsetzbar ist müsste man die Kernelhacker fragen. Wie dem auch sei, solch eine Anpassung würde wahrscheinlich für mehr geschwindigkeit sorgen.
Ein anderes Konzept, währe eine separate treiberinstallation alá Windows. Nur müsste das dann vom Hardwarehersteller übernohmen werden, wie das heute ist wissen ja alle Linux benutzer.
Von nick name am Di, 22. September 2009 um 14:36 #
> Ein weiterer Gedanke währe so einer Art Programm zu machen oder eine Routine bei der Installation einer Distro, oder einfach ne GUI die die gesamte hardware ermitteln kann, und dem entsprechend einen kernel baut.
Das wäre so und auch so wünschenswert. Mal abgesehen davon, das es kaum eine Disto mit Vanilla-Kernel gibt. (Oder irre ich da?)
> Eine zusätzliche abfrage des Einstatzgebiets des Rechners währe noch angebracht damit auch die nötigen Features hineinkompiliert werden können.
Und bei euen Geräten müss ich ihn da wieder selbst bauen und Zeit operfn? Im Falle eines HW-Tausch ist das schlecht.
> Ein anderes Konzept, währe eine separate treiberinstallation alá Windows. Nur müsste das dann vom Hardwarehersteller übernohmen werden, wie das heute ist wissen ja alle Linux benutzer.
Dann muss aber auch die ganze API für alle Module vorgehalten werden?. Anders: Wodurch genau entstehen die Performanzverluste?
>Anders: Wodurch genau entstehen die Performanzverluste?<
Ich würd ma behaupten durch verschiedene Routinen und Treiber von den manche nicht mal gebrauch werden, die jedoch im Hintergrund laufen. Wurde aber schon im dem eigentlichem Artickel gesagt.
>Mal abgesehen davon, das es kaum eine Disto mit Vanilla-Kernel gibt. (Oder irre ich da?)<
Wenn ich mich nicht irre, hat zumindest debian ne möglichkeit die Kernelsource als paket zu laden und dann kannst du damit anstellen was du willst. Es sei den, das was die da anbieten kein Vanila ist.
> Anders: Wodurch genau entstehen die Performanzverluste? >> Ich würd ma behaupten durch verschiedene Routinen und Treiber von den manche nicht mal gebrauch werden, die jedoch im Hintergrund laufen. Wurde aber schon im dem eigentlichem Artickel gesagt. Kann ich mir ehrlich gesagt überhaupt nicht vorstellen. Du kriegst keinen Treiber upstream der, obwohl nicht nötig, irgendeine Task oder so startet. Ich glaube nicht, dass die Treiber unmittelbar das Problem sind. Wenn ein Treiber ob einkompiliert oder als Modul gebaut nicht benötigt wird, weil die Hardware nicht vorhanden ist, wird der Treiber selbst nicht verwendet. Er wird entweder geladen oder nie wieder aufgerufen.
Der Performanzverlust kann nur von zentralen Komponenten des Kernels herrühren (Scheduler, Slab-Allocator, ...).
Von Alan Smithee am Di, 22. September 2009 um 15:07 #
> Wenn ich mich nicht irre, hat zumindest debian ne möglichkeit die Kernelsource als paket zu laden und dann kannst du damit anstellen was du willst. Es sei den, das was die da anbieten kein Vanila ist.
vanilla = kein kernel patch das hat weniger mit den features zu tun die du aktivierst.
Die größe der sourcen ist doch nicht das problem, abs nun 10 oder 100mb sind - was solls. Auch die größe des physikalischen kernels ist relativ latte, btw. meine aktueller 2.6.31 ist keine 3MB groß... dazu noch 10 module oder so die bei selten verwendeter hardware nachgeladen werden.
Das was die geschwindigkeit beeinflußt sind div abstraktionsschichten die bei vielen funktionen abgearbeitet werden, es geht die länge des codepfades der für eine funktion ausgeführt wird, nciht die größe des eigentlich kernels.
Deswegen bringen deine vorschläge auch nicht viel, es würde sich mit dem angepassten kernel nichts an der anzahl der abzuarbeitenden befehle zum ausführen einer funktion ändern. Und weil das wirklich eine schwer zu knackende nuss ist, fällt dem guten linus auch erstmal nichts dazu ein.
Der selben Ansicht bin ich auch. Allerdings würde mich wirklich interessieren, welche Tests da durchgeführt wurden. Phoronix bringt doch bei jedem Kernelrelease einen Vergleich. Und soweit ich mich erinnern kann, ist der aktuelle Kernel je nach Anwendungsgebiet schneller oder langsamer.
Phoronix ist zum Vergleichen schlecht geeignet. Entweder macht man einen ordentlichen Feldtest und liefert eine Definition der Umgebung mit, oder man führt ein sauberes Profiling durch. Bis jetzt hab ich von denen nur bunte Diagramme gesehen, deren Fazit hauptsächlich auf Daten aus time(1) beruhen. Das kann ich auch selber eintippen; ohne "Suite".
Von R. Duttine am Mi, 23. September 2009 um 10:49 #
Eine ideale Idee, um den Linux - Kernel schlank u. schnell zu gestalten. !!!!!!!!!!!!!! Ich hoffe, die Idee wird aufgenommen . Man schleppt Tausend Funktionen u. Treiber mit, die man gar nicht braucht. Linux könnte auch schneller sein
Und? Hast schon eine Lösung parat? Eine Vision ist das Ziel, eine Lösung ist der Weg zum Ziel. Eine Vision kann man in Sekundenbruchteilen erdenken/haben, der Weg dorthin kann Jahre dauern oder gar völlig unmöglich sein. Vision: alle Menschen haben sich lieb, darum gibt es keinen Krieg mehr. Weg: ähhhhhhh
Milrokernel ist mehr, als mur Treiber im Userspace. Und der Kommunikationsoverhead zwischen den Kerneldiensten, die aus dem Mikrokernel ausgelagert sind, fuehrt sicher nicht zu einer besseren Performance.
> Ein Microkernel wäre eine Lösung. Treiber laufen dann im Userspace und man hat keine Probleme mehr.
Und das löst das Problem der Abstraktionschichten und wachsender Codegrösse wie? Du hast halt einen Haufen User daemons laufen, statt eines Kernelprozesses, so what?
Linux ist bereits wesentlich mehr `micro' als früher und wird mehr und mehr `micro' werden, so weit das zu einem beliebigen künftigen Zeitpunkt technisch sinnvoll ist. Der Hype um jene Kernelkonzepte die im akademischen Sinn als `echt micro' gelten ist bzw. war in erster Linie ... ein Hype.
Dass Linux heute als Kernel (für GNU und andere) benutzt werden kann ist unter anderem dem Umstand zu verdanken, dass es früher nicht `micro' genug war um für Akademiker als schick durchzugehen. Zum Glück. MINIX war `echt micro' und MINIX war unbrauchbar für die `real world' (genauso wie HURD, nebenbei gesagt), der Entstehungsgrund für Linux. Um dessen `microness' würde ich mir nicht unbedingt große Sorgen machen - die ist absolut auf der Höhe der Zeit und wandelt sich weiter, mit der Zeit.
Was die Geschwindigkeitseinbußen angeht, zeigt die Nachricht meiner Meinung nach vor allem eines, nämlich dass das Frühwarnsystem der Community erwartungsgemäß funktioniert. In der proprietären Welt gibt es diverse Software-Hersteller die Jahre lang hinter verschlossenen Türen an einer neuen Betriebsystemversion herumentwickeln um den Anwender pünktlich zum Release mit der ernüchternden Tatsache vertraut zu machen, dass die Performance im Vergleich zum Vorgänger unterirdisch ist
was Minix angehst, so tust Du dem ganzen Unrecht. Es sollte gar nicht wirklich gut einsetzbar sein, sondern vor allem leicht zu verändern. Der Prof. Tannenbaum hatte es zu speziell dem Zweck entwickelt und Patches mit Verbesserungen, die es aber komplexer machen, regelmäßig abgelehnt.
Dass Linux ihm als zu fett gilt, liegt nicht an den vielen Treibern. Die sind ja nur Module und werden bei Bedarf nachgeladen, sonst nicht. Das klappt ganz gut. Was es fett macht, sind eher die 4 Arten von RAID, die sich darin verewigt haben, und jeweils andere APIs und anderen Code haben. Oder fnotify, inotify und wie auch immer die Vereinigung jetzt heisst. Oder /proc, /sys und debugfs, oder jetzt auch devfs2, etc.
Es gibt Unmengen an Interfaces, die kaum mehr jemand braucht, die Last erzeugen, weil Implementierungen sie bedienen können müssen, und Code fressen. Ich hoffe dass Linus versuchen will, auf ein Linux 3.0 zu kommen, dass inkompatibel ist, und alles unnötige an Altlasten wegwirft.
Von Jo:rg Zweier am Di, 22. September 2009 um 21:58 #
++
Dem kann ich mich nur anschließen. So langsam müssen die Kernelentwickler wirklich dazu übergehen, ihre APIs zu "standardisieren", sodass es auch die Anwendungsentwickler leichter haben und sich auf die wesentlichen Dinge konzentrieren können.
Komm hoer auf mit der Polemik. Wie viele Andere sehe ich die Symptome. Die tatsächlichen Ursachen kann und muss ich nicht analysieren, solange ich nicht an der Kernelentwicklung beteiligt bin. Eine Lösung kann ich deshalb ebenfalls nicht bieten, da ich die Ursachen nicht kenne.
Bevor du dich jetzt beschwerst, dass ich dann halt mitmachen soll, also am Kernel ..... Auch ohne Teilhabe darf ich warnen! Ebenso wie viele Bürger bzgl. des Einsatzes der BW in Afghanistan kritisieren ohne vor Ort zu sein!
Von dark_star am Di, 22. September 2009 um 14:52 #
So wie es aussieht schon, denn es geht ja weniger drum, ob jetzt ein Modul geladen ist oder nicht, sondern um die Basisarchitektur. Viele Optionen beeinflusssen div. Subsysteme und muessen beachtet werde. So hab ichs zumindest verstanden.
Auch wenn man den Kernel um nicht benutzte Module abspeckt, wird der verbleibende, absolut notwendige Rest wohl immer groesser und damit auch ein wenig langsamer. Aber natuerlich verbraucht der Kernel nur einen kleinen Teil der Rechenzeit. Das System selber wird deshalb nicht gleich um den genannten Faktor langsamer.
Von Christopher Roy Bratusek am Di, 22. September 2009 um 17:30 #
Nicht zwingend. Diverse Einstellungen lassen sich ja optimieren. Zwar wird er dann nicht mehr so schnell wie der 2.6.0, aber immerhin mehr als ein 08/15-Kernel der gleichen Version. Performance patches gibt's ja auch noch, beim selbstkompilierten Kernel kann man die ja hinzufügen.
Von romantic gorilla am Di, 22. September 2009 um 20:51 #
> Hab ich da auch die Performance-Probleme?
wieso "performance-probleme"? die aussage war doch nur, dass der kernel allmählich langsamer wird. ob sich das _spürbar_ auf die performance des systems auswirkt, ist ne andere frage.
Ich kann es nicht genau benennen, aber ich denke, seit die "Grossen" angefangen haben, für Linux zu entwickeln, wurde der Kernel aufgebläht. Alle Unix-artigen Systeme - angefangen von Hurd über Net/Open-BSD bis hin zu Sachen wie L4 -, die noch von "Hackern" entwickelt werden, sind im grossen und ganzen leichtgewichtig und auch gut performant. Sobald aber grosse Firmen anfangen, die Richtung in der Entwicklung anzugeben, wie sie es eben machen bei Linux, wird es sehr schnell unübersichtlich, aufgebläht und ähnlich schwer und fett. Zwar nicht ganz passend aber doch als Bild gut nutzbar wäre der Vergleich von grossen Firmen entwickelten Distributionen (Suse,Redhat,ja selbst Ubuntu) - die schon bei der Basisinstallation mehrere hundert MB bis zu paar GB installieren mit allerlei Diensten und GUIs etc., die man später mühsam ausschalten muss - und von Hackern gemachten Distros(Damnsmalllinux, Slackware, Archlinux), die man schon auf kleinste Datenträger bekommt.
> Also der Vergleich hinkt ja gewaltig. > Hurd = Microkernel > L4 = Microkernel > Somit schon ein komplett anderes Konzept.
Entscheidend ist das mit mehr unterstützen Komponenten die Komplexität von Datenstrukturen und Menge an Steueranweisungen zunimmt. Micro- und Monolithkernel hin oder her.
Von irgendwer am Di, 22. September 2009 um 16:25 #
Schön und gut, aber
> War zwar ein netter Versuch von Dir aber jetzt wieder ab auf die Trollwiese.
das ist nun wirklich nicht angebracht. Sein Einwand war legitim und entspricht wohlmöglich auch der Wahrheit. Den Satz hättest du dir schlicht sparen können.
Von dark_star am Di, 22. September 2009 um 15:12 #
Zitat: "aber die Stabilität sei sehr gut, Fehler würden schnell beseitigt und das Entwicklungsmodell funktioniere besser als je zuvor."
Wenn die 'Kommerziellen' auch dafuer verantwortlich sind, kanns schon hinkommen. Immer mehr Features, immer mehr Plattformen, immer hoehere Entwicklungsgeschwindigkeit - dass das ohne jegliche Einbussen geht, ist wohl kaum moeglich.
Aber ists wirklich so ein grosses Problem? Es gibt ja noch BSD&Co, die diesen Entwicklungsdruck seitens der kommerziellen Anwender nicht so massiv abbekommen.
Von fetter-linuxnerd am Di, 22. September 2009 um 15:50 #
endlich, dann passt sich der linuxkernel, vom aussehen her also den linuxnutzern an
das wäre auch eine erklärung dafür, wieso nach all den vielen releases, für mich persönlich, noch immer 2.6.24 am "schnellsten" rennt.
gabs da nicht mal nen test drüber, das seit 2.6.24 irgendwas irrsinnige performanceverluste verursacht?
beispiel: ich betreibe mein system nur mithilfe von live cds.
knoppix mit 2.6.24 ist superflüssig. sidux mit 2.6.27 jedoch, spielt videos schon nicht mehr so flüssig ab UND die hd performance fühlt sich irgendwie langsamer an.
Ist doch schon arm dass man alte versionen benutzen muss weil die neueren so beschissen programmiert wurden dass selbst fluessiges video abspielen unmoeglich ist
Von fetter-linuxnerd am Di, 22. September 2009 um 16:30 #
es ist eher so, dass die videos mit 2.6.27 und 2.6.30 zwar abgespielt werden, es jedoch immer wieder zu kleinen mikrorucklern kommt und sich imemr wieder ein paar asynchronitäten einschleichen. das geht so weit, das die videos, die ich mit 2.6.27+2.6.30 lade, auch auf 2.6.24 so abgespielt werden. dürfte also die dateien irgendwie "ändern".
dateien, die ich mit 2.6.24 lade laufen immer flüssig.
auch geht das schreiben auf der hd mit 2.6.24 um einiges schneller.
Von kartoffel200 am Mi, 23. September 2009 um 16:36 #
Aha du bist wohl ein kleiner Experte... Videos, man die werden soooo was vom Kernel beschleunigt.... Seit der ATi Mach64 oder der RAGE hat jede verfickte Graka extra MPEG fähigkeiten. Muss also der kleine "experte" weg von Chips und Cola und sich nen Treiber basteln der die Graka mit dem nötigen Scheiß vollnöhlt. Deshalb ziehen HD Videos, auch beim richtigen Codec, bei fehlender Grakaunterstützung ordentlich CPU Leistung.
Ob der Kernel 2.6.24 oder 2.6.30 schneller ist oder nicht kann der normale Dekstopanwender eh nicht rausfinden, da der Xorg im Regelfall von Distri zu Distri neuer wird.
Von irgendwer am Di, 22. September 2009 um 16:32 #
Das hat wohl weniger mit dem Kernel zu tun als viel mehr damit, dass wahrscheinlich seine Grafikkarte schlicht von Knoppix besser unterstützt/erkannt wird. Grafikperformance macht meines Wissens zwischen den Kerneln keinen großen Unterschied. Dahingegen macht es einen riesen Unterschied, ob nun xorgs vesa-Treiber, die freien nv/radeon-Treiber oder gar die proprietären nvidia/fglrx-Treiber zum Zuge kommen. (oder bei Intel z.B. welche Treiberversion mit welchem Beschleunigermodus: xaa, exa oder gar uxa)
So merken wird man den Unterschied von 2.6.2x und folgenden wohl eher weniger. Es sei denn, es kommen unterschiedliche Scheduler, Memory Management, etc. zum Einsatz. Das ist es aber nicht, worum es hier ging.
... versuch mal den i915 mit nem 2.6.29er kernel und mit nem 2.6.31er kernel. möglichst mit aktiviertem kms .... es ist der unterschied zwischen himmel und hölle.
Von irgendwer am Do, 24. September 2009 um 13:52 #
Na das sind ja dann eben auch unterschiedliche Treiberschnittstellen. Und wenn der Grafikkartentreiber ein anderer ist (bzw. in einer anderen Konfiguration läuft), dann macht das natürlich einen fühlbaren Unterschied in der gui. Intel mit uxa und gem ist nunmal schneller als mit xaa... und in der Umstellungsphase ist vieles einfach nur ein Graus...
Es gibt einen mutmaßlichen I/O-Bug in Kernel seit etwa 2.6.15/2.6.18, der im schlimmsten Falle auch noch so "starke" Systeme mit 100% auslastet. An Xorg wird zur Zeit allerdings auch sehr viel verändert. Je nach Grafikkarte befindet sich u.U. sogar die zugehörige Kernel-Firmware mittlerweile in non-free. Welche Grafikkarte werkelt denn in Deinem Rechner?
will ein Tester mit Kernel 2.6.31 eine geringe Verbesserung bemerkt haben: "There is an improvement in desktop responsiveness with kernel 2.6.31 and the as scheduler compared to the cfq scheduler. It does not solve the problem, but it makes it more sufferable."
Das Hauptproblem ist, dass es keine stabile Kernel-2.6-Reihe von kernel.org gibt (die also jetzt noch supportet wird), die diesen Bug nicht hat. Ich persönlich setze - falls die Hardware es erlaubt - Kernel 2.4 ein, wo es nur möglich ist.
Auf dem Desktop ist der Bug nicht so wichtig. Von Win9x-Zeiten her weiß man ja wohl noch, wo im Notfall der Reset-Knopf zu finden ist. Tritt der Bug ein, so kriecht das System dahin, siehe hierzu z.B. Kommentar 325 unter obigem Link.
Falls Deine Hardware geeignet sein sollte, so lasse z.B. Slackware 11.0 mit Kernel 2.4 gegen ein neuestes Linux mit Kernel 2.6 antreten und lass deinen Rechner einmal so richtig arbeiten (mitunter reichen schon große Kopieraktionen im Rahmen des Versuchs von "Multitasking"; oder kompilier einen Kernel und arbeite gleichzeitig mit einem anderen Programmen weiter; usw.). Du wirst schnell feststellen, welches System "responsiver" ist.
Kernel 2.6-Systeme verhalten sich unter annähernder Vollast, wenn denn der I/O-Bug zuschlägt, wie damals Win95 beim Formatieren einer Diskette. Siehe hierzu Kommentar 323 unter obigem Link: "The irony is that it feels like Windows 95 while a floppy was formated. You know, the whole pseudo multi tasking on top of Dos - everything was really choppy. (...) If I encode a DVD with ogmrip/mencoder h264 and 16 threads (16 threads get the highest cpu usage from my quad core which is still under 80% per core) Gnome feels like a formatting Win 95."
Von betroffener am Mi, 23. September 2009 um 08:26 #
Auf dem Desktop ist der Bug nicht so wichtig. Von Win9x-Zeiten her weiß man ja wohl noch, wo im Notfall der Reset-Knopf zu finden ist. Tritt der Bug ein, so kriecht das System dahin, siehe hierzu z.B. Kommentar 325 unter obigem Link. Doch er ist GERADE auf Desktopsystemen nervig. Kopiere einfach mal ein paar Videos, ISOs, Backup,... von/zu USB-Platten und mach nebenbei was anderes, schon bist du betroffen. Mich nervt der Bug jeden Tag und kotzt mich immer mehr an. Normalerweise sind Bugs unter Linux schnell erkannt und gefixt aber hier wissen die Entwickler nicht mal wo das Problem ist.
Von Michael Lehmeier am Mi, 23. September 2009 um 09:21 #
Wenn das dieser Bug ist, in den ich häufig reinlaufe, dann kann ich bestätigen, dass er nervig ist ohne Ende.
Wenn ich versuche, ein 16 GB Backup auf eine verschlüsselte SATA-Compact-Flash Karte oder USB-Stick zu machen ist die Wahrscheinlichkeit groß, dass der Computer sich so aufhängt, dass nur noch ein Reset hilft. Nur in kleinen Häppchen mit sync dazwischen geht das gut. Das sehe ich nicht als "nicht so wichtig" an.
Dieser I/O-Bug ist tatsächlich nervig. Es aber gut zu wissen, was es eigentlich mit diesem "der Linux-Kernel ist fett und aufgebläht" auf sich hat. Immerhin weißt Du definitiv, dass Du nicht "träumst".
Was ein linux System träge erscheinen lässt ist der xserver der einfach zu alt, zu fett, zu ufgebläht und einfach unpassend für solch ein modernes PC System ist. Mir persönlich kam ne Linux Konsole und dessen Befehle immer mehr als schnell genug vor. Nur an der GUI hängts leider noch
und als xfce auf arch linux auch träger als mein xp war, ahb ichs aufgegeben linux ist durchdacht, linux ist schnell, aber der xserver ist einfdach müll...
ok, ich komme aus der gentoo-ecke... wenn ich einen kernel backe dann ist eh nur treiberunterstützung für die hardware des jeweiligen rechners einkompiliert. wenn möglich lasse ich gar keine module zu. wenn linus meint das sei ihm zu fett dann interessiert mich ehrlich wo er die speckröllchen sieht.
Von Apfelmann am Mi, 23. September 2009 um 19:21 #
Vielleicht wäre eine sinvolle Lösung den Kernel zu splitten. Somit das man zum beispiel 3 Bereiche abdeckt. Home/Office Server Embedded Somit könnte man überflüssige funcionen umgehen die einfach das ganze nur unnötig an die leistung kratzen.
Ob das aber möglich ist???
Albert
Das wird den Speed aber nicht erhöhen. Es ist ja nicht so, das die Treiber das Speedproblem erzeugen. Geladen sind ja nur die man auch braucht.
Das Kernproblem sind sicher die vielen Funktionen. Hier wäre zu entscheiden welche den Speed tatsächlich beeinflußen und welche davon wirklich gebraucht werden. Sowas könnte man über eine Reporting-Funktion mit anschließendem Upload auf einen Zentral-Server machen. Danach könnte man entscheiden welche tatsächlich raus können.
Grüße.
aber mich stört es bis jetzt gar nicht. Warum auch? Die Festplatten werden immer grösser, CPU immer schneller. Also kommt es gar nicht drauf an,ob kernel 50 MB oder 80 MB gross ist...
Aber es gibt eben Leuter,die haben ältere Rechner und das macht sich schon bemerkbar...
Alberrt
Oder Leute, die Rechenleistung JETZT brauchen, und nicht erst auf die nächste CPU Generation warten können.
Die Aufgabe des Kernels ist es im wesentlichen, die Hardware-Ressourcen unter verschiedenen Prozessen zu verteilen, und sich selbst möglichst wenig Rechenleistung zu genehmigen.
Wenn man so auf das Kommando "top" schaut, dann sieht man, dass das System (also im wesentlichen der Kernel) 0.4% der Rechenleistung braucht (Quad-Core Intel 2.8 GHz). Auf einen Single-Core 500 MHz (10 Jahre alt) runtergebrochen würde das heißen, dass der Kernel dort 10% verbrauchen würde. Keine Ahnung, ob man das einfach so umrechnen kann, oder ob ein langsamerer Computer einfach weniger Operationen pro Sekunde BRAUCHT, weil ja auch weniger Task-switches, weniger Scheduler-Entscheidungen usw. berechnet werden müssen.
Jedenfalls finde ich 2% von 0.4% ist wenig genug. Wenn man das Ding auf einem Telefon laufen lassen kann, dann sollte man das eigentlich als Zeichen nehmen, dass es gar nicht so schlecht ist wie es vielleicht aussieht.
Würde mich daher auch mal interessieren, *wie* der Kernel von Intel gebenchmarked wurde...
Wenn der alte Kernel flotter ist, dann halt den alten behalten. Gibt genug Distis welche die alten Kernel weiter mit Sicherheitsaktualisierungen versorgen.
Ob das dann auch umsetzbar ist müsste man die Kernelhacker fragen. Wie dem auch sei, solch eine Anpassung würde wahrscheinlich für mehr geschwindigkeit sorgen.
Ein anderes Konzept, währe eine separate treiberinstallation alá Windows. Nur müsste das dann vom Hardwarehersteller übernohmen werden, wie das heute ist wissen ja alle Linux benutzer.
Das wäre so und auch so wünschenswert. Mal abgesehen davon, das es kaum eine Disto mit Vanilla-Kernel gibt. (Oder irre ich da?)
> Eine zusätzliche abfrage des Einstatzgebiets des Rechners währe noch angebracht damit auch die nötigen Features hineinkompiliert werden können.
Und bei euen Geräten müss ich ihn da wieder selbst bauen und Zeit operfn? Im Falle eines HW-Tausch ist das schlecht.
> Ein anderes Konzept, währe eine separate treiberinstallation alá Windows. Nur müsste das dann vom Hardwarehersteller übernohmen werden, wie das heute ist wissen ja alle Linux benutzer.
Dann muss aber auch die ganze API für alle Module vorgehalten werden?.
Anders: Wodurch genau entstehen die Performanzverluste?
Ich würd ma behaupten durch verschiedene Routinen und Treiber von den manche nicht mal gebrauch werden, die jedoch im Hintergrund laufen. Wurde aber schon im dem eigentlichem Artickel gesagt.
>Mal abgesehen davon, das es kaum eine Disto mit Vanilla-Kernel gibt. (Oder irre ich da?)<
Wenn ich mich nicht irre, hat zumindest debian ne möglichkeit die Kernelsource als paket zu laden und dann kannst du damit anstellen was du willst. Es sei den, das was die da anbieten kein Vanila ist.
>> Ich würd ma behaupten durch verschiedene Routinen und Treiber von den manche nicht mal gebrauch werden, die jedoch im Hintergrund laufen. Wurde aber schon im dem eigentlichem Artickel gesagt.
Kann ich mir ehrlich gesagt überhaupt nicht vorstellen. Du kriegst keinen Treiber upstream der, obwohl nicht nötig, irgendeine Task oder so startet. Ich glaube nicht, dass die Treiber unmittelbar das Problem sind. Wenn ein Treiber ob einkompiliert oder als Modul gebaut nicht benötigt wird, weil die Hardware nicht vorhanden ist, wird der Treiber selbst nicht verwendet. Er wird entweder geladen oder nie wieder aufgerufen.
Der Performanzverlust kann nur von zentralen Komponenten des Kernels herrühren (Scheduler, Slab-Allocator, ...).
vanilla = kein kernel patch
das hat weniger mit den features zu tun die du aktivierst.
Slackware
Das was die geschwindigkeit beeinflußt sind div abstraktionsschichten die bei vielen funktionen abgearbeitet werden, es geht die länge des codepfades der für eine funktion ausgeführt wird, nciht die größe des eigentlich kernels.
Deswegen bringen deine vorschläge auch nicht viel, es würde sich mit dem angepassten kernel nichts an der anzahl der abzuarbeitenden befehle zum ausführen einer funktion ändern. Und weil das wirklich eine schwer zu knackende nuss ist, fällt dem guten linus auch erstmal nichts dazu ein.
...es geht um die länge des...
Allerdings würde mich wirklich interessieren, welche Tests da durchgeführt wurden. Phoronix bringt doch bei jedem Kernelrelease einen Vergleich. Und soweit ich mich erinnern kann, ist der aktuelle Kernel je nach Anwendungsgebiet schneller oder langsamer.
Man schleppt Tausend Funktionen u. Treiber mit, die man gar nicht braucht. Linux könnte auch schneller sein
R. D.
Tut mir leid, aber das ist dürftig. Es ist an der Zeit wieder Visionen zu entwickeln. Der Linux Kernel überlebt sich ansonsten selbst!
Vision: alle Menschen haben sich lieb, darum gibt es keinen Krieg mehr.
Weg: ähhhhhhh
Ein Microkernel wäre eine Lösung. Treiber laufen dann im Userspace und man hat keine Probleme mehr.
> Ein Microkernel wäre eine Lösung. Treiber laufen dann im Userspace und man hat keine Probleme mehr.
Und das löst das Problem der Abstraktionschichten und wachsender Codegrösse wie? Du hast halt einen Haufen User daemons laufen, statt eines Kernelprozesses, so what?
Dass Linux heute als Kernel (für GNU und andere) benutzt werden kann ist unter anderem dem Umstand zu verdanken, dass es früher nicht `micro' genug war um für Akademiker als schick durchzugehen. Zum Glück. MINIX war `echt micro' und MINIX war unbrauchbar für die `real world' (genauso wie HURD, nebenbei gesagt), der Entstehungsgrund für Linux. Um dessen `microness' würde ich mir nicht unbedingt große Sorgen machen - die ist absolut auf der Höhe der Zeit und wandelt sich weiter, mit der Zeit.
Was die Geschwindigkeitseinbußen angeht, zeigt die Nachricht meiner Meinung nach vor allem eines, nämlich dass das Frühwarnsystem der Community erwartungsgemäß funktioniert. In der proprietären Welt gibt es diverse Software-Hersteller die Jahre lang hinter verschlossenen Türen an einer neuen Betriebsystemversion herumentwickeln um den Anwender pünktlich zum Release mit der ernüchternden Tatsache vertraut zu machen, dass die Performance im Vergleich zum Vorgänger unterirdisch ist
was Minix angehst, so tust Du dem ganzen Unrecht. Es sollte gar nicht wirklich gut einsetzbar sein, sondern vor allem leicht zu verändern. Der Prof. Tannenbaum hatte es zu speziell dem Zweck entwickelt und Patches mit Verbesserungen, die es aber komplexer machen, regelmäßig abgelehnt.
Dass Linux ihm als zu fett gilt, liegt nicht an den vielen Treibern. Die sind ja nur Module und werden bei Bedarf nachgeladen, sonst nicht. Das klappt ganz gut. Was es fett macht, sind eher die 4 Arten von RAID, die sich darin verewigt haben, und jeweils andere APIs und anderen Code haben. Oder fnotify, inotify und wie auch immer die Vereinigung jetzt heisst. Oder /proc, /sys und debugfs, oder jetzt auch devfs2, etc.
Es gibt Unmengen an Interfaces, die kaum mehr jemand braucht, die Last erzeugen, weil Implementierungen sie bedienen können müssen, und Code fressen. Ich hoffe dass Linus versuchen will, auf ein Linux 3.0 zu kommen, dass inkompatibel ist, und alles unnötige an Altlasten wegwirft.
Gruss,
Kay
Dem kann ich mich nur anschließen. So langsam müssen die Kernelentwickler wirklich dazu übergehen, ihre APIs zu "standardisieren", sodass es auch die Anwendungsentwickler leichter haben und sich auf die wesentlichen Dinge konzentrieren können.
Komm hoer auf mit der Polemik. Wie viele Andere sehe ich die Symptome. Die tatsächlichen Ursachen kann und muss ich nicht analysieren, solange ich nicht an der Kernelentwicklung beteiligt bin. Eine Lösung kann ich deshalb ebenfalls nicht bieten, da ich die Ursachen nicht kenne.
Bevor du dich jetzt beschwerst, dass ich dann halt mitmachen soll, also am Kernel ..... Auch ohne Teilhabe darf ich warnen! Ebenso wie viele Bürger bzgl. des Einsatzes der BW in Afghanistan kritisieren ohne vor Ort zu sein!
Auch wenn man den Kernel um nicht benutzte Module abspeckt, wird der verbleibende, absolut notwendige Rest wohl immer groesser und damit auch ein wenig langsamer. Aber natuerlich verbraucht der Kernel nur einen kleinen Teil der Rechenzeit. Das System selber wird deshalb nicht gleich um den genannten Faktor langsamer.
wieso "performance-probleme"? die aussage war doch nur, dass der kernel allmählich langsamer wird. ob sich das _spürbar_ auf die performance des systems auswirkt, ist ne andere frage.
Ich kann es nicht genau benennen, aber ich denke, seit die "Grossen" angefangen haben, für Linux zu entwickeln, wurde der Kernel aufgebläht.
Alle Unix-artigen Systeme - angefangen von Hurd über Net/Open-BSD bis hin zu Sachen wie L4 -, die noch von "Hackern" entwickelt werden, sind
im grossen und ganzen leichtgewichtig und auch gut performant.
Sobald aber grosse Firmen anfangen, die Richtung in der Entwicklung anzugeben, wie sie es eben machen bei Linux, wird es sehr schnell unübersichtlich,
aufgebläht und ähnlich schwer und fett.
Zwar nicht ganz passend aber doch als Bild gut nutzbar wäre der Vergleich von grossen Firmen entwickelten Distributionen (Suse,Redhat,ja selbst Ubuntu) - die schon bei der Basisinstallation
mehrere hundert MB bis zu paar GB installieren mit allerlei Diensten und GUIs etc., die man später mühsam ausschalten muss - und von Hackern gemachten Distros(Damnsmalllinux, Slackware, Archlinux), die
man schon auf kleinste Datenträger bekommt.
Hurd = Microkernel
L4 = Microkernel
Somit schon ein komplett anderes Konzept.
BSD, Solaris, etc.. ist zwar auch ein Monolith kommt aber kaum an die HW Unterstüzung von Linux ran.
GNU/Linux ist auch in Benchmarks einiges performanter als OpenSolaris, *BSD oder OS X. Siehe phoronox.com Benchmarks.
> Hurd = Microkernel
> L4 = Microkernel
> Somit schon ein komplett anderes Konzept.
Entscheidend ist das mit mehr unterstützen Komponenten die Komplexität von Datenstrukturen und Menge an Steueranweisungen zunimmt. Micro- und Monolithkernel hin oder her.
netBSD unterstützt (je nach Zählweise) mehr HW-Plattformen als Linux.
Wäre mir sehr neu wenn gerade auf dem Desktop wo viel unterschiedliche Hardware eingesetzt wird, NetBSD führend wäre.
War zwar ein netter Versuch von Dir aber jetzt wieder ab auf die Trollwiese.
> War zwar ein netter Versuch von Dir aber jetzt wieder ab auf die Trollwiese.
das ist nun wirklich nicht angebracht. Sein Einwand war legitim und entspricht wohlmöglich auch der Wahrheit.
Den Satz hättest du dir schlicht sparen können.
Ja ein schlankes flottes
Wenn die 'Kommerziellen' auch dafuer verantwortlich sind, kanns schon hinkommen. Immer mehr Features, immer mehr Plattformen, immer hoehere Entwicklungsgeschwindigkeit - dass das ohne jegliche Einbussen geht, ist wohl kaum moeglich.
Aber ists wirklich so ein grosses Problem? Es gibt ja noch BSD&Co, die diesen Entwicklungsdruck seitens der kommerziellen Anwender nicht so massiv abbekommen.
das wäre auch eine erklärung dafür, wieso nach all den vielen releases, für mich persönlich, noch immer 2.6.24 am "schnellsten" rennt.
gabs da nicht mal nen test drüber, das seit 2.6.24 irgendwas irrsinnige performanceverluste verursacht?
beispiel: ich betreibe mein system nur mithilfe von live cds.
knoppix mit 2.6.24 ist superflüssig. sidux mit 2.6.27 jedoch, spielt videos schon nicht mehr so flüssig ab UND die hd performance fühlt sich irgendwie langsamer an.
dasselbe gilt für 2.6.30 sidux.
bis auf weiteres, bleibe ich also auf 2.6.24
dateien, die ich mit 2.6.24 lade laufen immer flüssig.
auch geht das schreiben auf der hd mit 2.6.24 um einiges schneller.
Seit der ATi Mach64 oder der RAGE hat jede verfickte Graka extra MPEG fähigkeiten. Muss also der kleine "experte" weg von Chips und Cola und sich nen Treiber basteln der die Graka mit dem nötigen Scheiß vollnöhlt.
Deshalb ziehen HD Videos, auch beim richtigen Codec, bei fehlender Grakaunterstützung ordentlich CPU Leistung.
Ob der Kernel 2.6.24 oder 2.6.30 schneller ist oder nicht kann der normale Dekstopanwender eh nicht rausfinden, da der Xorg im Regelfall von Distri zu Distri neuer wird.
Grafikperformance macht meines Wissens zwischen den Kerneln keinen großen Unterschied. Dahingegen macht es einen riesen Unterschied, ob nun xorgs vesa-Treiber, die freien nv/radeon-Treiber oder gar die proprietären nvidia/fglrx-Treiber zum Zuge kommen.
(oder bei Intel z.B. welche Treiberversion mit welchem Beschleunigermodus: xaa, exa oder gar uxa)
So merken wird man den Unterschied von 2.6.2x und folgenden wohl eher weniger. Es sei denn, es kommen unterschiedliche Scheduler, Memory Management, etc. zum Einsatz. Das ist es aber nicht, worum es hier ging.
Intel mit uxa und gem ist nunmal schneller als mit xaa... und in der Umstellungsphase ist vieles einfach nur ein Graus...
An Xorg wird zur Zeit allerdings auch sehr viel verändert. Je nach Grafikkarte befindet sich u.U. sogar die zugehörige Kernel-Firmware mittlerweile in non-free.
Welche Grafikkarte werkelt denn in Deinem Rechner?
Laut dem letzten Posting in
http://bugzilla.kernel.org/show_bug.cgi?id=12309
will ein Tester mit Kernel 2.6.31 eine geringe Verbesserung bemerkt haben:
"There is an improvement in desktop responsiveness with kernel 2.6.31 and the as scheduler compared to the cfq scheduler. It does not solve the problem, but it makes it more sufferable."
Das Hauptproblem ist, dass es keine stabile Kernel-2.6-Reihe von kernel.org gibt (die also jetzt noch supportet wird), die diesen Bug nicht hat.
Ich persönlich setze - falls die Hardware es erlaubt - Kernel 2.4 ein, wo es nur möglich ist.
Auf dem Desktop ist der Bug nicht so wichtig. Von Win9x-Zeiten her weiß man ja wohl noch, wo im Notfall der Reset-Knopf zu finden ist. Tritt der Bug ein, so kriecht das System dahin, siehe hierzu z.B. Kommentar 325 unter obigem Link.
Falls Deine Hardware geeignet sein sollte, so lasse z.B. Slackware 11.0 mit Kernel 2.4 gegen ein neuestes Linux mit Kernel 2.6 antreten und lass deinen Rechner einmal so richtig arbeiten (mitunter reichen schon große Kopieraktionen im Rahmen des Versuchs von "Multitasking"; oder kompilier einen Kernel und arbeite gleichzeitig mit einem anderen Programmen weiter; usw.). Du wirst schnell feststellen, welches System "responsiver" ist.
Kernel 2.6-Systeme verhalten sich unter annähernder Vollast, wenn denn der I/O-Bug zuschlägt, wie damals Win95 beim Formatieren einer Diskette.
Siehe hierzu Kommentar 323 unter obigem Link:
"The irony is that it feels like Windows 95 while a floppy was formated. You know, the whole pseudo multi tasking on top of Dos - everything was really choppy. (...) If I encode a DVD with ogmrip/mencoder h264 and 16 threads (16 threads get the highest cpu usage from my quad core which is still under 80% per core) Gnome feels like a formatting Win 95."
Doch er ist GERADE auf Desktopsystemen nervig. Kopiere einfach mal ein paar Videos, ISOs, Backup,... von/zu USB-Platten und mach nebenbei was anderes, schon bist du betroffen. Mich nervt der Bug jeden Tag und kotzt mich immer mehr an. Normalerweise sind Bugs unter Linux schnell erkannt und gefixt aber hier wissen die Entwickler nicht mal wo das Problem ist.
Wenn ich versuche, ein 16 GB Backup auf eine verschlüsselte SATA-Compact-Flash Karte oder USB-Stick zu machen ist die Wahrscheinlichkeit groß, dass der Computer sich so aufhängt, dass nur noch ein Reset hilft.
Nur in kleinen Häppchen mit sync dazwischen geht das gut. Das sehe ich nicht als "nicht so wichtig" an.
Es aber gut zu wissen, was es eigentlich mit diesem "der Linux-Kernel ist fett und aufgebläht" auf sich hat.
Immerhin weißt Du definitiv, dass Du nicht "träumst".
> noch so "starke" Systeme mit 100% auslastet.
Könnte man zum Stresstesten ausnutzen...
Niveauloser geht es wirklich nicht mehr?!
Der Omega13.
lg
Erik
Mir persönlich kam ne Linux Konsole und dessen Befehle immer mehr als schnell genug vor. Nur an der GUI hängts leider noch
linux ist durchdacht, linux ist schnell, aber der xserver ist einfdach müll...
Linux hat nur schwere Knochen!
wenn linus meint das sei ihm zu fett dann interessiert mich ehrlich wo er die speckröllchen sieht.
Gesundheit!
Somit das man zum beispiel 3 Bereiche abdeckt.
Home/Office
Server
Embedded
Somit könnte man überflüssige funcionen umgehen die einfach das ganze nur unnötig an die leistung kratzen.