Latenzmessung Coprozessor an Linux: Hörst Du mich?

Anbieter zum Thema

Ingenics Digital GmbH

MicroConsult Academy GmbH

emlix GmbH

Latenz-Ausreißer in der RPMsg-Kommunikation zwischen Linux und FreeRTOS behindern Echtzeitanwendungen. Eine gezielte Analyse zeigt: Der Linux-Kernel ist das Nadelöhr – und lässt sich durch gezielte Modifikationen signifikant optimieren.

Die Interprozessorkommunikation in einem Multiprozessor-SoC mit Remote Processor Messaging (RPMsg) zwischen einer Linux- und einer FreeRTOS-Umgebung weist Latenz-Ausreißer auf, die mehrere Größenordnungen über der Durchschnittslatenz liegen. Mit einem neuen System zur prozessor- und umgebungsübergreifenden Latenzmessung kann gezeigt werden, dass die Ursache im Linux-Kernel liegt. Zur Vermeidung der Ursache werden Modifikationen am Linux-Kernel vorgenommen, mit denen die Latenz-Ausreißer drastisch verringert werden.

An eingebettete Systeme werden z.B. hinsichtlich Konnektivität und GUIs zunehmend höhere Anforderungen gestellt. Um dem gerecht zu werden, wird immer häufiger Embedded Linux eingesetzt [1]. Obwohl dies viele Möglichkeiten eröffnet, hat es aber auch einen entscheidenden Nachteil: Das System verliert die Echtzeitfähigkeit. Ohne aufwändige Änderungen eignet sich der Linux Kernel nicht, um harte Echtzeitanforderungen zu erfüllen.

Heterogene Multiprozessor-System-on-Chip (MPSoC) können hier Abhilfe schaffen. Sie kombinieren Anwendungsprozessorkerne, auf denen Linux ausgeführt wird, mit Coprozessorkernen. Die Coprozessoren können genutzt werden, um eine eigene, dedizierte Firmware auszuführen. Diese Betriebsart eines Mehrkernprozessors mit verschiedenen Umgebungen heißt asymmetrisches Multiprocessing (AMP). Wird als Umgebung für den Coprozessor ein Echtzeitbetriebssystem oder eine Bare-Metal-Umgebung verwendet, können harte Echtzeitanforderungen erfüllt werden. da die Echtzeitumgebung entkoppelt vom Linux [2] ist.

Eine komplette Kapselung der Ausführungsumgebungen ist jedoch nicht nützlich. Schließlich soll das Linux-System dazu in der Lage sein, Informationen mit der Echtzeitumgebung auszutauschen. Der Linux Kernel enthält mit Remote Processor Messaging (RPMsg) ein Framework für die Interprozessorkommunikation (IPK). Für die Implementierung der IPK in der Coprozessor-Firmware gibt es die OpenAMP Bibliothek. Sie enthält auf RPMsg basierende standardisierte Implementierungen und ermöglicht die Anbindung des Coprozessors an Linux.

Voruntersuchungen [3,4] haben gezeigt, dass die Durchschnittslatenzen bei der Kommunikation mit RPMsg zwischen einer Linux-Userspace-Anwendung und einer FreeRTOS-Umgebung bei ca. 100 µs liegen mit vereinzelt auftretenden Ausreißern mit Latenzen über 10 ms.

Bei echtzeitkritischen Anwendungen schränken hohe Worst-Case-Latenzen die Anwendungsszenarien stark ein. Um die Frage nach Ursache und möglicher Vermeidung der Ausreißer zu beantworten, wurde in [4] ein exemplarisches Beispielsystem mit einer Embedded Linux und einer FreeRTOS-Umgebung aufgesetzt und mithilfe eines neu entwickelten Messsystems zur prozessor- und umgebungsübergreifenden Latenzmessung analysiert.

Architektur des Beispielsystems: Linux und FreeRTOS auf einem Chip

Dazu wurde ein Beispielsystem implementiert, das eine Linux-Umgebung und eine Amazon FreeRTOS-Umgebung auf einem MPSoC ausführt (Bild 1).

Als Hardware wurde ein i.MX 93 von NXP ausgewählt. Er hat hat neben Cortex-A-Anwendungsprozessoren auch einen Cortex-M-Mikrocontrollerprozessor integriert [4].

RPMsg: Kommunikation mit Shared Memory und Interprozessor-Interrupts

