15. März 2016 MYTHOS VIELKERN-BETRIEBSSYSTEME FÜR HPC Stefan Wesner, Lutz Schubert, Vladimir Nikolov, Jörg Nolte, Randolf Rotta, Mai Krüger, Robert Kuban, uvm...
MANY THREADS OPERATING SYSTEM Ziel dynamische HPC Anwendungen auf Vielkern-Prozessoren Fokus schnelle Thread-Verwaltung Durchsatz statt Echtzeit, Overheads reduzieren BMBF Projekt 1 von Uni Ulm, mit Uni Siegen, BTU Cottbus, Alcatel-Lucent Deutschland AG, HLRS Stuttgart 1 Fördernummer BMBF 01IH13003 2
AGENDA 1. Wozu Vielkern-Betriebssysteme? Herausforderungen - Vielkern-Prozessoren Anforderungen - Zwei Szenarien Konzequenzen - Entwurfsziele 2. Zwischenergebnisse Die Kunst der Weglassens Wartefreie Aufgabenverwaltung Pragmatische Kompromisse 3. Zusammenfassung 3
OUTLINE 1. Wozu Vielkern-Betriebssysteme? Herausforderungen - Vielkern-Prozessoren Anforderungen - Zwei Szenarien Konzequenzen - Entwurfsziele 2. Zwischenergebnisse Die Kunst der Weglassens Wartefreie Aufgabenverwaltung Pragmatische Kompromisse 3. Zusammenfassung 1 Wozu Vielkern-Betriebssysteme? 4
MULTI- VERSUS MANY-CORE double prec. FPUs 1152 960 480 256 216 80 32 16 Haswell TileGx72 Cyclops64 Sparc T5 Intel KNL Intel KNC 16 72 128160 240288 768960 max. concurrent control flows Kepler GK110 Fermi GF104 max. paralleler Durchsatz in geg. Power- & Platz-Budget Energie- & Platzeffizienz statt Single-Thread Performance Durchsatz nur durch Aufgaben- und Daten-Parallelität 1 Wozu Vielkern-Betriebssysteme? 5
MYTHOS ZIELARCHITEKTUR Intel Xeon Phi Knights Corner XeonPhi XeonPhi XeonPhi Card Processor Processor Processor Memory Memory DMA DMA Memory DMA PCIe Host Processor Memory HDD, Network... 60 Kerne mit je 512bit VPU, 4 HW Threads, 1.05GHz In-Order, keine Sprungvorhersage, 2 Takte Instruction Decoder 8GB kohärenter gemeinsamer Speicher, Streuung über Verzeichnisse 150ns 1000+ns Latenz, Flaschenhals für Synchronisation PCIe2.0 Karten: eigene BS Kernel einfach startbar, Kommunikation mit Host über nicht-kohärenten gem. Speicher Ideale Worst-Case Plattform!? 1 Wozu Vielkern-Betriebssysteme? 6
SZENARIO I: HPC SIMULATIONEN Moleküldynamik (HLRS), Strömungen und Elektrodynamik (Uni Siegen) eine Anwendung besitzt alle Kerne und Speicher Aufgabenverwaltung und Kommunikation auf Anwendungsebene dynamische Speicherverwaltung Anforderungen effizientes Warten statt Polling (min Energie, min Contention) Semaphore/Futex wait, signal viele Threads manipulieren gemeinsamen Adressraum (IO,PGAS,DSM) mmap, mremap, mprotect 1 Wozu Vielkern-Betriebssysteme? 7
SZENARIO II: COMPUTE CLOUD Verteilte Medienverarbeitung (Alcatel/CenoLabs) dynamisch konfigurierter Datenfluss-Graph Knoten aktiviert durch Input Daten, laufen in Isolation+Zeitschranke Cloud Manager bewegt Daten, migriert Knoten für min. Energie Anforderungen viele Threads mit eigenem Adressraum erzeugen und aktivieren create, destroy, activate mit Zeitschranke Manager manipuliert fremde Adressräume, z.b. zero-copy comm mmap, mremap, mprotect auf Kind-Threads Weiterleiten der Systemaufrufe, Exceptions etc. an Manager event queue 1 Wozu Vielkern-Betriebssysteme? 8
MYTHOS DESIGN-ZIELE 1. Overheads reduzieren durch Weglassen: Policies vereinfachen und auslagern z.b. kein Demand-Paging, kein Swapping, nur FIFO Scheduling 2. BS-Aufgaben parallelisieren: Aufräumaufgaben über freie Kerne verteilen z.b. Rahmen freigeben und nullen 3. Wartezeiten sinnvoll füllen: Asynchrone BS-Aufgaben und Kommunikation z.b. Active Messages, Delegation Queues, Continuation Passing 4. Kommunikationskosten reduzieren: kleine Aufgaben verschicken statt viele Daten bewegen lokal gemeinsame Caches ausnutzen 1 Wozu Vielkern-Betriebssysteme? 9
OUTLINE 1. Wozu Vielkern-Betriebssysteme? Herausforderungen - Vielkern-Prozessoren Anforderungen - Zwei Szenarien Konzequenzen - Entwurfsziele 2. Zwischenergebnisse Die Kunst der Weglassens Wartefreie Aufgabenverwaltung Pragmatische Kompromisse 3. Zusammenfassung 2 Zwischenergebnisse 10
MEHRSCHICHTIGE ARCHITEKTUR Lokale und Verteilte Dienste separieren, Steuerung von Außen 2 Zwischenergebnisse 11
DIE KUNST DER WEGLASSENS mcconf: Kernel maßschneidern für Platform und Anwendung Komponenten Vielfalt durch Laufzeit-Komposition einfaches Replizieren & Platzieren auf Kerne Module Effizienz durch Compile-Time-Komposition Abhängigkeitsverwaltung mit #include, Varianten filtern anhand Prozessor, Umgebung... 2 Zwischenergebnisse 12
FORK-JOIN BENCHMARK Einen Thread erzeugen und aktivieren; Freigeben kostet noch... 500 mythos mythos nodel linux 400 300 usec 200 100 0 0 50 100 150 200 250 2 Zwischenergebnisse hardware thread 13
WARTEFREIE AUFGABENVERWALTUNG Asynchrones Ausführungsmodell mit lokaler Balanzierung Ereignisse, Aktive Nachrichten, Kritische Abschnitte, Interrupt-Epiloge, Continuations... Tasklets basierend auf C++11 Lambdas pro HW-Thread: Kernel-, User-, Idle-Warteschlangen Thread-Gruppen mit Work Sharing/Stealing, Delegation Locks regeln lokale Nebenläufigkeit threads[40]->send( [](){ mlog::kernel.info("hello"); } ); Mutex* m; m->protect( [=](){ process_event(args...);... } ); 2 Zwischenergebnisse 14
BROADCAST BENCHMARK Latenz und Durchsatz auf dem XeonPhi median latency [µs] 30 20 10 0 arity=1 arity=2 arity=3 50 100 150 200 50 100 150 200 50 100 150 200 number of hardware threads BT DR SDR median events per µs 0.5 0.4 0.3 0.2 0.1 0.0 arity=1 arity=2 arity=3 0 25 50 75 100 1250 25 50 75 100 1250 25 50 75 100 125 number of pipelined broadcasts BT DR SDR 2 Zwischenergebnisse 15
SYNCHRONISATIONSLATENZ Geschickte Platzierung der Synchronisationsvariablen type add0 optimal read optimal read worst 1500 Cacheline Ping Pong [ns] 1000 500 0 0 10 20 30 2 Zwischenergebnisse Distance [cores on the ring] 16
PRAGMATISCHE KOMPROMISSE... keine echten Prioritäten, keine Flusskontrolle zentrale Dienste beginnen neue Aufgaben statt alte abzuschließen doch viele Dienste und Policies im Kernel implementiert duplizierte Infrastruktur kernel- vs. user mode 8GiB/240 = 34MiB pro HW-Thread kein reiner Multikernel, gemeinsamer Speicherpool aktives Work-Stealing stört andere Threads Einsichten statische Resourcenplanung wie in Echtzeitsystemen Microkernel mit optionalen kernel-mode Tasks wartefreie Datenstrukturen für Speicherpools 2 Zwischenergebnisse 17
OUTLINE 1. Wozu Vielkern-Betriebssysteme? Herausforderungen - Vielkern-Prozessoren Anforderungen - Zwei Szenarien Konzequenzen - Entwurfsziele 2. Zwischenergebnisse Die Kunst der Weglassens Wartefreie Aufgabenverwaltung Pragmatische Kompromisse 3. Zusammenfassung 3 Zusammenfassung 18
ZUSAMMENFASSUNG Vielkern-Prozessoren steigern die Herausforderungen MyThOS als Experiment-Plattform für parallele BS Zeigt Potentiale für dynamische Anwendungen 3 Zusammenfassung 19
ZUSAMMENFASSUNG Vielkern-Prozessoren steigern die Herausforderungen MyThOS als Experiment-Plattform für parallele BS Zeigt Potentiale für dynamische Anwendungen Vielen Dank für Ihre Fragen! 3 Zusammenfassung 19