Manycore-RTOS und smartes Scheduling für IoT-Anwendungen

Anbieter zum Thema

MicroConsult Microelectronics Consulting & Training GmbH

Parasoft® Deutschland GmbH

eSOL

Controller mit mehreren heterogenen Rechenkernen sind meist auf eine Aufgabe spezialisiert. Sollen unterschiedliche Applikationen laufen, sind Architekturen mit homogenen Cores einfacher skalierbar.

Das rasante Wachstum des Internet der Dinge (IoT) und Cloud-basierter Anwendungen lässt sich nur mit neuen Funktionen in „intelligenten“ (smarten) Systemen wirksam unterstützen. Dies zeigt sich anhand zunehmender Trends wie Edge Computing, das bereits auf KI (künstliche Intelligenz) in Endgeräten (Edge Computing) zurückgreift und in der steigenden Nachfrage nach intelligenter Cyber-Sicherheit in IoT-Systemen. Dieser Bedarf an fortschrittlicher Rechenleistung tritt auch in jedem anderen Bereich auf, der eine kostengünstige Verarbeitung erfordert und wird derzeit mit Multicore-Systemen gedeckt.

Die Anzahl der in einem einzigen Chip integrierten Rechenkerne (Cores) nimmt zu, und obwohl viele davon heterogen sind, hat auch die Verwendung homogener Cores zugenommen. Anwendungsspezifische heterogene Lösungen sind optimal, wenn eine höhere Leistungsfähigkeit pro Watt erzielt werden soll. Leider können sie nur selten auf eine andere Anwendung skaliert werden. Dies schafft Möglichkeiten für den Einsatz homogener Cores, die viel einfacher skalierbar sind.

Bildergalerie

Während ein gängiger IC als Ganzes heterogen ist, besteht eine übliche Konfiguration aus Clustern großer Universal-, Grafik- und spezieller Beschleuniger-Cores sowie aus mehreren Clustern kleiner homogener Cores. Eine Reihe von Speichersubsystemen besteht aus einem Cluster lokal genutzten Speichers und externem Speicher, auf den die Cores nicht direkt zugreifen können. Jeder Core kann dabei einen lokalen Core-Speicher aufweisen, auf den auch andere Cores zugreifen können, wodurch ein verteilter gemeinsam genutzter Speicher gebildet wird – oder jeder Core kann einen lokalen mehrstufigen Cache besitzen und zusätzlich auf einem systemweit gemeinsam genutzten Speicher zugreifen (Bild 1).

Die zunehmende Anzahl an Cores erfordert jedoch mehr Softwareverarbeitung und deren Verwaltung. Der gängigste Ansatz zur Verwaltung von Laufzeit-Software ist der Einsatz eines Betriebssystems (OS; Operating System) – in diesem Fall eines Manycore-OS. Für Multicore-Prozessoren mit bis zu vier Cores, wird entweder SMP (Symmetric Multiprocessing) oder AMP (Asymmetric Multiprocessing) verwendet. Bei SMP ist keine feste Rolle für jeden CPU-Core festgelegt. Die Lastverteilung erfolgt durch Verarbeitung eines einzelnen Programms mit mehreren Cores. Da SMP die Last dynamisch auf mehrere Cores verteilt und ausführen lässt, kann die Echtzeitfunktion nicht vollständig garantiert werden, und Programme mit niedriger Priorität lassen sich möglicherweise erst dann ausführen, wenn ein CPU-Core wieder frei ist. AMP basiert hingegen auf einer Softwarestruktur vom Typ „Funktionsverteilung“ für solche Systeme, in denen jedem Core eine feste Rolle zugewiesen wird, sodass jeder Core getrennte Programme verarbeitet.

Der Preis, der bei AMP für die statische Zuordnung aller Threads zu jedem Core, die daraus resultierende Core-zu-Core-Thread-Kommunikation und gemeinsame Nutzung von Ressourcen und Diensten, kann erheblich sein. Einige Betriebssysteme versuchen dies durch einen Mix von AMP und SMP zu lösen, aber die zunehmende Anzahl von Cores erfordern aus Sicht des Softwaresystems ein spezielles SMP-Manycore-OS. Zu den Problemen bei SMP-Betriebssystemen auf einem Manycore-Prozessor zählt die Cache-Kohärenz, da viele Manycore-Prozessoren keine Hardware-Cache-Kohärenz zur Verfügung stellen. SMP erfordert aber gerade diese Hardware-Cache-Kohärenz und einen systemweit gemeinsam genutzten Speicher, auch wenn die Kosten für die Aufrechterhaltung der Kohärenz zwischen den verschiedenen lokalen Caches und Cache-Ebenen in einem Chip sehr hoch sein können.

