Energieeffizienz dank Multicore

Multithreading im Multiprocessing-Echtzeit-Betriebssystem

Energieeffizienz dank Multicore

Embedded-Software-Entwickler stehen heute Komplexitäten und Anforderungen gegenüber, die vor zehn Jahren noch unvorstellbar waren. Eine der häufigsten Herausforderungen stellt das Thema Energieeffizienz dar: Teams sollen Designs entwickeln, die Vorteile von Hardware- und Software-Power-Management-Funktionen nutzen und gleichzeitig hinsichtlich Funktionalität und Performance optimiert sind.

 Energieeffizienz und hohe Leistung müssen sich nicht ausschließen. (Bild: © monsterdruck.de - Fotolia.com)

Energieeffizienz und hohe Leistung müssen sich nicht ausschließen. (Bild: © monsterdruck.de – Fotolia.com)


Trotz des Zielkonflikts zwischen Energieeffizienz und höherer Performance entstehen innerhalb von Embedded-Multicore-Systemdesigns Situationen, in denen sich Leistungsaufnahme und Performance ergänzen: Ein Symmetrisches Multiprocessing-Echtzeit-Betriebssystem (SMP-RTOS) lässt sich mit Multicore-Hardware und Power-Management-Funkionen verbinden, um parallele Embedded-Programmierung zu erleichtern. Obwohl die Power-Management-Funktionen eines vollständig ausgestatten RTOS wesentlich zu einem energieeffizienten Design beitragen, existieren Thread-Synchronisierungsmechanismen, die auf von der Hardware gelieferten Primitiven basieren und für Energieeinsparungen bei gleichzeitiger Verbesserung der System-Performance sorgen. Muliticore hat sich in der Embedded-Welt inzwischen etabliert: Nahezu alle großen Halbleiteranbieter liefern Multicore-Chips, z.B. ARM (Cortex A9), PowerPC (QorIQ), MIPS (1004K MT) und Intel (Atom). Höhere Performance ist aber nicht der einzige Faktor hinter diesem Trend. Embedded Systeme können sich keine Performancesteigerung auf Kosten eines höheren Leistungsbudgets oder Beeinträchtigung vorhandener Software leisten. Embedded-Halbleiteranbieter fokussieren sich deshalb auf eine kleine Anzahl von Kernen, in der Regel nicht mehr als acht.

Flexibel mit Multicore

Eine Embedded-Runtime-Softwarelösung mit Betriebssystem, Middleware und Endanwendungen, die auf Multicore-Plattformen abzielt, muss Performance, Leistungsbedarf und bestehende Softwaredesigns berücksichtigen. Obwohl Parallel-Computing ein ziemlich fortschrittliches Feld mit vielen verfügbaren Programmiersprachen, Architekturen und Computertechnologien ist, führt die parallele Embedded-Entwicklung aufgrund der Vielzahl von Hardware und involvierten Tools zu neuen Anforderungen, die hohe Flexibilität erfordern. Da es keinen allgemein akzeptierten Multicore-Programmierstandard gibt, verlassen sich die meisten Entwickler von Embedded-Anwendungen auf Thread-Level Parallelism (TLP), den das RTOS liefert. In der Theorie verspricht dieser Ansatz keine Veränderungen des bestehenden Codes, wenn die RTOS-Unterstützung für die Multicore-Architektur robust ist. Doch TLP ist immer mit Overhead verbunden. Dies liegt an der Erstellung und Terminierung von Worker-Threads sowie an der Synchronisation zwischen einzelnen Kontexten. Typische Embedded-Systeme besitzen jedoch eine begrenzte Anzahl von Threads. Aktiviert wird ein Software-Kontext üblicherweise als Ergebnis eines externen Ereignisses, z.B. eines Interrupts. Dieser Thread muss dann die Ausführung in der vorgeschriebenen Zeit abschließen. Basierend auf den Eigenschaften von Embedded-Runtime-Applikationen verringert die Verwendung wichtiger Preemption- und Prioritäts-Thread-Attribute in einem Echtzeit-Betriebssystem der TLP-Overhead. Die Grundidee ist es, Parent- und Child-Threads auf verschiedenen Ebenen zu priorisieren, damit keine Synchronisierungszeit erforderlich ist. In Situationen, in denen eine Synchronisation unvermeidlich ist, verwendet das vorgeschlagene Schema energiesparende Primitiven, die von der Hardware geliefert werden. Ein weiterer Ansatz zur Entwicklung von Lastausgleichsstrategien und neuen Echtzeit-Scheduling-Algorithmen besteht darin, maximale Auslastung von mehreren Ressourcen zu erlangen. Aber diese Schemata erfordern in der Anwendungslogik oder im Betriebssystem-Code oft signifikante Änderungen. Sie haben für ein praktikables System erhebliche Nachteile, da ein Großteil des vorhandenen, zertifizierten und robusten Codes entweder gefährdet oder unbrauchbar ist. Statt der Suche nach einer optimalen Scheduling-Technik oder raffinierten Compiler-Technologie, empfiehlt sich ein portables Schema, das den Anwendungscode nicht beeinflusst und nur Veränderungen der Wrapper-Funktion der RTOS-Schnittstelle enthält.

