18lA UTOMOTIVE 1-2.2010l KOMPONENTEN ANPASSUNG DES LLREF-ALGORITHMUS Multi-Core-Scheduling in Embedded Systemen, Teil 1 Mehrkernprozessoren kommen zunehmend auch in eingebetteten Systemen zum Einsatz. Um den dort gegebenen Echtzeitansprüchen gerecht zu werden, müssen spezielle Algorithmen verwendet werden. Der LLREF- Algorithmus gilt als solcher optimaler Algorithmus. In der Original-Version verwendet dieser Algorithmus eine kontinuierliche Zeitbasis. Diese ist jedoch in einem eingebetteten System nicht gegeben, da dort eine quantisierte Systemzeit vorliegt. Deshalb muss der ursprüngliche LLREF-Algorithmus angepasst werden. In diesem Beitrag werden die nötigen Änderungen veranschaulicht. Den zweiten Teil lesen Sie in der nächsten Ausgabe der Hanser automotive. Der Largest Local Remaining Execution time First (LLREF) Scheduling-Algorithmus für Multi-Core- Architekturen wird im Original vorgestellt und modifiziert. Der ursprüngliche LLREF-Algorithmus nutzt eine kontinuierliche Zeitbasis. In einem Embedded System hingegen ist die Systemzeit durch den diskreten Systemtick quantifiziert. Bei der praktischen Umsetzung kann dies dazu führen, dass zu einem theoretisch ausführbaren Taskgefüge der gewählte LLREF- Scheduler im realen System keinen die Schedulingbedingungen erfüllenden Taskablauf erzeugen kann. Die vorgestellte Implementierung des LLREF-Algorithmus erfordert die Erweiterung des Zustandes SUSPEN- DED im bekannten Taskzustandsmodell um den Zustand REACTIVATE. Dadurch werden diejenigen Phasen berücksichtigt, in denen ein Task innerhalb einer Time and Local Execution Time Plane (TL-Ebene) inaktiv ist. Mehrkernprozessoren kommen zunehmend auch in eingebetteten Systemen zum Einsatz. Um den Echtzeitansprüchen gerecht zu werden, müssen spezielle Algorithmen verwendet werden. Bekannte Algorithmen, wie RMS oder EDF [GBUT2004], [WSTA2009], erzielen keine optimalen Ergebnisse. Der LLREF-Algorithmus gilt als solcher optimaler Algorithmus, welcher eine Utilisation von 100% ermöglicht. In der originalen Version
verwendet dieser Algorithmus eine kontinuierliche Zeitbasis. Diese ist jedoch in einem eingebetteten System nicht gegeben, da dort eine quantisierte Systemzeit vorliegt. Deshalb muss der ursprüngliche LLREF-Algorithmus angepasst werden. Um diese nötigen Änderungen zu veranschaulichen, wird zuerst der LLREF-Algorithmus [HCHO2006] vorgestellt. Darauf folgend werden die Auswirkungen der diskreten Systemzeit auf den Algorithmus betrachtet. Im letzten Abschnitt werden Möglichkeiten zur Lösung des Zeitdiskretisierungsproblems, wie Fill Pane, und das Ausnutzen von Rechenzeit am Ende einer Ebene aufgezeigt. Der modifizierte LLREF-Algorithmus wurde auf dem Dual-Core- Prozessor MPC5517 von Freescale Semiconductors als symmetrisches Multiprocessing implementiert. Der originale LLREF-Scheduling-Algorithmus Hyeonjoong Cho et al. stellen in An Optimal Real-Time Scheduling Algorithm for Multiprocessors [HCHO2006] einen Scheduling-Algorithmus für Multi-Core- Systeme vor, welcher auf Grundlagen des Pfair-Algorithmus [PHOL2004] basiert. Er wurde jedoch dahingehend verbessert, dass die Anzahl der Kontextwechsel und Task-Migrationen verringert werden. Der für periodische Taskgefüge konzipierte Algorithmus hat folgende Eigenschaften: Der LLREF-Algorithmus ist ein optimales Scheduling-Verfahren, welches einen durchführbaren Schedule garantiert, wenn die Gesamtprozessorauslastung kleiner oder gleich der Anzahl der vorhandenen Prozessoren ist. Die Task-Migrationen sowie die Kontextwechsel werden im Vergleich zu Pfair minimiert. KOMPONENTENl AUTOMOTIVE 1-2.2010l19 Bild 1: Fluider Schedule (oben) und reale Task-Ausführung (unten), vgl. [HCHO2006]. Im Nachfolgenden soll der LLREF-Algorithmus nach Cho vorgestellt werden. Für die reale Implementierung sind jedoch einige Anpassungen nötig, da Cho keine Quantisierung der Zeit vorsieht, wie es in realen eingebetteten Systemen der Fall ist. Time and Local Remaining Execution Time Plane Die Time and Local Remaining Execution Time Plane (TL- Ebene) ist die grafische Veranschaulichung des LLREF- Algorithmus. Die TL-Ebene stellt eine einzelne Periode innerhalb des zeitlichen Ablaufs des Schedules dar. Sie entsteht durch die Überlagerung der einzelnen Fluid- Schedules, der Tasks des Tasksets. Unter Fluid-Schedule versteht man die fiktive, kontinuierliche Abarbeitung einer vorgegebenen execution time C i innerhalb einer (Task-) Periode P i (Bild 1). Bild 2 stellt eine TL-Ebene mit einem beispielhaften Taskset von drei Tasks dar. Dabei behalten die einzelnen fluiden Bild 2: TL-Ebene mit einem beispielhaften Taskset von drei Tasks die reale Abarbeitung ist mit durchgezogenen, der Fluid-Schedule mit gestrichelten Linien dargestellt. Die Größe der Ebenen kann auf Grund unterschiedlicher Periodendauern der Tasks über die Zeit variieren.
20lA UTOMOTIVE Schedules ihre Steigung U i bei und schneiden die x-achse am Ende der TL-Ebene. Die local remaining execution time l i einer Task T i zu Beginn (tsk) der k-ten Ebene lässt sich nach Gleichung 1 berechnen. Sie ergibt sich aus der Aufteilung der execution time Ci innerhalb einer Taskperiode P i auf die darin befindlichen TL-Ebenen und stellt die aktuell abzuarbeitende Rechenzeit dar: Hiermit ist der Startpunkt des fluiden Schedules auf der y Achse bestimmt. Die local execution time c i ist die für eine TL-Ebene geplante Ausführungszeit. Mit dem zeitlichen Verlauf reihen sich die TLk-Ebenen aneinander, die Größe der TL-Ebene kann wegen unterschiedlicher Periodendauern der Tasks dabei über die Zeit variieren. Die zeitliche Ausdehnung einer TL-Ebene soll an einem Spezialfall für ein harmonisches Taskgefüge (Bild 3) veranschaulicht werden. Liegt kein harmonisches Taskgefüge vor, so bestimmt sich die über die Zeit veränderliche Größe der TL-Ebenen aus zwei aufeinanderfolgenden Deadlines aller am Scheduling beteiligten Tasks. Sind alle einzuplanenden Tasks harmonisch, haben also eine Periodendauer, die ein ganzzahliges Vielfaches der anderen Tasks ist und sind nicht phasenverschoben, so ist die zeitliche Ausdehnung einer TL-Ebene über die Zeit konstant, der Overhead des Schedulers ist geringer. Die konstante Größe der TL-Ebenen ergibt sich aus dem größten gemeinsamen Teiler der Periodendauern aller am Scheduling beteiligten Tasks. Scheduling Nach der Scheduling-Strategie Larges Local Remaining Execution time First werden Tasks (T1 und T3) mit der höchsten Ausführungszeit innerhalb einer Ebene zuerst gestartet (Bild 4). Somit werden bei einem System mit M Prozessoren M Tasks simultan ausgeführt. Zum Ende einer jeden TL-Ebene müssen sich realer und fluider Schedule auf der x-achse zum Zeitpunkt tfk schneiden. Durch diese Bedingung wird sichergestellt, dass jede Task ihre Deadline einhält, da sie somit innerhalb der Ebene ihre local execution time c i verbraucht haben muss. Weil die Task-deadlines auf 1-2.2010l KOMPONENTEN das Ende einer TL-Ebene fallen, wird durch das Einhalten der local deadlines innerhalb der Ebene sichergestellt, dass alle deadlines der Tasks eingehalten werden können. Scheduling Events in der TL-Ebene Der LLREF-Algorithmus unterscheidet zwischen Events und Sub-Events (Bild 5). Die wichtigsten Events bei diesem Algorithmus sind das Ende bzw. Starten einer neuen TL-Ebene. Daneben gibt es innerhalb einer TL-Ebene die beiden besonderen Zeitpunkte der Sub-Events C und B: Sub-Event C Letztmöglicher Zeitpunkt, eine Task zu starten, um die local execution time c i abzuarbeiten, ohne eine lokale Deadline (Ende der Ebene) zu verletzen. Sub-Event B Eine Task hat ihre local execution time c i,j abgearbeitet. Eine neue Task kann entsprechend der Bild 3: Entstehung der TL-Ebene bei harmonischen Task-Gefügen die Größe der TL-Ebenen TTLk bleibt über die Zeit konstant und errechnet sich aus dem größten gemeinsamen Teiler der Taskperioden.
Bild 4: Darstellung eines durch den LLREF-Algorithmus erzeugten Schedules in der TL-Ebene das Taskset wird auf einem System mit M=2 Prozessoren zur Ausführung gebracht. Deutlich zu erkennen ist die Migration von T1 von Prozessor P1 auf P0. Der Startpunkt der Taskgraphen auf der y-achse wird durch Gleichung 1 bestimmt. Scheduling-Strategie gestartet werden. Die drei Arten von Events sollen in den nachstehenden Abschnitten erläutert werden. Dabei wird für die weitere Beschreibung von einem Taskset ausgegangen, welches absteigend nach den local remaining execution times l i sortiert ist. Das Taskset enthält nur Tasks, deren local remaining execution times für diese Ebene noch nicht abgearbeitet worden sind. Starten einer neuen TL-Ebene Zum Ende einer Ebene müssen alle Tasks ihre local execution time c i abgearbeitet haben und somit muss l i zu Null geworden sein. Dies bedeutet, dass in der TL-Ebene alle Taskgraphen die rechte untere Ecke des Dreiecks erreicht haben. Daraus resultiert wiederum, dass das Taskset (die readylist) zum Ende der Ebene keine Tasks mehr enthält, da l i bei allen zu Null geworden ist und KOMPONENTENl AUTOMOTIVE 1-2.2010l21 somit die anfangs genannte Bedingung (l i > 0) für die Zusammensetzung des Tasksets nicht mehr erfüllt ist. Folglich wird beim Starten einer neuen TL-Ebene der Schedule des Taskset komplett neu aufgebaut. Es muss daher die local execution time c i für alle Tasks berechnet werden, sowie die remaining execution times r i der Tasks T i für die darauffolgend zu startende TL-Ebene bestimmt werden und das Taskset nach c i sortiert werden. Auf die Auswirkungen der bei der Berechnung von c i auftretenden Rundungen wird später eingegangen. Sub-Event C Das Event C ( ceiling hitting event ) tritt dann auf, wenn eine Task T i, die gerade nicht ausgeführt wird (folglich i > M), die no local laxity diagonal (NLLD) trifft. Die NLLD ist hier die Hypotenuse in dem durch l i und TTL aufgespannten gleichschenkligen Dreieck, welches die TL-Ebene bildet. Dies bedeutet, dass diese Task sofort ausgeführt werden muss, um ihre lokale deadline einzuhalten. Der Zeitpunkt des Events C wird wie folgt bestimmt: Wir stellen aus: Embedded World 2010, Halle 10, Stand 215
22lA UTOMOTIVE 1-2.2010l KOMPONENTEN Bild 5: Scheduling-Events in der TL-Ebene Ende einer TL- Ebene zum Zeitpunkt tfk Event B (bottom hitting event) beim Treffen des Taskgraphen auf den Boden der Ebene Event C (ceiling hitting event) beim Auftreffen des Taskgraphen auf die no local laxity diagonal (NLLD). Ist das Event C detektiert worden, so muss eine laufende Task sofort unterbrochen und in das Taskset einsortiert werden. Die Scheduling-Strategie largest remaining execution time first wird nun auf das Taskset angewendet und die soeben unterbrochene Task entsprechend ihrer noch austehenden local remaining execution time l i im Taskset (readylist) platziert. Sub-Event B Das Event B ( bottom hitting event ) tritt auf, wenn eine aktive Task (i M) auf die x-achse trifft, sprich den Boden der TL-Ebene. Auf der y-achse einer TL-Ebene ist die local remaining execution time l i aufgetragen. Somit trifft ein Task-Graph auf die x-achse, sobald l i zu Null geworden ist. Dies bedeutet, dass die Task ihr Soll für diese Ebene erfüllt hat und somit die nächste Task gestartet werden kann. Für die praktische Umsetzung ist das Event B daran festzustellen, dass zum Zeitpunkt t j die local remaining execution time l i,j zu Null geworden ist. Modifikationen am LLREF Bei der Implementierung des Algorithmus sind einige Modifikationen auf Grund der genannten, quantisierten Zeitbasis in einem eingebetteten System nötig. Um die Notwendigkeit dieser Modifikationen darzustellen, wird der Einfluss der diskreten Zeitbasis auf den Algorithmus erläutert. Cho et al. [HCHO2006] gehen bei der Beschreibung des LLREF-Algorithmus von einem kontinuierlichen Zeitverlauf aus. In einem realen Embedded System hingegen ist die Zeit quantisiert, d. h. der Systemtick bildet die Zeitbasis. Mit Systemtick wird im Folgenden das Zeitintervall bezeichnet, mit dem die Timer-Interruptserviceroutine getriggert wird, welche den Scheduler zyklisch ausführt. Die Periode des Systemticks ist somit die kleinste Zeiteinheit, die vom Scheduler erfasst werden kann. Deshalb ist eine genauere Zeitauflösung der realen Tasklaufzeit (vorerst) nicht möglich, was dazu führt, dass der Scheduler seine Entscheidung für Taskwechsel auf der Grundlage einer nicht korrekt erfassten Laufzeit treffen muss. Die Vorgabe einer kontinuierlichen Zeit ist daher in der Realität nicht zu verwirklichen, da schon durch den CPU-Takt eine Quantisierung der Zeit vorgenommen wird. Eine weitere Einschränkung in realen Systemen ist, dass häufig keine Hardwareunterstützung für Gleitkommazahlen zur Verfügung steht. Somit ist eine Verwendung von Integer-Zahlen zur Berechnung der verschiedenen Zeiten aus Performancegründen anzuraten. Der Einsatz von Ganzzahlen führt zu Rundungsfehlern in der Berechnung. Diese Rundungsfehler in der Bestimmung der verschiedenen Zeiten wirken sich auf das Scheduling aus. Die entwickelten Behandlungsmethoden dieser Rundungsfehler und der Zeiterfassung sowie die Implementierung des LLREF-Algorithmus auf Ganzzahlbasis und die Zulässigkeit der Modifikationen werden im Teil 2 (in der nächsten Ausgabe) dieses Artikels erläutert. (oe) Stefan Krämer (S_Kraemer@email.de) hat seine Masterarbeit, in welcher er den LLREF- Algorithmus für eine Dual-Core-Architektur implementiert und modifiziert hat, im Laboratory for Safe and Secure Systems und im Labor für Industrielle Elektronik der Hochschule Regensburg a gefertigt. Derzeit arbeitet er als Softwareentwickler bei der Firma ITF-EDV Fröschl. Prof. Dr. Jürgen Mottok (juergen.mottok@etechnik.fh-regensburg.de) lehrt Informatik an der Hochschule Regensburg. Seine Lehrgebiete sind Software Engineering, Programmiersprachen, Betriebssysteme und Functional Safety. Er leitet das Laboratory for Safe and Secure Systems. Prof. Dr.-Ing. Hans Meier (hans.meier@etechnik.fh-regensburg.de) lehrt Mikrocomputertechnik mit hardwarenaher Programmierung an der Hochschule Regensburg. Weitere Interessensgebiete sind die Digitale Bildverarbeitung und der Entwurf von Leiterplatten. Seit 10 Jahren leitet er das Labor für Industrielle Elektronik. Hochschule Regensburg @ www.fh-regensburg.de
JAHRGANG 9 Professionelle Messtechnik ist mehr als Laptop und USB, sagt Rahman Jamal von National Instruments im Interview mit Hanser automotive. FACHZEITSCHRIFTEN FACHBÜCHER ONLINE-SERVICES SEMINARE Carl Hanser Verlag GmbH & Co.KG, München, www.hanser-automotive.de; Nicht zur Verfügung in Intranet- u.internet-angeboten oder elektron. Verteilern Firmenadresse Vorname Firma Branche Abteilung Straße / Postfach Bessere Leistung bei 20 www.hanser-automotive.de nics SW-Suite 10 für Test und Diagnose systems 2010 Privatanschrift Name Position KOMPONENTENl AUTOMOTIVE 1-2.2010l23 schnellerer Information Hybridtechnik Bauelemente, Messtechnik, Testsysteme 14 HANSER AUTOMOTIVE das innovative Fachmagazin für professionelle E/E-Entwickler und Entscheider aus Forschung und technischem Management in der Automobil- und Zuliefer - branche berichtet in 7 Ausgaben pro Jahr unabhängig und umfassend über aktuelle Trends, Produkte, Applikationen und Systemlösungen der Kfz-Elektronik. IM ONLINE-PORTAL HANSER-AUTOMOTIVE.DE finden Sie nicht nur das Heftarchiv ab 2004, sondern auch weitere topaktuelle News, Tipps und Informationen. UNSER TOP-ANGEBOT FÜR SIE: Diese und die nächste Ausgabe kostenlos zum Kennenlernen! Einfach Coupon ausfüllen und per Fax an +49/89/998 30-157 schicken. Ja, ich möchte auch die nächste Ausgabe von HANSER automotive kostenlos lesen. Falls ich nicht spätestens 14 Tage nach Erhalt des Heftes den weiteren Bezug per Fax, E-Mail oder Post abbestelle, abonniere ich HANSER automotive für mindestens 1 Jahr bis auf Widerruf inklusive Zugang zum Online-Voll text archiv unter www.hanser-automotive.de mit der Möglichkeit unbegrenzter Downloads zum Abonnementpreis von jährlich 79, Unverbindliche Preisempfehlung, zzgl. Versandkosten 6,60 (Inland) bzw. 13,30 (Ausland), inkl. MwSt. Die Zeitschrift erscheint siebenmal jährlich. Land / PLZ / Ort Datum / Unterschrift Unternehmensgröße: 1-19 20-49 50-99 100-199 200-499 500-999 über 1.000 Beschäftigte NO (Stand 2010) Carl Hanser Verlag Kolbergerstr. 22 81679 München Tel.: +49/89/998 30-303 Fax: +49/89/98 48 09 abo-service@hanser.de www.hanser-automotive.de