Re: 6.3: SMP + ADAPTIVE_GIANT + PREEMPTION = race condition

<de-bsd-questions(at)de.FreeBSD.org, pmc(at)citylink.dinoex.sub.org> aka Oliver Fromme schrieb
mit Datum Wed, 27 Feb 2008 19:05:41 +0100 (CET) in m2n.de.fbsd.questions:

|To: de-bsd-questions(at)de.FreeBSD.org, pmc(at)citylink.dinoex.sub.org
|Reply-To: de-bsd-questions(at)de.FreeBSD.org, pmc(at)citylink.dinoex.sub.org

Ist das Absicht? Das reply-to, mein ich.

|idlc = Interface Definition Language Compiler.
|Das Teil gehört zum CORBA-Framework.

Was immer das ist...

| > 2. Dieser Kompiler braucht ein "kill -9" um da rauszukommen. Normales
| > ^C tut nicht.
|
|Das kommt leider zuweilen bei kaputten Programmen vor.

Prinzipiell ja.

|Compilier mal folgendes Mini-Programm und starte es:
..
|Es wird ebenfalls 100% system-time verbrauchen, und Du
|kannst es nicht mit ^C abbrechen.

Im Prinzip richtig.
Nach meinem Verständnis ist ein Compiler nix anderes als ein
StreamEditor. Es gibt keinen Grund, warum da an irgendwas systemnahem
rumgespielt werden sollte - und ich sehe auch nicht, warum jemand,
der sowas halbwegs portabel zu programmieren sucht, sich das dann ohne
Not antun und sich damit nur absehbaren Ärger aufhalsen sollte.

|Im Falle von idlc tippe ich mal auf ein Thread-Synchro-
|nisations-Problem bzw. eine Race-Condition. Damit bekommt
|man dergleichen Probleme auch ziemlich leicht hin, die
|sich erst auf SMP-Systemen manifestieren.

Hm ja hm. Müsste man dann vielleicht doch mal reinschauen...

| > Unter den Gesichtspunkten bin ich zu der Überzeugung gekommen, dass
| > das kein openoffice-Problem ist, sondern ein Kernel-Problem.
|
|Ich kann jetzt nicht zu 100% ausschließen, dass es ein
|Kernel-Problem ist, aber es kann ebensogut ein Bug im
|idlc sein. Dem ganzen CORBA-Krempel traue ich eh keinen
|Millimeter weit über den Weg. :-)

Das werd ich Dir nicht absprechen. Irgendwie ist das Zeug nicht so
sexy dass man sich damit beschäftigen möchte...
Desungeachtet spiel ich halt mit Wahrscheinlichkeiten, und es scheint
mir unwahrscheinlich, dass jemand abenteuerliche systemnahe Übungen
veranstaltet, wo es logisch gesehen keinen wirklichen Bedarf dafür
geben dürfte. Andererseits hast Du natürlich auch recht - irgendeine
Schweinerei muß dieser idlc anstellen, sonst würden ja auch viele
andere Kommandos hängenbleiben die einfach nur File-IO machen.

| > Jedenfalls fand ich den Lösungsansatz <dann bau openoffice halt auf
| > einem UP kernel> unter den Umständen NICHT akzeptabel - denn ich will
| > ein stabiles System und kein "funktioniert-manchmal"-System.
|
|Verstehe ich jetzt nicht. Offenbar läuft der idlc doch
|problemlos durch, wenn Du (vorübergehend) SMP disablest.

Hilf mir auf die Sprünge. Ich hab noch keine Möglichkeit gefunden,
SMP *vorübergehend* abzuschalten. Ich hab noch nichtmal das gefunden,
was anderswo "bindprocessor" heisst: womit man einem einzelnen Prozess
das herumhüpfen austreiben kann.

Das einzige was ich (mit "man smp") gefunden hab ist machdep.hlt_cpus,
das scheint aber nur zu bewirken dass die Hälfte der Prozesse einfriert
und man nur mit viel Glück ohne Reboot wieder rauskommt: der cpu wird
angehalten, aber der Scheduler weiss davon nix.

