staging.inyokaproject.org

Noch dran, agaida?

Bei der nächsten Gelegenheit sollte man mich vor dem Arbeiten daran erinnern, warum Linus git entwickelt hat. Eigentlich wollte ich bei der Gelegenheit mal grade eben den aktuellen Kernel in mein SVN übernehmen. Das hat ein wenig gedauert und ist kurz vor dem Schluss abgebrochen.

Macht aber nichts, hier der modifizierte Patch:

## Alt
diff --git a/fs/open.c b/fs/open.c
index 04b9aad..41c87f3 100644
--- a/fs/open.c
+++ b/fs/open.c
@@ -31,6 +31,9 @@
 #include <linux/falloc.h>
 #include <linux/fs_struct.h>
 
+#define CREATE_TRACE_POINTS
+#include <trace/events/fs.h>
+
 int vfs_statfs(struct dentry *dentry, struct kstatfs *buf)
 {
 	int retval = -ENODEV;

## neu

diff --git a/fs/open.c b/fs/open.c
index 04b9aad..41c87f3 100644
--- a/fs/open.c
+++ b/fs/open.c
@@ -31,6 +31,8 @@
 #include <linux/ima.h>
 
 #include "internal.h"
+#define CREATE_TRACE_POINTS
+#include <trace/events/fs.h>
 
 int do_truncate(struct dentry *dentry, loff_t length, unsigned int time_attrs,
        struct file *filp)

Kleine Ursache, große Wirkung. So wass passiert, wenn Kernel nicht in einem Stück gepatcht werden. Wen wundert es noch, dass da wieder mal Remnand alias Remnant druntersteht. Getestet ist der patch bis mainline 2.6.37-rc7

Ja, in dem stimme ich Dir völlig zu (auch wenn ich (noch) keine Ahnung bei dieser "systemtiefen" Materie habe). Man sollte dort anfangen, wo es am meisten bringt. xfce statt kde zb. Eine Priorisierung wäre gut im Wiki. z.B., was wirklich m. E. was bringt, ist zumindest einmal beim mounten auf noatime zu wechseln. Aber den Wiki Artikel finde ich schon ganz gut. Kleine Änderung, große Wirkung. Es hat wenig Sinn, das ganze System durcheinanderzubringen, um vielleicht 5 oder 10 % Performancegewinn herauszuholen.

Tuning ist was Feines. Ich hab Linux eigentlich erst begriffen (in Ansätzen 😉), als ich an kleinen nebensächlichen Problemen gesessen habe. Für den Anfang: Springende und hakende Eingaben per Tastatur, Mausthemen, Dekorations usw. Das Böse an dem Versuch einer wie auch immer gearteten Beschleunigung ist das Anspruchsdenken vieler User. Das erreicht dann teilweise recht absurde Formen der Beschäftigung mit der Materie, die ich, ich gestehe es, auch alle durchlaufen habe. Dazu gehört

• Kernelbau

• Overclocking

• Einsatz von "Wunderpatches"

• die Idee, dass die nächste Nummer von Paket XY das allein seelig machende ist.

IMHO der falsche Ansatz. Kernelbauen und optimieren ist hübsch, nur leider definitiv für viele Leute ungeeignet. Die Geduld, die man braucht, um einen Kernel vernünftig anzupassen und dann eventuell noch zu patchen, haben die wenigsten. Meist ist im Endeffekt nur die psychologische Seite entscheidend. Um nicht nur leichte Kosmetik zu betreiben, ist für den ersten eigenen Kernel, der wirklich gut ist, eine Zeit von ein bis zwei Wochen zu veranschlagen, die man braucht, sich überhaupt in die Materie einzuarbeiten, vorausgesetzt, man hat überhaupt gewisse Grundkenntnisse. Der Haupteffekt ist dann aber nicht der neue Kernel, sondern das tiefere Verständnis der Sachen, die im System passieren. Genau das macht dann ein System schnell.

Zu Overclocking sag ich mal nichts, habe ich lang und schmutzig selbst betrieben, ist ganz witzig und führt in vielen Fällen zu einem instabilen System, weil oftmals an Reglern gedreht wird, die eh schon am Anschlag stehen. Auch hier wieder. Der Effekt kommt nicht durch durch OC an sich, sondern durch das Verständnis.

Alle Woche kommt ein Wunderpatch auf den Markt, das ist wie bei Diäten - einfach sinnlos. Solche Sachen wie z.B. das grade gepostete Tracing mal ausgenommen, aber das ist in Ubuntu schon eingebaut. Auch das Group-Scheduling wird was bringen, man kann aber davon ausgehen, das das in irgend einer Form in Natty drin ist.

Zu neuen Programmversionen sag ich mal nichts, ein Blick in die Quellen verrät, dass auch hier meist die psychologische Wirkung die größte ist. Von Ausnahmen abgesehen ist das leider so, eine Ausnahme ist zum Beispiel der neue Catalyst, der mit X scheinbar so zusammenarbeitet, dass dieses nervige laggen (Minimize-Maximize-Bug) auf ein Minimum reduziert ist und sich in den ersten Minuten nach dem Neustart nicht mehr auswirkt. Hab ich aber noch nicht nachvollziehen können, die einen sagen so, die anderen so.

Die Propagierung von schlankeren Programmen ist durchaus sinnvoll, wenn damit noch ein flüssiges Arbeiten sinnvoll ist. Ein Beispiel dafür war CrunchBang, was leider nicht mehr auf Ubuntu, sondern wieder auf Debian basiert. Die großen Pakete wie KDE oder Gnome sind halt nicht die Renner, LXDE auch nicht mehr. Da muss man schon radikaler werden.

An der Speicherschraube und Prozessorleistung kann man auch kaum noch drehen, das einzige, was im letzten halben Jahr mein System deutlich beschleunigt hat war die kleine SSD. Ich muss zugeben, dass ich diesen massiven Effekt nicht erwartet hätte, das war gigantisch.

Hallo agaida, sehr interessantes Posting. Ich lese immer gern, wies anderen ergangen ist anstatt theoretische Anleitungen. Jetzt hat mich das mit der SSD Platte schon recht neugierig gemacht: Wie wirkt(e) sich das im direkten Vergleich aus. Programmstarts und Responses sind ja schlecht zu messen, deswegen frage ich nach der Bootzeit. Startdauer Vergleich etwa zwischen herkömmlicher Festplatte und SSD Festplatte (Verhältnis etwa 2:1 3:1 4:1 ...)?

Ich frage mich auch noch, wie man die in ein Notebook (Acer Aspire) hineinbekommt (platzmässig)? Man müsste evtl. auch die alte Harddisk drinnen lassen, so dass man sie vielleicht für größere Dateien (Videos, Bilder,...) hernimmt und zwei oder drei Partions (für Linux und Windows) voll verwenden könnte (weil 64 GB sind ja anscheinend so üblich).

Im Forum nach Bootchart SSD schauen. Nicht dass wir uns falsch verstehen. Ich sehe in sinnvollem Tuning die Massnahmen, die ein System vielleicht nicht schneller machen, aber z.B. responsiver. Das ist ein Unterschied. Ein System kann rattenschnell sein und sich trotzdem anfühlen wie ein 8088. Solche Sachen sind dann oft nur Feinheiten, die aber sehr oft einen entscheidenden AHA-Effekt bringen. Das System an sich ist dadurch aber in keiner Weise schneller geworden, nur besser bedienbar. Mehr Rechenleistung erreicht man nur durch mehr Rechenleistung. Dass man vorhandene Rechenleistung aber ausnutzt, dass sollte das Ziel sein. Da hat Ubuntu im Standard schon recht viel an Board, was das Leben schön macht.

Ansonsten sind die Regeln seit Generationen gleich: Schlank bleiben, keinen Ballast mitführen, Flaschenhälse entfernen. Und der größte Flaschenhals momentan ist halt die nichtflüchtige Speicherung von Daten, sprich irgendeine Form von Datenträger. Der zweite Punkt ist die Benutzerschnittstelle - eine hakende Tastatur, springende Mauszeiger und eine Verzögerung bei der Ausgabe bemerkt man halt sofort und die stört. Ob ein Kernel in 48 oder 42 Minuten baut, ist da eher von akademischem Interesse. Beide Zeiten sind viel zu lang, wenn man dringen darauf wartet. Kann ich aber in der Zeit des Bauens den Rechner in seiner Gesamtheit nicht mehr bedienen, stört das natürlich noch mehr. Das sind so die Punkte, die auch durch die aktuellen Entwicklungen adressiert werden. Wie man da allerdings noch mehr als hier vorhanden eine Systematik reinbringen kann, weiss ich nicht wirklich.

Hey, vielen Dank!

In deinem ersten Posting stimme ich dir völlig zu, viel bringen wird Kerneltuning mit Sicherheit nicht. Allerdings reizt mich hier auch mehr die Beschäftigung mit der Materie als solches. Ich würde z.B. sehr gern mal einen Kernel bauen der wirklich nur das enthält was mein System tatsächlich braucht. Mir ist schon klar, daß das Leistungsmäßig nichts bringt, schließlich wird ohnehin nur das geladen was sinnvoll ist.

Aber der Sport reizt mich eben. Allerdings ist es wirklich schwierig ganz Treiberzweige sauber auszubauen. Wenn ich bisher etwas in der Art versucht habe, habe ich wohl meist zu viel entfernt, was dazu führte daß der Kompiliervorgang irgendwann mit Fehlern abbrach. Und das obwohl ich genau darauf geachtet habe nichts zu entfernen was ich brauche. Scheinbar sind da oftmals Abhängigkeiten vorhanden die man nicht gleich durchschaut.

Nun, so schnell gebe ich nicht auf. Und für alle, die auch mal Lust auf einen eigenen Kernel haben: es macht echt Spaß sich damit zu befassen. Einfach weil es geht. 😉

Die Antwort bei Kernelbasteln als Sport kannst Du Dir sicherlich vorstellen: Arch oder Gentoo. Und für mich ganz wichtig, eine "ordentliche" Oberfläche, bei der ich hin und herspringen kann, wie xconfig. Den Textkram find ich irgendwie hassenswert, vor allem wenn man ein wenig mit den verschiedenen Modulen spielen will. Was ich beim basteln unter Arch auch noch immer sehr witzig fand ist wirklich der Einsatz von git für die Konfigurationen in Arbeit. Nichts finde ich wiederlicher, als wenn durch eigenen Dummsinn eine Konfiguration überschrieben wird, an der man schon längere zeit gearbeitet hat.

Der Fairness halber muss ich auch erwähnen, dass die meisten Arch-Konfigurationen im AUR recht bescheiden geschrieben sind, die sind nur für Einmalbau ausgelegt, so dass man erst mal das Scripting ändern muss. Auf jeden Fall wird man aber im allgemeinen nicht blöder dadurch. BTW ein paar Grundeinstellungen, die das Leben am Anfang wesentlich erleichtern: Staging raus, Telefonie raus, Video raus, TV raus. Spart bei der Grundkonfiguration ca 60% der Kompilierzeit und einige Fehler. Bei den letzten Mainlinekerneln war zudem immer wieder ein nerviger Bug in der Konfiguration bei der Integration von irgendwelchen obskuren bin-Dateien (Firmware) für Hardware, von der ich noch nie gehört habe. Die werden natürlich immer kurz vor Schluss verarbeitet und fallen mit permanenter Boshaftigkeit auf die Nase. Diese Zeilen sollte man also gleich nach dem ersten Fehler rauspatchen.

Einen kleinen noch zum Schluss: Du hast das ja schon erwähnt: Linus Test mit dem Group-Scheduling. Beim Bauen sollte man sich nicht davor scheuen, auch mal einen -j3 oder 4 auf einem Doppelkern und ein wenig mehr auf einem Quad mitzugeben. Das beschleunigt die Sache ungeheuer und die Kernel sind darauf ausgelegt, parallel gebaut zu werden. Mein "Rekord" sind mit Quellen holen bis zu fertigen Paket 4 min. Bei 1 min fang ich mit Gentoo an. Dann hab ich die passende Hardware.

Mal so nebenbei... bei dem Patch den du hochgeladen hast... normalerweise müsste ich da doch unter Kernelhacking/Tracers die Option "Trace process context switches and events" aktivieren, oder? Die ist bei mir nämlich ausgegraut und lässt sich auch nicht zuschalten.

Einspielen und glücklich sein. Das war's. Das ist ja kein Kernelhacking an sich, die Dinge die da gemeint sind, sind andere Marker und Möglichkeiten, die dann ausgelöst werden. Der Patch mach ja nur eine Verfolgung der Files möglich, die dann von ureadahead abgegriffen werden. Der hat keinen Schalter.

Ok, fein. War nur etwas irritiert da zu dem Patch im Gentoo-Forum eine etwas anders lautende Anleitung existierte. Aber trotzdem: vielen Dank für die Hilfe soweit! ☺

Ich kann dazu nur sagen, wir haben das Ding eingespielt und gut wars. Der hat dann brav die Files zusammengesammelt.

Hat super geklappt, mit etwas Geduld. Man sollte in Jedem Fall gute Dokumentationen zur verbauten Hardware und ein Tool wie hwinfo haben. Die initrd ist nun nur noch 3 MB groß, die Pakete linux-headers und linux-image haben zusammen 13,3 MB. Das Einzige was ich leider nicht geschafft habe ist den Suspendmodus meines Notebooks mit angeschlossener SB Audigy PCMCIA zu reparieren.

Wo bekomme ich einen Patch für das automatic task group scheduling her der mit dem 2.6.37 rc8 funktioniert? Ich suche mir da seit gestern schon den Wolf, scheint als wäre ich zu dämlich google mit den richtigen Suchanfragen zu füttern...

Edit: schon Ok, habe gerade meinen ersten Patch selbst gepatcht. 😀

Mist, klappt doch nicht. Der Patch wird zwar erfolgreich eingespielt, beim kompilieren brichts aber immer wieder ab:

Kann ich nochmal auf deine Hilfe hoffen, agaida?

Edit: Info, folgende Zeile habe ich ergänzt um den originalen Patch zu "patchen":

 /* Change a task's cfs_rq and parent entity if it moves across CPUs/groups */
@@ -1920,6 +1928,7 @@  static void deactivate_task(struct rq *r
 #include "sched_idletask.c"
 #include "sched_fair.c"
 #include "sched_rt.c"
+#include "sched_autogroup.c"
 #include "sched_stoptask.c"
 #ifdef CONFIG_SCHED_DEBUG
 # include "sched_debug.c"
 #endif

Den Originalpatch habe ich von hier.