Das RPMsg-Framework nutzt die Tatsache, dass die kommunizierenden Prozessoren als heterogener MPSoC in einem Chip integriert sind. Bei heterogenen MPSoCs nutzen die Prozessoren alle gemeinsam den selben Speicher. Dadurch sind für die Kommunikation keine Busse oder seriellen Schnittstellen nötig. Stattdessen wird ein spezieller Speicherbereich, das Shared-Memory, genutzt über den die Prozessoren Daten austauschen. Bei der IPK erfüllt das Shared-Memory zusammen mit Interprozessor-Interrupts (IPIs) die Funktionen der Bitübertragungsschicht des OSI-Referenzmodells.

Mit Virtual IO wird bei der IPK sichergestellt, dass es keine Kollisionen beim Zugriff auf das Shared-Memory gibt und die Empfänger über neue Daten benachrichtig werden (Sicherungs- und Vermittlungsschicht). Das RPMsg Protokoll ermöglicht die dynamische Erzeugung und Verknüpfung von RPMsg-Endpunkten zum Nachrichtenaustausch (Transportschicht). Sämtliche Schichten, die an der IPK beteiligt sind, existieren jeweils im Linux-Kernel und in der Firmware des Coprozessors.

IPK-Latenz: Prozessor- und umgebungsübergreifende Zeitmessung

Eine per RPMsg zwischen Coprozessor- und Linux-Umgebung ausgetauschte Nachricht durchläuft verschiedene Schichten in verschiedenen Umgebungen und auf verschiedenen Prozessoren. Zwar stellt der Linux-Kernel mehrere Möglichkeiten zur Zeitmessung zur Verfügung, jedoch kann damit nicht die Dauer von Abläufen erfasst werden, bei denen nicht sowohl der Start- als auch der Endpunkt in der Linux-Umgebung liegen. Deshalb wurde in der Voruntersuchung [4] ein spezielles Messystem entwickelt (Bild. 2).

Das System nutzt ein Hardware-Timer-Modul des MPSoC. Dieses Modul ist aus dem Linux-Userspace, dem Linux-Kernelspace und der Firmware des Coprozessors zugänglich. Damit können an beliebigen Stellen des Ablaufs der IPK Zeitstempel erzeugt und darüber die Dauer zwischen den Schritten bestimmt werden. Das Messsystem beeinflusst den gemessenen Prozess nur minimal und kann eine große Anzahl an Messungen automatisch durchzuführen, um auch selten auftretende Effekte zu erfassen.

IPK-Latenz: Ursache der Latenz-Ausreißer

Die Voruntersuchung in [4] haben gezeigt, dass sich die Latenz-Ausreißer auf eine Kommunikationsrichtung beschränken (Tabelle 1).

Bei der L2F-Kommunikation liegt die beobachtete Maximallatenz mit 71 µs in derselben Größenordnung wie die Durchschnittslatenz von 21 µs. Im Gegensatz dazu gibt es bei der F2L-Kommunikation Ausreißer von fast 9 ms, die einer Durchschnittslatenz von lediglich 104 µs gegenüberstehen.

Bei der Analyse der F2L-Kommunikation (Tab. 2) wurde in [4] festgestellt, dass sich die Latenzausreißer vor allem auf zwei Abschnitte konzentrieren.

Ursache für die Ausreißer sind die Verzögerung durch die Workqueue in Abschnitt 4 und die Userspace-Schnittstelle (TTY) im 6. Abschnitt. Diese verwendet intern eine weitere Workqueue. Die Ursache für die hohen Latenzausreißer ist folglich die Latenz zwischen Einfügen und Abarbeiten von Arbeitsaufträgen mit einer Workqueue.

Modifikationen und Evaluation

Um die Ausreißer in der RPMsg-Kommunikation zu vermeiden, muss die Ursache, die Workqueue-Verzögerung, vermieden werden: Wenn statt einer TTY-basierten eine Char-Device-basierte Userspace-Schnittstelle verwendet wird, kommt hier keine Workqueue zum Einsatz.

Bei der Abarbeitung der IPIs wird jedoch eine Workqueue zur Abarbeitung der Interrupts im Prozess-Kontext statt im Interrupt-Kontext eingesetzt. Zum einen kann so der Linux-Kernel mit geringerer Verzögerung auf neue Interrupts reagieren, da er sich kürzer im Interrupt-Kontext befindet. Zum anderen ist es im Interrupt-Kontext nicht möglich bestimmte Funktionen des Linux-Kernels zu nutzen.

Deutschlands Leitkongress der Embedded-Softwarebranche

Bewerben Sie sich als Sprecher