|Und das wird ja nur einmalig zum Bauen benötigt. Insofern
|kann ich nicht nachvollziehen, wo Du da Instabilitäten
|siehst oder ein »funktioniert nur manchmal«.

Ich seh das so: wenn sie beim Bauen etwas tun, womit das System nicht
klarkommt, dann ist es nicht unwahrscheinlich, dass sie im Betrieb
etwas ähnliches tun. Und für mich geht Reliability *immer* über
Performance: Wenn ich auf ein definiertes Ergebnis ein bischen warten
muss, damit kann ich gut leben, das ist Gelegenheit zur Meditation.
Aber wenn ich zwei Stunden an einem Brief geschrieben hab und er
geht beim Abspeichern in die wüste - das haut dann direkt auf die
Magenschleimhaut.

Und abgesehen davon: das Bauen ist das einzige, wozu ich das zweite
Steinchen reingesteckt hab. Wahrscheinlich werd ichs auch wieder
rausnehmen - weil um mir das...

$ uptime
11:45PM up 6:05, 9 users, load averages: 0.00, 0.00, 0.00

  ... anzuschauen brauch ich es wirklich nicht, zum Heizen gibts
hier Erdgas, und zwei Videos gleichzeitig gucken macht auch nicht
so viel Sinn...

| > Nun hab ich erst kürzlich von 5.5 auf 6.3 migriert, und als
| > vorsichtiger Mensch ("change only one parameter") hatte ich vorher
| > noch auf 5.5 alle Ports aktualisiert
|
|Das halte ich eher für eine schlechte Idee. Man sollte
|(bzw. *MUSS*) _nach_ dem Update alle Ports neu compilieren.
|Davor ist es völlig überflüssig.

Da hast mich mißverstanden. Neu Kompilieren nach dem OS-Upgrade
ist ganz ok.
Aktualisieren meinte: den Ports-Tree vom cvs her aktualisieren.
Und das (von irgendwann 2005 bis Jan 2008 für ~500 Ports) ist eine
Drecksarbeit. Weil das bedeutet eben nicht, dass der Port sich
nur irgendwie durchkompiliert, sondern dass er dann auch ungefähr
das tut wozu er gebraucht wird! Das heisst: make-options richtig
einstellen, lokale patches überprüfen/aktualisieren, erweiterte
bzw. überschriebene config-Files sinnvoll ausfüllen, Filesystem-
Nutzung und Pfade an das lokale Layout anpassen, usw.usf.

Wenn ich das _nach_ dem OS Upgrade mache, dann hab ich keine
Möglichkeit effektiv herauszufinden ob irgendeine Weirdness
ursächlich aus dem upgradeten Port kommt oder aus dem upgradeden
OS: es wird viel aufwendiger, die Sachen einzugrenzen.

Den ganzen Wust dann nach dem OS Upgrade nochmal durchkompilieren
ist dagegen geschenkt. Das geht automatisch - und genau das ist der
Schritt, bei dem das zweite Steinchen Laune macht!

|Die beiden Schalter haben u.a. einen Einfluss darauf, wie
|einzelne Prozesse und Threads geschedulet werden. Wenn
|Du sie ausschaltest, machst Du Dein SMP-System langsamer.

Subjektiv ist das im Desktop-Betrieb für mich nicht merkbar.
Was ich dagegen merke, ist dass ein SMP System irgendwie "hakeliger"
reagiert als ein UP. Das scheint bei 6.3 schon viel besser als bei
5.5, wird aber mit diesen beiden Optionen auch nicht besser.
(Der 5.5 ist gelegentlich ganz stehengeblieben, und nach ein paar
Stunden dann fehlerfrei weitergelaufen und hat mich treuherzig
angeguckt als wenn nix gewesen wär. Auf dem 6.3 hab ich bis jetzt
nur nen versauten CD-rohling, und das kann an vielem liegen.)

Für ein Server-System mit relativ homogener Vollauslastung mag sich
das natürlich ganz anders verhalten.

besten Gruß
Peter

To Unsubscribe: send mail to majordomo(at)de.FreeBSD.org
with "unsubscribe de-bsd-questions" in the body of the message
Received on Thu 28 Feb 2008 - 01:13:41 CET