Linux-SMP-Performance

Wichtiger Hinweis

Ich habe dieses Board nicht mehr und auch keine Doku. Ich kann daher keine Fragen nach Jumperbelegungen etc. beantworten.

Vorgeschichte

Als ich im Frühjahr einen neuen Computer kaufte, wurde ich von den geringen Motherboard- und Pentium-75-Preisen verleitet, ein Dual-Prozessor-Board von A.I.R. (54 CDP mit 512kB shared L2-Cache, on-board 7870-SCSI und diversen Schnittstellen) zu kaufen. Es stellte sich zwar dann heraus, daß die 75er nicht MP-tauglich sind und ich zwei 90er nehmen mußte (das konnte ich eigentlich nicht nachvollziehen -- auf www.intel.com findet sich kein Hinweis darauf, daß die 75er anders sind als die 90er - aber dort steht auch nichts davon, daß es von den älteren Pentiums (A- und B-stepping) zwei Versionen gab, wovon nur eine als Zweitprozessor geeignet war). SMP-Support gab es damals noch in keinem freien Betriebssystem und eigentlich hatte ich vor, auf dem Gebiet selber was zu machen. Doch die Faulheit obsiegte und Alan Cox legte mit Version 1.3.31 einen SMP-fähigen Linux-Kernel vor, bevor ich auch nur eine Zeile Code getippt habe (immerhin habe ich mir Intels MP-Spezifikation durchgelesen ).

1.3.35 war dann der erste Kernel, den ich zu installieren versuchte. Das Ergebnis war leicht desaströs. Daß der Kernel auf einem Single-Prozessor-Board mit "Only one processor found" panikte beunruhigte mich nicht so besonders, führte aber am nächsten Tag am WSR zu erheblicher Aufregung, weil ich mir frei genommen hatte und jemand meinen PC rebooten wollte. Daß er sich auf meinem Dual-Prozessor-Board unmittelbar nach Aktivieren des zweiten Prozessors verabschiedete war schon eher beunruhigend. Vor allem hatten mich die Gerüchte über spezielle Pentium-Versionen für MP verunsichert. Hatten mir die Leute beim Birg womöglich die falschen CPUs angedreht? Die linux-smp-Mailing-List beruhigte mich aber schnell. Manche Treiber vertragen während der Initialisierung höchstens einen Prozessor. Also holte ich mir die nächsten zwei Patches, und 1.3.37 funktionierte tatsächlich ohne alle Probleme. Schön, jetzt habe ich also zwei Pentiums, und Linux meldet beim Booten stolz 71.88 total BogoMips aber ist die Kraxen jetzt auch wirklich schneller? Schließlich ist das eine der ersten Versionen, große Teile des Kernels sind noch nicht parallelisierbar, der SMP-Support bringt sicher einiges an Overhead und wie oft laufen auf einem Privat-PC schon mehrere CPU-hungrige Prozesse gleichzeitig? Im täglichen Gebrauch ist ohne Stoppuhr absolut kein Unterschied zu bemerken, also packte ich meine angejahrte Benchmark-Suite wieder aus.

Es handelt sich dabei um einige sehr einfache Programme, die natürlich einem Vergleich mit der SPEC-Suite nicht standhalten können. Alle bis auf einen habe ich kurz nach dem Kauf meines 386ers 1990 geschrieben und sie entsprechen den damals in deutschsprachigen Zeitschriften üblichen Tests (Sieb des Eratosthenes, Mandelbrotmenge, Bildschirm-Ausgabe, File-IO). Seitdem habe ist das Programm auf so ziemlich jedem Computer1 gelaufen, der mir unter die Finger kam (vom original IBM PC bis zur HP 9000/I70). Die Ergebnisse sind aber nur bedingt vergleichbar, da es im Lauf der Zeit immer wieder kleine Änderungen gegeben hat.