Gestalten Sie den ESE Kongress aktiv mit! Es gibt viele gute Gründe, warum Sie sich mit Ihrem eigenen Vortrag oder Seminar am Programm beteiligen sollten. Teilen Sie Ihr Wissen, Ihre Erfahrung und Ihre Erkenntnisse mit Ihren Branchenkollegen. Nutzen Sie den ESE Kongress als bewährte Plattform, um sich als Software-Experte einen Namen zu machen und Ihren Marktwert zu steigern, und präsentieren Sie Ihre Lösungen einem hochwertigen Fachpublikum.

Jetzt Vortrag einreichen!

Die Verarbeitungsdauer einer RPMsg-Nachricht liegt in einer unkritischen Größenordnung und es werden auch keine nicht im Interrupt-Kontext verfügbaren Funktionen des Linux-Kernels benötigt. Jedoch werden während des Aufbaus der Kommunikation bei der dynamischen Erzeugung von RPMsg-Endpunkten spezielle Nameservice-Nachrichten ausgetauscht, die in der Linux-Umgebung zur Erzeugung einer neuen Userspace-Schnittstellen-Instanz führen, was nicht im Interrupt-Kontext möglich ist.

So kann die Workqueue nicht vollständig aus dem Kommunikationsablauf entfernt werden. Durch die Unterscheidung zwischen regulären und Nameservice-Nachrichten kann die Workqueue auf die IPIs beschränkt werden, die eine Nameservice-Nachricht ankündigen. Dadurch wird weder die Funktion eingeschränkt noch ein unnötiges Interrupt-Deferral bei regulären RPMsg-Nachrichten durchgeführt.

Mit einem derart modifizierten Linux-Kernel und der Char-Device-basierten Userspace-Schnittstelle wurden die bereits durchgeführten Latenzmessungen wiederholt (Tab. 3).

Die Ergebnisse der Latenzmessungen zeigen, dass durch die Modifikationen die Ausreißer von ca. 9 ms auf unter 0,6 ms reduziert werden konnten. Diese Verbesserung erlaubt es, das OpenAMP-Framework auch in Systemen mit höheren Echtzeitanforderungen zum Einsatz zu bringen.

SEMINAR-TIPP

Embedded-Linux-Woche

In den Kursen der Embedded-Linux-Woche führen unsere Referenten Sie Schritt für Schritt in die Linux-Welt ein. Fortgeschrittene können sich im Seminarangebot "Echtzeit-Linux und Systemprogrammierung" vom einfachen Embedded-Linux-User zum systemnahen Echtzeit-Entwickler weiterbilden. In nur fünf Tagen erarbeiten Sie sich fundiertes Fachwissen um den Linux-Kernel, Prozessverwaltung, Tracing, Ressoucenverwaltung, Hardware-Anbindung und vieles mehr, so dass Sie sich schon bald als waschechten Linux-Experten bezeichnen können!

Weitere Details und Termine

Literatur- und Quellenverzeichnis

[1] Embedded Linux Market Report Overview. Business Research Insights, April 2024, www.businessresearchinsights.com/market-reports/embedded-linux-market-108687.

[2] Nao, L.; Passaro, P.; Gioia, E. und Petracca, M.: Asymmetric multiprocessing techniques in smart devices: Application in a drone navigation system. 25th International Conference on Software, Telecommunications and Computer Networks (SoftCOM), 2017, S. 1–5, https://doi.org/10.23919/SOFTCOM.2017.8115511.

[3] Kauschke, D. (2021). Umsetzung von Asymmetric Multiprocessing mit OpenAMP. Tagungsband Embedded Software Engineering Kongress 2021, 52-57, https://www.embedded-software-engineering.de/umsetzung-von-asymmetric-multiprocessing-mit-openamp-a-487017d6cfa0c3b6faf413a40fde6304/

[4] Kaiser, M. (2024, Oktober). Latenzen bei der Interprozessorkommunikation mit OpenAMP. Elektronik Embedded Systems (20), 14-20, https://www.elektroniknet.de/embedded/software/latenzen-bei-der-interprozessorkommunikation-mit-openamp.220662.html

Dieser Beitrag wurde mit freundlicher Genehmigung des Autors aus dem Tagungsband des ESE Kongress 2024 übernommen. (sg)

* Malte Kaiser ist Softwareentwickler bei Ingenics Digital GmbH in Gräfelfing bei München mit Fokus auf Firmware-Entwicklung für eingebettete Systeme mit Bare-Metal- und RTOS-Umgebungen sowie Embedded Linux.

(ID:50385653)