Scheduling: Herausforderung bei Manycore-Prozessoren

Eine weitere Herausforderung für ein Manycore-OS ist das Scheduling. Die Lastverteilung verbessert zwar den Durchsatz, verschlechtert dabei jedoch auch die Echtzeitfähigkeit aufgrund des inhärenten Overheads der Thread-Übergänge und deren Unsicherheit. Die Herausforderung an das Scheduling ist die möglichst effiziente Verwendung der Betriebssystemarchitektur, die dadurch den Aufbau des Schedulers erheblich beeinflusst. Eine neuartige Manycore-Echtzeit-Scheduling-Methode namens „Semi-Priority Based Scheduling“ (SPBS) zielt auf die Manycore-Prozessor-Anforderungen wie Cache-Kohärenz, Speicherfreigabe und Inter-Core-Transport. Die Anwendung muss weder wissen, wie viele Cores vorhanden sind, noch auf welchem Core sie ausgeführt wird. Bei einem echten Manycore-RTOS befindet sich auf jedem Core ein kleiner Mikrokernel, wodurch ein verteiltes Kernelsystem entsteht. Der Mikrokernel verfügt über einen Message-, Interrupt- und Memory-Manager sowie einen Scheduler mit grundlegendem Task-Management (Bild 2).

Core-transparente Kernel-APIs ermöglichen dem User eine klassische SMP-Ansicht auf die Anwendung, was Software Portabilität und skalierbare Leistungsfähigkeit über eine flexible Anzahl von Cores bietet. OS-Dienste werden als Server-Threads implementiert, die über mehrere Cores verteilt sind. Bei Diensten, die Ressourcen benötigen, ist der Server nicht nur verteilt, sondern auch hierarchisch, und jede Dienstanforderung, die von einem lokalen Server nicht erfüllt werden kann, wird auf einen übergeordneten Server umgeleitet. Threads und Server werden von einem „Name Service“ benannt und verwaltet.

Da jeder Kernel nur Threads innerhalb seines Cores plant, verwaltet ein Thread-basierter Scheduler diese übergeordnet für alle Cores innerhalb eines Scheduling-Clusters. Clustering oder das Gruppieren von Cores kann für das Partitionieren von Ressourcen und Serverinstanzen verwendet werden. Nicht Interrupt-gesteuerte, schnelle Inter-Core-Kommunikationsprimitive kommen für harte Echtzeit-Threads mit höherer Priorität oder für Threads mit hoher Kommunikationsfrequenz zum Einsatz. Um ein Scheduling in Echtzeit und mit hohem Durchsatz zu erzielen, sind konkurrierende Faktoren zu berücksichtigen. Höhere Durchsätze erfordern einen Lastausgleich, der sich auf die Echtzeitfähigkeit auswirkt. Ein Verbot des Lastausgleichs zur Sicherstellung der Echtzeitfähigkeit führt dagegen zu einem geringeren durchschnittlichen Durchsatz. SPBS stellt das Echtzeit-Scheduling von Threads mit höherer Priorität sicher, während Threads mit niedrigerer Priorität nach der Lastausgleichsmethode behandelt werden (Bild 3).

Bei SPBS arbeiten zwei Arten von Schedulern parallel

Schauen wir uns eMCOS, ein von eSOL entwickeltes Produkt, an. eMCOS verfügt über einen einzigartigen Scheduling-Algorithmus, das bereits erwähnte SPBS, das den in vielen Embedded-Systemen erforderlichen Echtzeit-Determinismus gewährleistet und gleichzeitig eine höhere Leistungsfähigkeit durch Lastausgleich erzielt. Bei SPBS arbeiten zwei Arten von Schedulern parallel: Ein Thread-Gruppen-Scheduler mit hoher Priorität und einer mit niedrigerer Priorität, der die Arbeitslast gemäß der Prioritäten auf die verfügbaren Cores verteilt.

Die Wichtigkeit von Tasks wird als Thread-Priorität ausgedrückt, eine dynamische Eigenschaft, die durch Lastausgleich gehandhabt wird. Unter den Threads mit gleicher Priorität werden bei diesem Scheduling diejenigen mit längeren Ausführungszeiten als höhere Lasten betrachtet. Der erste Scheduler läuft unabhängig auf jedem Core und verwendet einen klassischen prioritätsbasierten Algorithmus zur Auswahl des auszuführenden Threads. Da jeder Kernel unabhängig ausgeführt wird, erfolgen Scheduling und Kontext-Switching auf optimimaler Weise – vergleichbar mit einem Single-Core-System, und ohne dass eine Synchronisierung zwischen den Cores erforderlich ist.

