Kleiner Vorschlag zur build-Beschleunigung

Kreuzuebersetzer, Diskussion über Änderungen im Tuxbox-CDK und Tuxbox-CVS
rhabarber1848
CDK-Experte
Beiträge: 4335
Registriert: Donnerstag 3. April 2008, 13:05

Kleiner Vorschlag zur build-Beschleunigung

Beitrag von rhabarber1848 »

Nach dem Kompilieren eines Paketes wird das Löschen des Paket-Verzeichnisses im Hintergrund erledigt:

Code: Alles auswählen

--- cdk/acinclude.m4	2011-06-19 13:46:27.000000000 +0200
+++ cdk/acinclude.m4	2011-10-02 23:01:16.000000000 +0200
@@ -2,7 +2,7 @@
 AC_MSG_CHECKING([$1 rules])
 eval `${srcdir}/rules.pl make ${srcdir}/rules-make $1 cdkoutput`
 INSTALL_$1=`${srcdir}/rules.pl install ${srcdir}/rules-install $1`
-CLEANUP_$1="rm -rf $DIR_$1"
+CLEANUP_$1="rm -rf $DIR_$1 &"
 CLEANUP="$CLEANUP $DIR_$1"
 DEPSCLEANUP="$DEPSCLEANUP .deps/$1"
 AC_SUBST(DEPENDS_$1)dnl
@@ -21,7 +21,7 @@
 CONFIGURE_$1="../$DIR_$1/configure"
 PREPARE_$1="$PREPARE_$1 && ( rm -rf build_$1 || /bin/true ) && mkdir build_$1"
 INSTALL_$1=`${srcdir}/rules.pl install ${srcdir}/rules-install $1`
-CLEANUP_$1="rm -rf $DIR_$1 build_$1"
+CLEANUP_$1="rm -rf $DIR_$1 build_$1 &"
 CLEANUP="$CLEANUP $DIR_$1"
 DIR_$1="build_$1"
 AC_SUBST(CLEANUP_$1)dnl
amiga23
Einsteiger
Einsteiger
Beiträge: 238
Registriert: Sonntag 14. November 2004, 23:44

Re: Kleiner Vorschlag zur build-Beschleunigung

Beitrag von amiga23 »

Funktioniert für mich. Habe 3 Images erfolgreich gebaut. Aber ich habe den Zeitunterschied nicht gemessen.
rhabarber1848
CDK-Experte
Beiträge: 4335
Registriert: Donnerstag 3. April 2008, 13:05

Re: Kleiner Vorschlag zur build-Beschleunigung

Beitrag von rhabarber1848 »

amiga23 hat geschrieben:Aber ich habe den Zeitunterschied nicht gemessen.
Ich habe es mittlerweile geschafft, Zeitmessungen durchzuführen, bei yadd-neutrino kein Unterschied meßbar :(
Daher werde ich das Thema nicht mehr weiterverfolgen.
seife
Developer
Beiträge: 4189
Registriert: Sonntag 2. November 2003, 12:36

Re: Kleiner Vorschlag zur build-Beschleunigung

Beitrag von seife »

Und die potenziellen Probleme (falls mal 2 Pakete hintereinander gebaut werden sollten, die dieselben Verzeichnisnamen im Tarball haben, kann es unschöne und schwer zu debuggende Effekte geben).

Des weiteren macht deine Storage einfach nicht mehr IOPS, egal ob du nun im Hintergrund löschst oder im Vordergrund ;-)
Oder anders ausgedrückt: das Auspacken des nächsten Tarballs geht zwar evtl. früher los, aber dauert halt entsprechend länger, wenn gleichzeitig noch gelöscht wird... genau das, was deine Zeitmessungen auch zeigen.

Die Lösung ist: einfach im tmpfs bauen. Benötigt halt "ein wenig" mehr RAM ;)
rhabarber1848
CDK-Experte
Beiträge: 4335
Registriert: Donnerstag 3. April 2008, 13:05

Re: Kleiner Vorschlag zur build-Beschleunigung

Beitrag von rhabarber1848 »

seife hat geschrieben:Und die potenziellen Probleme (falls mal 2 Pakete hintereinander gebaut werden sollten, die dieselben Verzeichnisnamen im Tarball haben, kann es unschöne und schwer zu debuggende Effekte geben).
Das Entpacken eines Paketes wird immer mit
( rm -rf linux-2.4.37.11 || /bin/true ) && ( rm -rf linux || /bin/true ) && bunzip2 -cd [...]
eingeleitet, es sollte also keine Probleme geben.
Barf
Developer
Beiträge: 1475
Registriert: Dienstag 4. Februar 2003, 22:02

Re: Kleiner Vorschlag zur build-Beschleunigung

Beitrag von Barf »