Für die hier beschriebenen Tests habe ich nur die beiden CPU-intensiven Tests verwendet (die File-I/O ist interessanterweise auch deutlich schneller geworden. Ich nehme aber an, daß das auf Änderungen am ext2fs-Code zwischen 1.2.5 und 1.3.37 zurückzuführen ist und nicht auf SMP). Als echte Anwendungen habe ich das Anzeigen eines MPEG-Files und eine Kompilation einer relativ großen Library gewählt.

Die Tests

Schluß mit dem Geschwafel, jetzt kommen Fakten und Zahlen (und noch mehr Geschwafel in Form meiner Kommentare).

Memory-intensives Programm (Sieb des Eratosthenes mit 1MB-Array)

Interessant ist hier, daß ein einzelnes Programm deutlich (25%) langsamer läuft als mit dem Uniprozessorkernel. Alan Cox hat mal erwähnt, daß ein Prozessor im Idle-Task sinnlose Memory-Zyklen erzeugt (und deshalb völlig stillgelegt werden sollte, was aber derzeit noch nicht passiert) und das könnte für diesen Effekt verantwortlich sein. Ich verstehe allerdings nicht ganz wieso, da man annehmen sollte, daß der untätige Prozessor immer nur die gleichen paar Bytes aus dem eigenen Cache liest.

Wie zu erwarten war, ist kaum Parallelität zwischen zwei memory-intensiven Prozessen zu beobachten. Beide Prozessoren verbringen wohl den grössten Teil der Zeit damit, auf das Main-Memory zu warten. Da das working set jedes Prozesses größer ist als der L2 Cache, würde wohl auch ein geteilter L2-Cache wenig bringen.

CPU-Intensives Programm (Mandelbrotmenge)

Dieses Programm berechnet Punkte einer Mandelbrotmenge, speichert das Ergebnis aber nirgends ab. Es besteht also nur aus drei engen Schleifen, in den FP-Operationen ausgeführt werden. Das working set hat locker im internen Cache des Prozessors Platz und die Prozesse laufen perfekt parallel.

mpeg_play

mpeg_play mit einem relativ hochauflösenden (ca. 400x300 Pixel) mpeg-Video. Ich hatte hier erwartet, daß mpeg_play und X-Server teilweise parallel laufen können. Das scheint nicht der Fall zu sein, unter SMP-Linux ist die Performance geringer. Auffallend ist, daß die Performance deutlicher absinkt, wenn man das Video in doppelter Größe darstellt. Bei zwei Prozessoren scheint das Memory-System generell eher zum thrashen zu neigen.

make diamond

make im Source-Directory einer X-Widget-Library (diamond/X11, kennt vermutlich keiner außerhalb des TU-Instituts 182/1). 197 C-Files zwischen 84 und 24391 Bytes (Durchschnitt knapp über 2k).

Ein normales make ist deutlich langsamer als am Uniprozessor-Linux, mit steigender Anzahl gleichzeitig laufender Prozesse nimmt die Performance aber deutlicher zu und bei make -j2 ist das Dual-Prozessorsystem ca. 30% schneller als das Singleprozessorsystem. Bei -j3 wird es aber wieder langsamer, während das Singleprozessorsystem noch ein kleines bißchen zulegt.

Schlußfolgerung

Derzeit ist der SMP-Kernel im Durchschnitt wahrscheinlich eher etwas langsamer als der herkömmliche Kernel.

1995-11-05

Benchmarks durchgeführt und eine erste Version dieses Berichts an luga@wsr.ac.at geschickt.

1995-11-09

Erste HTML-Version. Leider ging diese Version verloren (die Fileversionen in VMS waren doch praktisch)

1995-11-25

Zweite HTML-Version.

2000-09-07

Link auf A.I.R. geändert.

2000-12-04

"Keine Fragen"-Hinweis eingefügt.

Diese HTML-Page ist in HTML-3 geschrieben (naja, fast). Die meisten verwendeten Features sind reine Kosmetik, die Tabellen haben aber einen gewissen Informationsgehalt. Zum Betrachten ist daher ein Browser, der zumindest Tabellen versteht (Netscape, Mosaic >= 2.6, Arena, ...) sehr zu empfehlen.