Systemmodell: Round Robin oder Priorisierung

Das als Beispiel gewählte Embedded-System besteht aus einer Multicore-Plattform mit M identischen bzw. homogenen Kernen. Der SMP-RTOS-Thread-Scheduler folgt dem traditionellen Ansatz eines primitiven Threading-Modells mit festen Prioritäten. Diese Art des Schedulings ist in den heute kommerziell verfügbaren RTOS am weitesten verbreitet. Ein solcher Ansatz sorgt dafür, dass der wichtigste Thread immer als erster abläuft. Jeder unterbrechbare Thread mit niedrigerer Priorität kann nur von einem Thread mit höherer Priorität angehalten werden. Daher ist für wichtige Threads eine indirekte Garantie für den Echtzeitbetrieb erhältlich. Threads mit gleicher Priorität werden nach dem Round-Robin-Verfahren ausgeführt. Eine einfache Multicore-Erweiterung dieses Modells nimmt den Thread mit der höchsten Priorität ’n‘ (0 < M-1) und versendet ihn an einen der 'n' verfügbaren freien Kerne. Will man so viel Legacy-Code wie möglich nutzen, geht der einfachste Weg zur Multicore-Entwicklung über TLP unter einem Parent-Child-Programmiermodell. Bei diesem Beispiel bleibt der Code unabhängig von parallelen Programmierkonstrukten. Das Parent-Child-Modell hat keinen Einfluss auf die Deadline-Anforderungen solange es TLP unter den Grenzwerten halten kann. Beispielsweise kann ein vorhandener Anwendungs-Thread (Parent), der Video-Frames dekodiert, die Ausführung mit Hilfe von TLP beschleunigen, wenn er Frames unter den Child-Threads aufteilt. Diese Child-Threads laufen parallel auf mehreren verfügbaren Kernen ab und erhöhen so unter Umständen die Performance des Systems. Dort gibt es nur sehr geringe Anforderungen für Codeänderungen. Ein 'Parent' muss verteilen und dann auf alle 'Children' warten, um eine Task abzuschließen. Wenn Thread-Erstellung (Fork) und Wartezeit (Join) im Vergleich zur Thread-Workload klein sind, lassen sich die Deadline-Anforderungen des Original-Threads leicht erfüllen. Fork- und Join-Services sind üblicherweise Wrapper, die andere Standard-RTOS-Schnittstellen umgeben.

Seiten: 1 2Auf einer Seite lesen

Mentor Graphics (Deutschland) GmbH
www.mentor.com

Das könnte Sie auch Interessieren