Abbildung 1: Den Juropa-Cluster hat das Forschungszentrum Jülich selbst entwickelt. Auf allen Knoten läuft Suse Linux. Zusammen mit dem ähnlich aufgebauten HPC-FF-Cluster belegt er Platz 10 der Top 500.

Das Jülich Supercomputing Centre hat sich mit seinem neuen Clustersystem ganz oben in den Top 500 platziert: Der zehntschnellste Rechner der Welt nutzt Suse Linux – demnächst mit Realtime-Erweiterung.

Schnelle und große Rechner benutzen die Jülicher in der ehemaligen Kernforschungsanlage, die heute Forschungszentrum Jülich heißt, schon seit Jahrzehnten, um naturwissenschaftliche Phänomene zu untersuchen, Versuchsergebnisse mathematisch zu verifizieren oder vorherzusagen: Es geht um High Performance Computing (HPC).Jetzt hat das Jülich Supercomputing Centre (JSC) es mit einem nach eigenen Plänen entworfenen Clustersystem weit nach oben in die Liste der Top 500 [1] geschafft. Der Rechnerverbund besteht aus zwei Komponenten, Juropa und HPC-FF [2], die gemeinsam über 26 000 Intel-Rechenkerne für parallele Rechnungen bieten und im Benchmark 274,8 Teraflop/s erreichten – das bringt das Verbundsystem auf Platz 10 der Weltrangliste. Dabei verwendet der Cluster Standardhardware und mit Suse Linux Enterprise Server 11 auf allen Rechenknoten auch ein Standardbetriebssystem.

Abbildung 1: Den Juropa-Cluster hat das Forschungszentrum Jülich selbst entwickelt. Auf allen Knoten läuft Suse Linux. Zusammen mit dem ähnlich aufgebauten HPC-FF-Cluster belegt er Platz 10 der Top 500.

Zukunftsmusik in Echtzeit

In einem Vortrag am Forschungszentrum Jülich ging Matthias Nagorni (Novell) auch auf künftige Pläne ein. Schon länger beschäftigt er sich mit dem Realtime-Patch »preempt_RT« [3], das die Grundlage für Suse Enterprise Linux Real Time (SLERT, [4]) bildet. Interessant für den Einsatz im Cluster sind Interrupthandler-Threads und Gang Scheduling.

Ein Interrupthandler besteht unter Linux aus zwei Teilen, einer Top Half und einer Bottom Half, die auch Tasklet heißt. Die Top Half ist über die Interrupttabelle im System verankert und läuft sofort, wenn eine Hardwarekomponente einen Interrupt auslöst. Sie bearbeitet nur die wichtigsten Aufgaben und ist ununterbrechbar. Alles Weitere erledigt das Tasklet, das erst später startet und unterbrechbar ist, damit das System etwa neu eingetroffene Interrupts sofort verarbeiten kann.

Allerdings können Tasklets sich nicht schlafen legen und dürfen darum zur Synchronisierung keine Kernelsemaphore, sondern nur Spinlocks verwenden, die in Endlosschleifen Rechenzeit beanschpruchen, während sie darauf warten, dass eine angeforderte, aber belegte Ressource wieder frei wird.

Kampf dem OS-Jitter

Der SLERT-Kernel ersetzt Tasklets durch Interrupthandler-Threads, die der Linux-Scheduler wie andere Threads und Prozesse verwaltet – darum dürfen diese auch schlafen und können auf Spinlocks verzichten. Damit vermeiden Entwickler OS-Jitter [5], der ein paralleles Programm stark ausbremst. Sie stellen sicher, dass identischer Code, der parallel auf etlichen Rechenkernen läuft, exakt zeitgleich einzelne Zwischenergebnisse liefert und anschließend beispielsweise an alle übrigen Threads schickt.

Dazu müssen alle beteiligten Threads zum selben Zeitpunkt starten – der Gang Scheduler ordnet allen Threads eines größeren Parallelprogramms zeitgleich je einen freien CPU-Kern zu. Das funktioniert sowohl mit mehreren Kernen eines Prozessors als auch über mehrere Nodes im Cluster hinweg.

Welche Arten von Rechenaufgaben von dem neuen Realtime-Kernel profitieren können, sollen Tests auf den Jülicher Clustern zeigen, die nun beginnen. Nagorni sagte im Gespräch mit dem Linux-Magazin: “Das ist jetzt wirklich Forschung, […] über die wir dann besser verstehen, welche Workloads im HPC-Bereich in Frage kommen.”