Re: Hyperthreading und SMP-Kernel

From: Bernd Walter <ticso(at)cicely12.cicely.de>
Date: Sat, 27 Mar 2004 09:08:07 +0100

On Sat, Mar 27, 2004 at 12:47:00AM +0100, Bjoern Engels wrote:
> On Fri, Mar 26, 2004 at 11:16:57PM +0100, Patrick Hess wrote:
> > Bjoern Engels schrieb:
> > > ich bin seit einiger Zeit stolzer Besitzer einer Maschine mit
> > > hyperthreading-faehigem Prozessor. HT ist aktiviert, den Kernel
> > > habe ich mit
> > >
> > > options SCHED_ULE
> >
> > Kenne ich nicht. Welches Betriebssystem benutzt du denn eigentlich?
>
> *g* Sorry, ich vergesse _immer_, das zu erwaehnen ;)
>
> FreeBSD 5.2.1-RELEASE-p1 #0: Tue Mar 9 10:16:20 CET 2004

War irgendwie klar - weil so lange gibt es SCHED_ULE ja auch noch
nicht.

> > > Und kann ich nun irgendwie ueberpruefen, ob sich die Prozesse
> > > wirklich an die beiden virtuellen CPUs binden? Ist das z.B. die
> > > Zeile in top, die mit "C" betitelt ist?
> >
> > Ja, zum anderen kann man außerdem bei laufenden Prozessen in der
> > Spalte STATE erkennen, auf welcher CPU der Prozess gerade
> > ausgeführt wird.
>
> Hm, da habe ich nur RUN/select/nanslp/lockf usw. stehen, nichts zur
> CPU. Aber die C-Spalte reicht ja auch.

RUN bedeutet, dass ein Prozess einführbar ist aber keine CPU hat.
select, usw... bedeuten dass die Prozesse auf ein Ereigniss warten.
Was der Patrick meinte ist CPU0, CPU1 was bedeutet der Prozess wird
gerade von der besagten CPU ausgeführt.
Zumindest dein top wird gerade eine CPU haben, ansonsten hätte er
nichts anzeigen können.

> > Wenn das bei dir alles schön auf CPU0 und CPU1 verteilt wird,
> > würde ich mir keine weiteren Gedanken machen. Naja, und so der
> > Performancesprung ist HTT nun auch wieder nicht...
>
> In der Regel nicht, das stimmt. Wir haben auf der Arbeit mal Benchmarks
> gemacht - Im Schnitt gab's einen lapidaren Geschwindigkeitszuwachs,
> bei einigen wenigen Anwendungen aber bis zu rund 30%, andere wurden
> marginal langsamer.
> Ausserdem kann das HT auch noch ganz andere ungewollte Auswirkungen
> haben: Sybase-Datenbanken z.B. krallen sich pro Prozessor eine gewisse
> Menge RAM, und wenn die Datenbank meint, sie habe ploetzlich die
> doppelte Anzahl Prozessoren, kann das schon zum Swappen auf der Karre
> fuehren ;)
> Mit Java haben wir da auch ueble Erfahrungen gemacht, uns sind z.B.
> Tomcats, auf deren Servern HT aktiv war, regelmaessig gestorben.
>
> Da das Ganze aber auf meine Maschine nicht zutrifft, vermute ich eher
> mal, dass sich das HT positiv auswirkt, ich werde in dieser Richtung
> noch ein bisschen Testen.

Nun du musst im wesentlichen den SMP Overhead wieder wettmachen.
Bei 2 physikalischen CPUs sieht es schon anders aus, weil man ja eh
schon SMP drin hat - dann kommt es darauf an, dass die Prozesse
möglichst so verteilt werden, dass nicht alzu oft eine CPU idle läuft
und die andere mit beiden virtuellen CPUs arbeitet.
Bei einigen Anwendungen ist es unmöglich den SMP Overhead wieder gut
zu machen, aber SCHED_ULE tut schon einiges mehr dafür, um es in
möglichst vielen Situtaionen zu schaffen, als der alte Scheduler.

-- 
B.Walter                   BWCT                http://www.bwct.de
ticso(at)bwct.de                                  info(at)bwct.de
To Unsubscribe: send mail to majordomo(at)de.FreeBSD.org
with "unsubscribe de-bsd-questions" in the body of the message
Received on Sat 27 Mar 2004 - 09:10:52 CET

search this site