Das "Launchen" von Prozessen innerhalb make wird besser von make (und seine -j option) gehandhabt. "Hinter dem Rücken" von make zu gehen wird irgendwann beissen. Besser wäre, möglichst viele Maketargets parallelisierbar (in Sinn von make -j) zu machen.
seife hat geschrieben:Und die potenziellen Probleme (falls mal 2 Pakete hintereinander gebaut werden sollten, die dieselben Verzeichnisnamen im Tarball haben, kann es unschöne und schwer zu debuggende Effekte geben).
Schliesse mich an. Nach zwei Jahren kommt jemanden auf die (eventuell bescheuerte) Idee, zwei Packages in "utilities" zu entpacken...
seife hat geschrieben:Die Lösung ist: einfach im tmpfs bauen. Benötigt halt "ein wenig" mehr RAM ;)
Oder ein journalling file system; ist wahnsinnig schell beim Löschen von Verzeichnissbäumen.
seife
Developer
Beiträge: 4189
Registriert: Sonntag 2. November 2003, 12:36

Re: Kleiner Vorschlag zur build-Beschleunigung

Beitrag von seife »

OT: ein journaling filesystem muss nicht schnell beim Löschen sein. Im Gegenteil, es muss noch mehr tun um sicherzustellen dass wirklich gelöscht ist als ein FS ohne Journal.

Beispiel: XFS. Extrem langsam. Und ext3 ist auch nicht wirklich schnell beim Löschen.
Barf
Developer
Beiträge: 1475
Registriert: Dienstag 4. Februar 2003, 22:02

Re: Kleiner Vorschlag zur build-Beschleunigung

Beitrag von Barf »

ich hat geschrieben:Das "Launchen" von Prozessen innerhalb make wird besser von make (und seine -j option) gehandhabt. "Hinter dem Rücken" von make zu gehen wird irgendwann beissen. Besser wäre, möglichst viele Maketargets parallelisierbar (in Sinn von make -j) zu machen.
Habe ein Bisschen nachgedacht. Das Starten von Hintergrundprozessen in Make ist wirklich nicht eine gute Idee. Seifes Argument ist gültig, aber zweitrangig. Wichtiger ist, dass Make ist der "Arbeitsleiter", der wann ein Aufgabe (Task/Target) gestartet wird steuert, und der Bescheid bekommt wann etwas fertig ist. Hintergrundprozessen ist in diesem Sinn das Make anzulügen, und fehler zu provozieren. Was passiert wenn ein Hintergrundprozess fehlschlägt, oder sich aufhängt?

Natürlich kann man behaupten, dass dies nicht in hinreichen einfachen Fällen Gültigheit hat.... ...

(Um Missverständnisse zu vermeiden: Sinn und Zweck mit diese Zeilen ist nicht rhabarber zu kritisieren, sondern meine Gedanken aufzuschreiben. Eines Tages schreibe ich vielleicht ein Buch über Make....)
seife hat geschrieben:OT: ein journaling filesystem muss nicht schnell beim Löschen sein. Im Gegenteil, es muss noch mehr tun um sicherzustellen dass wirklich gelöscht ist als ein FS ohne Journal.
In Mitte der 90-er Jahren habe ich Solaris 2.4 mit dem Solaris Disksuite installiert, und ich erinnere mich das dadrin enthaltene journalling filesystem es als (subjektiv) superschell beim Löschen. (Keine Messungen.) Dass die genannten Filesysteme schlecht/langsam sind ist durchaus möglich.
seife
Developer
Beiträge: 4189
Registriert: Sonntag 2. November 2003, 12:36

Re: Kleiner Vorschlag zur build-Beschleunigung

Beitrag von seife »

Ganz OT:
Das hat mit schlecht nichts zu tun. reiserfs3 ist auch extrem schnell was das Löschen vieler Datenmengen angeht.

Dafür braucht man kein undelete: ein "reiserfsck --rebuild-tree" (IIRC) erweckt sachen zum Leben, die schon längst nicht mehr da sein sollten.

Es ist eine correctness-issue: Jedes Filesystem muss irgendwann sein "housekeeping" machen. XFS macht das, IIRC, beim Löschen der Dateien. => verringerung der Fragmentierung etc.
Ext3 nullt beim Löschen von dateien bestimmte Datenblöcke, damit sichergestellt ist, dass die bei einem journal replay nicht wieder als ungelöscht erscheinen. => beim löschen grosser / vieler Dateien müssen blöcke verteilt über die Platte geschrieben werden.

Reiser3 hat das alles nicht gemacht mit der Konsequenz, dass nach einem Crash das Dateisystem zwar *konsistent* war, aber der Inhalt unter umständen nicht das, was der User erwartet hätte.

Das sind alles keine schlechten Dateisysteme, sie haben nur unterschiedliche Designziele / Prioritäten. Insbesondere XFS würde ich - trotz dem relativ langsamen Löschvorgang - immer noch bevorzugt meine Daten anvertrauen, auch weil ich die Entwickler kenne und weiss was sie für eine Einstellung haben.

Disclaimer: Ich bin kein FS-Experte, das oben ist eine vereinfachte Darstellung von meinem Verständnis der Sachverhalte :-)