Thomas Hofer wrote:
On Monday 30 December 2002 15:01, Thomas Hertweck wrote: [...]
IMHO macht die Option -j zumindest bei "make dep" und "make modules_install" wenig Sinn - die Hauptzeit geht fuer das Compilieren drauf, d.h. dort kannst Du die Option getrost weglassen.
Das ist klar; ich hab sie nur "pro forma" hingeschrieben, weil ich dachte, die Option wäre unproblematisch.
Hmm, unproblematisch ist diese Option wohl eher nicht. Falls Du Dich mal mit Programmierung fuer Parallelrechner auseinander setzt, dann wirst Du das merken - "race conditions" sind da eine tueckische Angelegenheit! Kleines Beispiel: Du hast ein Shared-Memory-System und moechtest immer etwas zur Variablen a dazu addieren. Das ganze verteilst Du auf mehrere Prozessoren, die Variable a wird aber von allen geteilt. Nun ist a=1 und das parallel laufende Programm moechte nun gleich- zeitig vom Thread auf Proz1 eine 2 und vom Thread auf Proz2 eine 3 zur Variablen a hinzuaddieren. Was ist das Ergebnis? Wenn beide es wirklich gleichzeitig versuchen, dann sieht Proz1 a=1+2 und Proz2 sieht a=1+3, und letztendlich ist es Zufall, was nachher in der Variablen a steht, naemlich 3 oder 4. Aber beides ist falsch, denn es muesste a=1+2+3=6 drin stehen. Deswegen muss man dafuer sorgen, dass z.B. immer nur ein Zahl zu einem Zeitpunkt zu a hinzu addiert werden kann - bei OpenMP kann man das mit sog. Pragmas (Preproces- sor-Anweisungen) realisieren, in diesem Falle braeuchte man ein sog. "atomic". Das nur mal als ganz einfaches Beispiel. Bei Make- files duerfte es sich aehnlich verhalten - es muesste ja sicherge- stellt werden, dass das Target zur Erstellung aller Object-Files beendet ist, bevor das Target zum Linken aufgerufen wird. Sonst kommt es zu Fehlern. Solange ich nur compiliere und Object-Files erzeuge (gcc -c) kann ich das im Prinzip locker parallel laufen lassen. Beim Kernel werden aber eben auch "unterwegs" Dateien an- gelegt, wieder gelesen, etc. - das macht es anfaellig fuer "race conditions".
By the way, nach "make dep" folgt normalerweise ein "make clean" - laesst Du das absichtlich weg?
Ist Absicht - ich liebe Schwierigkeiten :) Bis jetzt hat es bei mir immer ohne make clean funktioniert. Ich habe aber das Gefühl, daß sich die massiven compile-Probleme, die ich gerade mit dem neuen 2.4.20er hatte, auf das Fehlen des make clean zurückführen lassen. Ich bin nun auf folgende Formel umgestiegen:
make dep clean && make -j4 bzImage modules && make modules_install
Das sieht besser aus. Ich wuerde das "make clean" nicht weglassen Da- bei werden die alten Object-Files geloescht, es wird der alte compi- lierte Kernel + System.map aus dem Kernelquellbaum geloescht, es wird compile.h (enthaelt Infos ueber Compiler und Uhrzeit der Kernelerstel- kung) geloescht, usw. Das sorgt dann auf alle Faelle dafuer, dass alle Object-Files neu erstellt werden _muessen_. Ausserdem ist das heutzu- tage bei schnellen Rechnern kein groesseres Problem mehr, hier compi- liert ein Kernel mit allem Schnickschnack in ein paar Minuten durch :) Gruesse, Thomson -- Thomas Hertweck, Dipl.-Geophys. Geophysikalisches Institut, Universitaet Karlsruhe (TH)