kanotix.com

Installation, Einstellungen, Systempflege - Neuer Titel: Test 2.6.31 mit/ohne "bfs"-Patch

jesko - 16.10.2009, 06:29 Uhr
Titel: Neuer Titel: Test 2.6.31 mit/ohne "bfs"-Patch
Ich möchte beide Kernel-Versionen von

linux-image-2.6.31-14-generic_2.6.31-14.47_i386.deb

- mit und ohne "bfs"-Patch - zu Testzwecken in der gleichen Installation benutzen können.

Ich habe zunächst probeweise die "bfs"-Version mithilfe von Kanos

get-source-compile-generic-kernel-git-offline.sh-Skript

aus dem Paket source-bfs.tar.gz erstellt und installiert.

Problem: die mit dem Skript erzeugte Version heißt genauso wie das fertige Kernel-Paket (ohne "bfs"-Patch) aus dem Excalibur-Repository.

Wie erzeuge ich nun eine "bfs"-Namensvariante,

z.B. linux-image-2.6.31-14-bfs_2.6.31-14.47_i386.deb

aus dem lokal gespeicherten Source-Tree?

-jesko
Kano - 16.10.2009, 13:08 Uhr
Titel: Namenskonflikt 2.6.31-14 mit/ohne "bfs"-Patch
Der -14- kernel hat bfs im Repo. Kannst doch einfach gegen -12- vergleichen, performancemässig wirds da keinen Unterschied geben zwischen 2.6.31.2 und 2.6.31.4.

dmesg|grep BFS

zeigt es dir.
jesko - 17.10.2009, 10:47 Uhr
Titel:
Hier mein Benchmark:

HD-Installation: kanotix-2.6.31.iso
CPU: q9400
a) Laufender Kernel: 2.6.31-10-generic (kein bfs-Patch!)
b) Laufender Kernel 2.6.31-14-generic aus git-Quellen mit Kanos Skript neu kompiliert

Bei a) und b) wurde jeweils der gleiche Plain-Vanilla-Kernel linux-2.6.31.4 (kernel.org) mit identischer Kernel-Konfiguration .config=file:///boot/config-2.6.31-10-generic kompiliert.

Kompilierzeit mit Kernel a)
AchimsBox:/usr/local/src/linux-2.6.31.4# time make -j 4 bzImage
...
real 4m7.914s
user 10m16.491s
sys 1m3.508s


Kompilierzeit mit Kernel b)
AchimsBox:/usr/local/src/linux-2.6.31.4# time make -j 4 bzImage
...
real 3m26.095s
user 9m55.489s
sys 0m32.390s

Kommentar:
1) Eine "-12er"-Version von Kanos 31er-Kernel konnte ich nicht finden.
2) Bekanntermaßen ist "-j 4" für einen Nicht-bfs-Kernel suboptimal, dagegen für einen "bfs"-Kernel optimal.

-jesko
P.S.: Vgl. Kommentar zu den "sys"-Zeitanteilen im folgenden Beitrag von mir.
Kano - 17.10.2009, 12:57 Uhr
Titel:
Naja was du da kompiliert hast ist ja nur der statische anteil, was wirklich lange dauert sind die ganzen module.
jesko - 17.10.2009, 19:32 Uhr
Titel:
Kano hat folgendes geschrieben::
Naja was du da kompiliert hast ist ja nur der statische anteil, was wirklich lange dauert sind die ganzen module.

... genau.

Deshalb hier Teil 2 Kompilierzeit Module unter sonst gleichen Bedingungen wie oben, also:

HD-Installation: kanotix-2.6.31.iso
CPU: q9400
a) Laufender Kernel: 2.6.31-10-generic (kein bfs-Patch!)
b) Laufender Kernel 2.6.31-14-generic aus git-Quellen mit Kanos Skript neu kompiliert

Bei a) und b) wurde jeweils der gleiche Plain-Vanilla-Kernel linux-2.6.31.4 (kernel.org) mit identischer Kernel-Konfiguration .config=file:///boot/config-2.6.31-10-generic kompiliert.

