Am Sonntag 05 September 2010 schrieb Michelle Konzack: > Hello Martin Steigerwald, > > Am 2010-09-04 16:03:02, hacktest Du folgendes herunter: > > Meine Wette ist: Eine reine Optimierung Deines Kernels auf die CPU > > kann die von Dir wahrgenommene Trägheit des Desktops nicht beheben. > > Im Grunde würde ich was die Desktop-Performance angeht, bei modernen > > Systemen *zuletzt* auf die CPU schauen. Eine Grundlage von > > Performance-Analyse ist es, zunächst einmal herauszufinden, *wo* der > > Flaschenhals ist. > > Eben... Ich habe hier ein Development Kit Marvel Armada 300 (2000 MHz > mit 2 Gbyte DDR2) plus zwei extrem schnelle Seagate SATA Platten sowie > einem G190EG02 (192 industrial Touch Screen TFT Display) und die > Kiste ist gut 3 mal schneller als mein alter AM2 mit 3200MHz... > > MHz sagen garnischt aus... [...] > Ich denke, die Sache mit der Geschwindigeit des Desktops hängt > SEHR stark von den Applikationen ab, welch man verwendet und vor > allem, WIE SAUBER sie programmiert sind. Bei KDE habe ich erheblich > Zweifel! > > Für ich ist das chaotischer Spagetti-Code, also etwas, was ich > mir persönlich ein meinem ARM Micros nicht leisten kann... Wie z.B. > mein selbstbau Handhelt (Atmel AT91SAM9263 mit 200MHz, Formike 4"0 > 480x272/16 Micron 256 MByte SDRAM + 512 MByte NAND) Nuja, ich lasse es lieber über die Code-Qualität von KDE zu spekulieren, wenn ich mir diese nicht wirklich angeschaut hab. Aber ich denke auch, dass die Art und Weise, wie Anwendungen geschrieben sind, einen erheblichen Einfluß auf dessen Performance haben kann. > > Vielleicht - meines Erachtens höchstwahrscheinlich - ist die von Dir > > wahrgenommene Trägheit gar nicht CPU-gebunden. Du kannst also Deine > > Zeit darauf verwenden, es mit einem K7-Kernel zu versuchen. Ich > > halte es jedoch für effektiver, erstmal zu schauen, was Dein System > > während solcher Trägheitsphasen eigentlich macht. Ein Blick via > > atop, top, vmstat, iotop, collectd oder sysstat könnte da mehr Licht > > ins dunkel bringen. > > Meines erachtens profitieren nur "background processe" davon, > welche NICHT Desktop (X-Window) basierend sind und auch nicht > aus diesem gestartet wurden. > > Sprich, die Trägheit kommt davon, das daß X-Window-System > einen erheblichen RAM Speicher benötigt und dessen Geschwindigleit > und ab- arbeitung nicht von der CPU-Leistung abhängt. Ich glaube mehr, dass wirklich lange Wartezeiten auf Desktops fast immer E/A-gebunden in Bezug auf den Massenspeicher sind, zumindest bei mechanisch-magnetischen Festplatten mit hohen Seek-Zeiten. Wenn ich mit Kernel 2.6.33 KDE 4.4.5 hier starte, geht zuerst das Konsole-Fenster auf, dass ich auf einer Arbeitsfläche immer offenhabt. Wenn ich da dann einen Befehl absetze, noch bevor der Rest von KDE vollständig geladen ist, dann dauert es mitunter eine halbe Minute oder gar länger bis die Shell den Befehl geladen und ausgeführt hat. Und ich gehe davon aus, was da so lange dauert ist das Laden des Befehls. Denn: Während der Initialisierung von KDE leuchtet die Harddisk-LED meines ThinkPad T42 fast ununterbrochen. Ich wette atop würde die Plattenauslastung mit 97-100% beziffern. Mit ein Grund dafür dürfte sein, dass der KDE-Desktop und seine Anwendung extrem viele unterschiedliche kleine Dateien einladen. Daher ja auch die Arbeit zum KSharedDataCache oder wie der optimierte Cache-Mechanismus von KDE 4.5 heißt. > > Was für einen Desktop verwendest Du, was für Anwendungen laufen, > > verwendest Du Compositing, welcher Grafiktreiber usw. usf.? > > Ich verwende den integrierten 24bit RGB controller z.B. aber ich > bin dabei, einen externen PCIe am zu versuchen, senn selbst Marvel > gibt an, das der interne Controler zwar ausreciend ist, aber mit > einem Externen wesenlich mehr Leistung herausgeholt werden kann auch > wenn dieser nur 1x hat. Eigentlich habe ich die Frage an Francis gestellt, der aber nun eine Antwort zu verweigern scheint, weil dann eine ernsthafte Diskussion und Analyse starten kann, die den Troll-Effekt natürlich auf eine unangenehm niedrige Stufe bringt. > > Ansonsten lasse mich jedoch gerne eines besseren belehren. Wenn Du > > also den Superduper-Desktop-Beschleunigungskernel gebaut hast, lasse > > es mich wissen. Ich hab da auch Interesse dran. > > Da gibt es ein paar Geeks die sowas geamcht haben, spricht, die > gesammten altlasten entfernt und nur noch AM2 + unterstützen... Kein > PCI sondern nur noch PCIe usw... > > Die Kiste ist tatsäschlich schneller! > > Die Frage ist nur, ob es die Arbeit wert ist. Mit am interessantesten finde ich da noch die Arbeit von Con Koliva, der IMHO eigenen Mainline-Kernel-Entwicklern manchmal den Spiegel vorhält[1] [2]. Nicht umsonst hat er seinen jüngsten Scheduler Brain Fuck Scheduler genannt. Ich hab jedoch den Eindruck, dass CFS wirklich ganz gut, vielleicht gar besser als frühere Versuche von Con Koliva ist. Wie gut der BFS performt habe ich nicht getestet. Ich halte seine Ansicht, die Kernel-Entwickler achteten zu wenig auf die Desktop-Performance des Linux-Kernels durchaus für bedenkenswert. Aber Linux ist ja immer noch ein serverlastiges Betriebssystem und die meisten Enterprise-Kunden werden wohl für vorwiegend server-relevante Entwicklungen bezahlen. [1] http://de.wikipedia.org/wiki/Con_Kolivas [2] http://users.on.net/~ckolivas/kernel/ Ciao, -- Martin 'Helios' Steigerwald - http://www.Lichtvoll.de GPG: 03B0 0D6C 0040 0710 4AFA B82F 991B EAAC A599 84C7
Attachment:
signature.asc
Description: This is a digitally signed message part.