Wie lange dauert eine Neukompilierung bei euch?

[Pix]

Hallo,

ich habe mir den Kernel 2.6.24.x kompiliert und war erschrocken wie lange mein PC dafür benötigt hatte. Knapp 4h gingen ins Land, und ich muss gestehen, da kam schon Frust auf. Ich kann mich noch an Zeiten erinnern, wo ich für einen Kernel 2.4.x nur ~20min und für einen Kernel 2.6.1x etwa 50min brauchte, alles Erstkompilierung, also kein Libraries Objektdateien etc. vorhanden. Aber nun 4h ist arg viel Zeit.

Meine Frage:
1. Wie lange benötigt ihr für eine erstmalige Kompilierung des Kernels, und warum dauert das bei mir verdammt noch mal so lange?
2. Was ist wichtiger hinsichtlich der verträglichen Kompilierungszeit eines Kernels: Mehr Kerne (Dual/Quadcore) oder mehr RAM?

Danke Dirk

PS: Mein PC – ein PII 400MHz, 384 BM RAM

[mistersixt]

Na ja, ein PII mit 400 Mhz. ist halt nicht mehr wirklich aktuell... der Kernel wächst halt stetig, und gerade bei den letzten Versionen ist extrem viel dazugekommen.

Gruss, mistersixt.

[nepos]

Mein Laptop (Pentium M, 1,8 GHz, 512 MB RAM) baut der nen 2.6.18er Kernel in ca. 10-15 Minuten.

[Six]

Meine Frage:
1. Wie lange benötigt ihr für eine erstmalige Kompilierung des Kernels, und warum dauert das bei mir verdammt noch mal so lange?

a) ca. 10 Minuten auf einem Turion TL60
b) weil dein Prozessor -- und vermutlich die ganze Maschine -- verdammt noch mal so alt sind.

2. Was ist wichtiger hinsichtlich der verträglichen Kompilierungszeit eines Kernels: Mehr Kerne (Dual/Quadcore) oder mehr RAM?

Ab eine bestimmten RAM-Größe profitierst du bei der Kernel-Kompilierung nicht mehr wirklich von mehr RAM. Ich schätze, die Untergrenze liegt bei 512 MB. Wissen tu ich das aber nicht. Und mehr Dampf ist immer gut. Wenn du wissen willst, wo du schrauben mußt, dann würde ich tippen: verlorene Liebesmüh.

[armin]

Mein Laptop (Pentium M, 1,8 GHz, 512 MB RAM) baut der nen 2.6.18er Kernel in ca. 10-15 Minuten.

Das ist dann aber kein Debian-Kernelkonfiguration, sondern schon was ordentlich abgespecktes, oder?
Soweit ich mich erinnere brauche ich um einen Debian-Kernel mit original Config zu bauen etwa eine Stunde. Wenn nur das nötigste dabei ist kommt man natürlich schonn Mal in unter 10 Minuten hin.

[jensm]

Bei meinem letzten Male (leider mit Kernel panic geendet) hatte das so ungefähr 45 Minuten gedauert.
Aber da war mit Sicherheit einiges Zeugs dabei was ich hätte rausschmeissen können.

[nepos]

Mein Laptop (Pentium M, 1,8 GHz, 512 MB RAM) baut der nen 2.6.18er Kernel in ca. 10-15 Minuten.

Das ist dann aber kein Debian-Kernelkonfiguration, sondern schon was ordentlich abgespecktes, oder?
Soweit ich mich erinnere brauche ich um einen Debian-Kernel mit original Config zu bauen etwa eine Stunde. Wenn nur das nötigste dabei ist kommt man natürlich schonn Mal in unter 10 Minuten hin.

Stimmt, das ist mein Kernel, der nur noch die nötgen Sachen enthält.

[Danielx]

Knapp 4h gingen ins Land
(...)
PII 400MHz, 384 BM RAM

Das sind durchaus normale Werte für deinen Rechner.

Hier mal zwei ausgewählte Werte von mir, sozusagen als Vergleich alt zu neu:
Auf einem PIII 700MHz, 256 MB RAM hat es 4h 25min gedauert.
Auf einem Core2Duo 1,8 GHz, 1 GB RAM dagegen nur 8min 35sec (mit CONCURRENCY_LEVEL=4).
Jeweils bei einem 2.6.18-er Kernel mit der Standard-Config aus Debian.

Gruß,
Daniel

[KBDCALLS]