Kompilierzeit mit Kernel a)
AchimsBox:/usr/local/src/linux-2.6.31.4# time make -j 4 modules
...
real 17m46.130s
user 47m51.007s
sys 4m36.757s


Kompilierzeit mit Kernel b)
AchimsBox:/usr/local/src/linux-2.6.31.4# time make -j 4 modules
...
real 15m55.382s
user 46m39.563s
sys 2m20.993s

Kommentar:
das Verhältnis des "sys"-Zeit-Anteils bei Kompilation mit dem Kernel mit bfs-Patch zu demjenigen bei Kompilation mit dem Kernel ohne bfs-Patch beträgt etwa 1:2 (!).

-jesko
caillean - 18.10.2009, 08:22 Uhr
Titel:
Hallo,

ich denk du bist da einem Irrtum aufgesessen.
Afaik müssen user und sys-zeit zusammengezählt werden, dann kannst du erkennen wieviel Cpu-Zeit der Prozess gebraucht hat.
http://stackoverflow.com/questions/556405/what-do-real-user-and-sys-mean-in-the-output-of-time1
Das wären hier effektiv nur grad mal ca. 3 Minuten, die der BFS-kernel schneller war.

OT:
Abgesehen davon finde ich es Tünnef, dass der bfs-gepatchte Kernel durch den vom Bot im Channel gegebenen Befehl für den 31-14er Kernel installiert wird.
Zum einen weil es schon noch passieren kann, dass der Kernel dann nicht bootet.
Zum anderen stellt sich mir ernsthaft die Frage, wer von den Kanotix-Nutzern so viele Kernel oder andere Anwendungen kompiliert, dass es sich in der Zeit bemerkbar machen sollte.

Wer den bfs-sheduler braucht, weil er viele Dinge kompiliert, der sollte schon in der Lage sein, sich diesen Patch selber in den Kernel einzupflegen, alle anderen sollten die Wahl haben den Sheduler nicht nutzen zu müssen Smilie
jesko - 18.10.2009, 09:57 Uhr
Titel:
caillean hat folgendes geschrieben::

ich denk du bist da einem Irrtum aufgesessen.
Afaik müssen user und sys-zeit zusammengezählt werden,

Nein, nein. Da wird nichts zusammengezählt.

NB: In meinen Beispielen kommt die Tatsache, dass ("user"-time) > ("real"-time) ist, daher, dass unter "user" einzeln die Zeiten der vier parallel arbeiteten CPU-Kerne addiert werden.

Ansonsten: bitte lies in Deinem Zitat die Definition von "real" nach. Die ist selbstverständlich richtig. Bei Bedarf übersetze ich gerne ...
caillean hat folgendes geschrieben::

Wer den bfs-sheduler braucht, weil er viele Dinge kompiliert, ...

Derjenige braucht ihn nicht wirklich. Ich auch nicht.

Ehe man solche Urteile abgibt, sollte man sich informieren. Am besten beim Autor Con Kolivas.

-jesko
caillean - 18.10.2009, 10:27 Uhr
Titel:
Sorry, aber ich denke, Du solltest lieber richtig lesen und zwar meinen Beitrag genauso wie den Link, den ich eingestellt habe! Smilie

Google doch mal selber nach "real user sys", dann wirst du etliche Seiten finden, wo du nachlesen kannst, dass wenn das ganze gebenchmarkt werden soll, schon die Zeiten von user und sys zusammengezählt werden !

Und übersetzen brauchst Du mir die von mir verlinkte Seite nicht, ich kann sehr wohl Englisch lesen und verstehen, aber Du ja vielleicht nicht Sehr glücklich

Und denk nicht, ich hätte mich nicht informiert, ich bin inzwischen der Meinung, dass alles nur noch darum geht schneller, neuer und toller sein zu müssen. Hauptsache man hat es egal ob es was bringt oder nicht.
Meiner Meinung nach sollten die User schon noch ne Auswahl haben was sie für einen Kernel haben wollen.
Was bringen Euch Sekunden um die es hier geht...