Der zweite Scheduler verteilt die Last durch periodisches Messen der CPU-Auslastung jedes Threads und führt Thread-Gruppen mit niedriger Priorität auf den verbleibenden Cores aus. Dabei berücksichtigt er den relativen Durchsatz und die Priorität der Threads. Bei Bedarf kann dieser zweite Scheduler Threads mit niedriger Priorität in andere, weniger ausgelastete Cores verlagern, was die beste Leistungsfähigkeit ermöglicht. Threads mit hoher Priorität bleiben unberührt, um den Systemdeterminismus zu erhalten. Da keine Interrupts beim Thread-Wechsel auf einen anderen Core und der Ausführung auftreten, lässt sich die Zeit berechnen, die jeder Thread benötigt, um die Verarbeitung innerhalb der erforderlichen Echtzeitgrenzen abzuschließen.

Ein Vergleich anhand eines eMCOS-Prototyps zeigt, dass SPBS andere Scheduling-Methoden bei Thread-Konfigurationen mit starken Unterschieden zwischen den Thread-Workloads eindeutig übertrifft. Das Ziel bei SPBS besteht darin, die Thread-Prioritäten zu berücksichtigen und gleichzeitig den Gesamtdurchsatz zu maximieren. N höchste Threads, die N verschiedenen Cores zugeordnet sind, erfahren keinen Thread-Übergang und sind immer der Thread mit der höchsten Priorität auf den Cores, denen sie zugeordnet sind. Der Rest der Threads verwendet ein prioritätsbasiertes Scheduling für den Lastausgleich, bei dem Threads mit höherer Priorität gegenüber Threads mit niedrigerer Priorität bevorzugt werden. Damit wird die Thread-Priorität stärker gewichtet als die Anzahl der Threads pro Core. Der Scheduling-Overhead kann mit zunehmender Anzahl von Threads erheblich ansteigen und auch nicht-deterministisch sein.

Dies optimiert der Thread-Scheduler bei SPBS auf die Art, dass die Scheduling-Kosten minimal und deterministischer sind. Datenabhängigkeiten werden derzeit beim Scheduling von Threads nicht berücksichtigt. Daher müssen Anwendungen ihre stark datenabhängigen Threads im selben Core Cluster verarbeiten, anstatt sie auf mehrere Cluster zu verteilen. Der SPBS-Ansatz für ein Manycore-RTOS verwendet auch Thread-Count-Leveling, bei dem die Anzahl der Threads pro Core gleich bleibt sowie eine rein zufällige Zuordnung (Mapping), bei der ein neuer Thread zufällig einem Core zugeordnet wird. Ein vollständig präemtives Scheduling mit fester Priorität, wie es oft in einem kommerziellen RTOS zu finden ist, erfordert dagegen konstantes Messaging zwischen den Cores, was zu einem erheblichen Messaging-Overhead und einer geringen Leistungsfähigkeit führt.

Semiproprietäres Scheduling für optimierten Stromverbrauch

Ein Manycore-RTOS mit neuem semiprioritärem Scheduling ist im Vergleich zu anderen Algorithmen sehr effektiv. Der optimale Wert des zur Berechnung einer Thread-Workload Faktors (derzeit das Quadrat der Thread-Priorität) sollte von bestimmten Thread-Set-Eigenschaften abhängen. Dazu zählt die Verteilung der Thread-Priorität auf verschiedene Thread-Counts sowie die Verteilung der Thread-Ausführungszeit. Die Menge an Software, die auf einem Manycore-Prozessor ausgeführt wird, nimmt weiter zu und erfordert, dass einige der Threads dynamisch erstellt oder gelöscht werden müssen. Die Verbrauchsoptimierung von Prozessoren erfordert eine dynamisch geregelte Stromversorgung, die auf jedem Core unabhängig ausgeführt wird. Dadurch wird neben der Durchsatzoptimierung ein weiterer Parameter für den Lastausgleich eingeführt. Semiprioritäres Scheduling kann auch dies und andere künftige Anforderungen berücksichtigen.

* * Masaki Gondo ... ist CTO und General Manager Technology von eSOL.

* * Rolland Dudemaine ... ist Vice President Engineering von eSOL Europe.

(ID:46677957)