Auf einem PIII 700MHz, 256 MB RAM hat es 4h 25min gedauert.
Auf einem Core2Duo 1,8 GHz, 1 GB RAM dagegen nur 8min 35sec (mit

Gruß,
Daniel

Wobei der Kiste etwas mehr Ram gut tun würde.

Die Hauptbremse dürfte sein wenn er anfängt zu swappen.

Wie heißt es so treffend. Ram ist durch nichts zu ersetzen , außer durch mehr.

[mistersixt]

Also auf einem 4-fach QuadCore (also quasi mit 16 CPUs) mit je 2.93 Ghz, 32 GB RAM und einem "make -j 16" dauert eine Debian-Kernel mit sämtlichen Modulen 1 Minute 48 Sekunden ...

[Aliquando]

Von der Debian-Standardkonfiguration ausgehend braucht mein PIII mit 550 MHz und 384 MB RAM für einen 2.6.22 gute 3 1/2 bis 4 Stunden, mein P4 mit 2,4 GHz und 768 MB RAM nicht ganz 1 1/2 Stunden.
Zumindest auf dem P4 war aber längst nicht der ganze RAM benutzt, dafür lief die CPU aber konstant bei 100% Last.

[storm]

Nicht zu vergessen: die gcc-Version. Da ergeben sich auch ordentliche Unterschiede. Beschleunigen könnte man das (bei ausreichend Speicher) auch durch Auslagern des Codes in eine ramdisk. Die brauch aber allerhand Platz (grobe Schätzung: 3 x source-Größe). Und während des Kompilierens alles unnötige ausmachen. Bei häufigeren Kompilieren empfiehlt sich auch noch ccache, dafür braucht dann da das erste Mal erheblich länger um den cache erstmal zu füllen.
Oder gleich cross auf einer schnelleren Maschine machen.

ciao, storm (baut im Regelfall in <5min einen neuen Kern)

/edit: @mistersixt, schöne Maschine. *g -- Du könntest doch sogar mit -j 32 arbeiten?

[cirrussc]

Also auf einem 4-fach QuadCore (also quasi mit 16 CPUs) mit je 2.93 Ghz, 32 GB RAM und einem "make -j 16" dauert eine Debian-Kernel mit sämtlichen Modulen 1 Minute 48 Sekunden ...

boa in 2 min mal eben nen neuen Kernel, da kann man ja probieren was das Zeug hält.
Wieso 16 CPU's? Selbst mit Intels Hyper Threading wären es nur 8 Virtuelle!?

Bei mir dauert der komplette make-kpkg Durchgang (CONCURRENCY_LEVEL=4, also auch headers, und manual debs)
so ca 30 min.

[towo]

Wiso 16 CPU's? Selbst mit Intels Hyper Threading wären es nur 8 Virtuelle!?

Du hast den Poste gelesen?

4x4 ist 16, schon immer.
Und ein Quadcore hat 4 Kerne, macht bei 4 Quadcore 16 CPU, Mathematik 2. Klasse.

[cirrussc]

Du hast den Poste gelesen?

jain
Hab das 4-fach Weggedacht.

[bse]

Beschleunigen könnte man das (bei ausreichend Speicher) auch durch Auslagern des Codes in eine ramdisk. Die brauch aber allerhand Platz (grobe Schätzung: 3 x source-Größe).

Ich habe das mal überprüft, weil ich anderer Meinung war und bin
Getestet: Linux-2.6.25-rc7 mit handgeschnitzter config, auf einem Core 2 Duo, compiliert mit "time make -j3 -s"

HDD (Seagate Barracuda 7200.9 (ST3250624AS)):

Code: Alles auswählen

real	3m45.341s
user	6m24.044s
sys	0m46.151s

tmpfs:

Code: Alles auswählen

real	3m36.332s
user	6m23.316s
sys	0m44.079s

... und nein, geswappt hat er dabei sicher nicht, ich hab nämlich ausreichend Speicher und keinen Swap.

Ich stimme aber zu, dass die Compilerversion und die CONFIG einen wesentlichen Einfluss haben. Angeblich verwenden manche Kernelentwickler deshalb ja immer den ältesten GCC, der den Kernel noch compilieren kann.

BTW: Nach erfolgreichem Compile:

Code: Alles auswählen

$ df /dev/shm
Filesystem           1K-blocks      Used Available Use% Mounted on
shm                    2014764    496876   1517888  25% /dev/shm

[storm]

Das hätte ich dir aber auch vorher schon gesagt, dass der Unterschied auf 'nem modernen System marginal ausfällt. *g Imo wird das aber auf HW, wie dem PII-400 (oder noch älter), anders aussehen. Andererseits: wer hat schon so eine alte Maschine mit exorbitant viel Speicher.

ciao, storm

/edit: gut, die Schätzung des Platzbedarfs ging daneben. :)