Und dieses ganze Benchmark-Getue ist in meinen Augen echt albern!
So und jetzt kannst du mich bashen. Sehr böse
conchy - 18.10.2009, 10:45 Uhr
Titel:
caillean!
Da gebe ich Dir 100% recht.
Gruss P.S
Kano - 18.10.2009, 13:44 Uhr
Titel:
Interessant ist nur die REAL zeit. Ich kompiliere übrigens mplayer (über meine svn/git/vaapi) scripte noch viel häufiger als kernel - ist auch viel kleiner *g*
caillean - 18.10.2009, 14:03 Uhr
Titel:
Kano hat folgendes geschrieben::
Interessant ist nur die REAL zeit. Ich kompiliere übrigens mplayer (über meine svn/git/vaapi) scripte noch viel häufiger als kernel - ist auch viel kleiner *g*


jesko:

Und das sind effektiv ca 2 Minuten schnelleres kompilieren, und nicht ein völlig verdrehtes 1:2 Verhältnis, wie Du behauptet hast. Lachen

jesko hat folgendes geschrieben::
Kommentar:
das Verhältnis des "sys"-Zeit-Anteils bei Kompilation mit dem Kernel mit bfs-Patch zu demjenigen bei Kompilation mit dem Kernel ohne bfs-Patch beträgt etwa 1:2 (!).


Darum auch mein Link vorhin, um Dir zu verdeutlichen, dass ein Vergleich der sys-Zeit NICHTS aussagt. Lachen
jesko - 27.10.2009, 00:46 Uhr
Titel:
Leider habe ich bislang keines der wirklich einschlägigen Programme zu Testzwecken eingesetzt, die den für den Desktopeinsatz relevanten Interaktivitätsgewinn eines 2.6.31er Kernels mit BFS-Patch zeigen. Da mögen meine Kommentare zum Kompiletest irreführend gewesen sein.

Aber: um einen eigentlichen Geschwindigkeitstest des Compilers konnte es da sowieso nicht gehen. Grund: Compiler, Kernelquelle und Kernelkonfiguration waren in beiden Fällen identisch.


Es konnte bei dem Test also gerade nicht um die "user"-Zeiten gehen.

Dass trotzdem die "user"-Zeiten voneinander abwichen, ist daher eher zufällig.

Um den aktuellen BFS-Patch auch mit Kanos o.a. Skript benutzen, muß dieser leicht verändert werden. Was zu tun ist, entnimmt man der Fehlermeldung des patch-Befehls.

http://www.pubbs.net/kernel/200910/30352/

-jesko
jesko - 11.11.2009, 12:59 Uhr
Titel:
Ich habe versucht, aus Kanos git-Quellen - mit den naheliegenden Anpassungen von Kanos Skript und dem neuen 3.10er bfs-Patch

http://ck.kolivas.org/patches/bfs/2.6.3 ... -310.patch

einen Kernel zu bauen. Kompiliert nicht.

Selbstverständlich läßt sich aber ein mit dem (unveränderten) bfs3.10er-Patch gepatchter Vanilla-Kernel kompilieren - der auch funktioniert.

-jesko
jesko - 14.11.2009, 11:45 Uhr
Titel:
Das Paket source-bfs.tar.gz wurde nun von Kano upgedatet. Damit läßt sich aus den git-Quellen ein Kernel (vmlinuz-2.6.31-14-generic) mit bfs310er-Patch bauen.

Was der Unterschied dieses so erzeugten Kernels zu dem ebenfalls neuen Kernel im Paket linux-image-2.6.31-16-generic_2.6.31-16.51_i386.deb ist, weiß ich nicht.

-jesko
Kano - 14.11.2009, 11:53 Uhr
Titel:
Du hast wohl das offline script benützt, dann lädt es natürlich nicht den neuesten snapshot.
jesko - 14.11.2009, 12:33 Uhr
Titel:
Danke! Das war die Erklärung.

-jesko
Alle Zeiten sind GMT + 1 Stunde
PNphpBB2 © 2003-2007