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

Peter Much wrote:
> in freebsd-openoffice haben sich ein paar Leute beklagt, dass der
> Build von openoffice hängenbleibt und in eine Endlosschleife geht.
> Man hat vermutet dass es am SMP liegt und beschlossen, openoffice
> auf einem UP Kernel zu bauen. Danach war nichts mehr davon zu lesen,
> also scheint der UP Ansatz geholfen zu haben. :-/

Immerhin ein funktionierender Work-around.

> Mir ist es dann auch passiert. Und ich fands komisch. Denn:
> 1. was da hängenbleibt ist ein "idlc" - das scheint irgendein
> komischer Compiler zu sein der irgendwelches Zeug im Zus.hang
> von JAVA/CORBA/whatsoever bearbeitet.

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

> 2. Dieser Kompiler braucht ein "kill -9" um da rauszukommen. Normales
> ^C tut nicht.

Das kommt leider zuweilen bei kaputten Programmen vor.

> 3. Die loadavg ist nicht grün sondern rot! Das teil frisst 100%
> *system* time!

Das kommt leider zuweilen bei kaputten Programmen vor.
Compilier mal folgendes Mini-Programm und starte es:

    #include <signal.h>
    #include <sys/time.h>
    main(void)
    {
            struct timeval stv;
            signal(SIGINT, SIG_IGN);
            for (;;)
                    gettimeofday(&stv, NULL);
    }

Es wird ebenfalls 100% system-time verbrauchen, und Du
kannst es nicht mit ^C abbrechen.

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.

> 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. :-)

> 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.
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«.

> 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.

> Also hab ich mal die beiden neuen Schalter (ADAPTIVE_GIANT und
> PREEMPTIVE) rausgeschmissen. Und siehe - schon gehts!

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.
Für den idlc genügt es offenbar, dass sein Bug nicht mehr
zum Tragen kommt.

> Nur - welcher von beiden ist jetzt der schuldige?
> Nach dem, was darüber zu lesen ist, hängt das alles irgendwie
> zusammen - es könnte ebensogut erst ein Zusammenwirken von Umständen
> sein. Was wäre dann die bessere Option, die man nutzen sollte:
> PREEMPTIVE oder ADAPTIVE_GIANT?

Du solltest beide nutzen, denn beide sorgen für bessere
Performance. Einen der beiden (oder gar beide) abzuschal-
ten, ist ein schlechterer Work-around als der, vorüber-
gehend SMP auszuschalten (was dank sysctl auch ohne Reboot
geht).

> Jedenfalls - langer Rede kurzer Sinn: der momentan mit 6.3
> veröffentlichte Standardkernel SMP-GENERIC ist *nicht*
> production-grade tauglich.

Das würde ich so nicht unterschreiben.

Gruß
   Olli

-- 
Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M.
Handelsregister: Registergericht Muenchen, HRA 74606,  Geschäftsfuehrung:
secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün-
chen, HRB 125758,  Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart
FreeBSD-Dienstleistungen, -Produkte und mehr:  http://www.secnetix.de/bsd
With Perl you can manipulate text, interact with programs, talk over
networks, drive Web pages, perform arbitrary precision arithmetic,
and write programs that look like Snoopy swearing.
To Unsubscribe: send mail to majordomo(at)de.FreeBSD.org
with "unsubscribe de-bsd-questions" in the body of the message