/edit #2: @bse: nur aus Interesse, welcher Compiler?

[bse]

Sorry für die späte Antwort, Compiler war gcc-4.2.x, genaue Version kann ich gerade nicht nachschauen. Version mit Gentoo-Patches.

[gOtNoPhEaR]

Hallo zusammen...

also ich habe jetzt nen Core i7 und wunder mich die ganze Zeit, dass er so lahm kompiliert.
Kernel wird ganz normal mit make-kpkg kompiliert und CONCURRENCY_LEVEL=8 ist auch gesetzt.
Es werden mir auch 8 Prozessoren angezeigt.
Beim kompilieren erreiche ich aber eine maximal Gesamtauslastung der CPU von 14% was in etwa einem Kern entspricht, jedoch werden die Prozesse während des kompilierens wie es nach htop aussieht auf die Kerne verteilt und laufen immer mal wo anders.
Hat jemand eine Idee?

Danke schonmal ...

[Danielx]

Vielleicht können die Daten nicht schnell genug von der Festplatte gelesen bzw. auf diese geschrieben werden?
Du könntest ja mal auf einer RAM-Disk kompilieren.

Gruß,
Daniel

[tafkad]

Wie Danielx sagte, schnelle CPU reicht nicht immer, wenn die schreibzugriffe auf der Platte zu lange dauern und kompilieraktionen sind immer recht viele Schreibzugriffe. Daher einfach mal in einer Ramdisk testen.

Andere Frage, Core I7 hat doch auch nur 4 Reale Kerne und 4 virtuelle, oder? Bin nämlich immernoch der Meinung das virtuelle Kerne bei gewissen dingen die Leitung extrem reduzieren.

[gOtNoPhEaR]

Daran hab ich auch schon gedacht, aber die Festplatte dümpelt auch nur so vor sich hin und macht keinen großen Durchsatz. RAM ist schnell genug. Naja, ist ein neues System und ich glaube es ist auch noch nicht alles so 100%ig vernünftig eingerichtet. Hatte nur mal bei nem Freund gesehen, mit seinem Core2Quad ging das schon einiges mehr ab.
Aber ich werde euch darüber auf dem Laufenden halten, sobald es was neues gibt....

[gOtNoPhEaR]

So, habe jetzt mal versucht das ganze in ner RAMDISK zu kompilieren. Geht zwar ein wenig schneller, jedoch steigt die CPU-Auslastung immernoch nicht über 16%

EDIT:
Mit

Code: Alles auswählen

make -j8

geht die CPU-Auslastung bis aus 98% ... Also scheint irgendwie make-kpkg mit CONCURRENCY_LEVEL=8 Probleme zu haben ...

[Lord_Carlos]

@ gOtNoPhEaR
Zeig mal wie deine Befehle ganz genau aussehen, mit dem ganzen Export von CONCURRENCY_LEVEL und so weiter.

Andere Frage, Core I7 hat doch auch nur 4 Reale Kerne und 4 virtuelle, oder?

Also wenn man nicht gerade 2.6.32 (oder war das .33?) oder einen alternativen CPU Scheduler benutzt, empfehle ich immer mehr Processe als man Kerne hat zu verwenden. Wenn ich das richtig verstanden kommt der default CPU scheduler mit richtig vielen Kernen (ueber 32) sehr gut klar, aber Desktop nicht soo dolle.
Ich benutzt momentan BFS (Brain fucked Schduler), aber in .32 oder .33 ist auch ein anderer verbesserter default scheduler rein gekommen.

[gOtNoPhEaR]

Hat jetzt geklappt. Einfach in die /etc/kernel-pkg.conf die Zeile:

Code: Alles auswählen

CONCURRENCY_LEVEL=8

gepackt.

Anschließend kompiliert (vanilla-2.6.32.4) mit:

Code: Alles auswählen

time sudo make-kpkg --revision=1 --append-to-version=-2010-01-19-marla --initrd kernel_image kernel_headers

Ergebnis:

Code: Alles auswählen

real    3m44.348s
user    14m58.538s
sys     1m37.024s

Einziger Nachteil, der Rechner zieht beim kompilieren 120Watt mehr Saft