| Autor |
Nachricht |
|
|
Titel: Neuer Titel: Test 2.6.31 mit/ohne "bfs"-Patch
 Verfasst am: 16.10.2009, 06:29 Uhr
|
|
Anmeldung: 17. Nov 2004
Beiträge: 118
Wohnort: Berlin Germany
|
|
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 |
Zuletzt bearbeitet von jesko am 17.10.2009, 19:41 Uhr, insgesamt 2 Male bearbeitet
|
| |
|
|
|
 |
|
|
|
Titel: Namenskonflikt 2.6.31-14 mit/ohne "bfs"-Patch
Verfasst am: 16.10.2009, 13:08 Uhr
|
|
Anmeldung: 17. Dez 2003
Beiträge: 16792
|
|
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. |
|
|
| |
|
|
|
|
|
|
|
Titel:
Verfasst am: 17.10.2009, 10:47 Uhr
|
|
Anmeldung: 17. Nov 2004
Beiträge: 118
Wohnort: Berlin Germany
|
|
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. |
Zuletzt bearbeitet von jesko am 17.10.2009, 19:37 Uhr, insgesamt 2 Male bearbeitet
|
| |
|
|
|
|
|
|
|
Titel:
Verfasst am: 17.10.2009, 12:57 Uhr
|
|
Anmeldung: 17. Dez 2003
Beiträge: 16792
|
|
| Naja was du da kompiliert hast ist ja nur der statische anteil, was wirklich lange dauert sind die ganzen module. |
|
|
| |
|
|
|
|
|
|
|
Titel:
Verfasst am: 17.10.2009, 19:32 Uhr
|
|
Anmeldung: 17. Nov 2004
Beiträge: 118
Wohnort: Berlin Germany
|
|
|
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 |
|
|
| |
|
|
|
|
|
|
|
Titel:
Verfasst am: 18.10.2009, 08:22 Uhr
|
|
Anmeldung: 18. Mai 2008
Beiträge: 205
Wohnort: Schleswig-Holstein
|
|
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  |
|
|
| |
|
|
|
|
|
|
|
Titel:
Verfasst am: 18.10.2009, 09:57 Uhr
|
|
Anmeldung: 17. Nov 2004
Beiträge: 118
Wohnort: Berlin Germany
|
|
|
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 |
|
|
| |
|
|
|
|
|
|
|
Titel:
Verfasst am: 18.10.2009, 10:27 Uhr
|
|
Anmeldung: 18. Mai 2008
Beiträge: 205
Wohnort: Schleswig-Holstein
|
|
Sorry, aber ich denke, Du solltest lieber richtig lesen und zwar meinen Beitrag genauso wie den Link, den ich eingestellt habe!
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 
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.  |
Zuletzt bearbeitet von caillean am 18.10.2009, 11:09 Uhr, insgesamt ein Mal bearbeitet
|
| |
|
|
|
|
|
|
|
Titel:
Verfasst am: 18.10.2009, 10:45 Uhr
|
|
Anmeldung: 23. Jun 2005
Beiträge: 371
Wohnort: El Coronil (Sevilla)
|
|
caillean!
Da gebe ich Dir 100% recht.
Gruss P.S |
|
|
| |
|
|
|
|
|
|
|
Titel:
Verfasst am: 18.10.2009, 13:44 Uhr
|
|
Anmeldung: 17. Dez 2003
Beiträge: 16792
|
|
| 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* |
|
|
| |
|
|
|
|
|
|
|
Titel:
Verfasst am: 18.10.2009, 14:03 Uhr
|
|
Anmeldung: 18. Mai 2008
Beiträge: 205
Wohnort: Schleswig-Holstein
|
|
|
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. 
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. |
|
|
| |
|
|
|
|
|
|
|
Titel:
Verfasst am: 27.10.2009, 00:46 Uhr
|
|
Anmeldung: 17. Nov 2004
Beiträge: 118
Wohnort: Berlin Germany
|
|
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 |
|
|
| |
|
|
|
|
|
|
|
Titel:
Verfasst am: 11.11.2009, 12:59 Uhr
|
|
Anmeldung: 17. Nov 2004
Beiträge: 118
Wohnort: Berlin Germany
|
|
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 |
|
|
| |
|
|
|
|
|
|
|
Titel:
Verfasst am: 14.11.2009, 11:45 Uhr
|
|
Anmeldung: 17. Nov 2004
Beiträge: 118
Wohnort: Berlin Germany
|
|
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 |
|
|
| |
|
|
|
|
|
|
|
Titel:
Verfasst am: 14.11.2009, 11:53 Uhr
|
|
Anmeldung: 17. Dez 2003
Beiträge: 16792
|
|
| Du hast wohl das offline script benützt, dann lädt es natürlich nicht den neuesten snapshot. |
|
|
| |
|
|
|
|
|
|
|
Titel:
Verfasst am: 14.11.2009, 12:33 Uhr
|
|
Anmeldung: 17. Nov 2004
Beiträge: 118
Wohnort: Berlin Germany
|
|
Danke! Das war die Erklärung.
-jesko |
|
|
| |
|
|
|
|
|
|
