Cache-Nutzung bei Echtzeitsystemen Wie ein Beschleuniger zur Bremse werden kann

Anbieter zum Thema

Open Source Automation Development Lab (OSADL) eG

MicroConsult Academy GmbH

Moderne Caches steigern die CPU-Leistung, können in Echtzeitsystemen aber zum Problem werden. Dieser Beitrag zeigt, wie Cache-Architektur und -Nutzung das Latenzverhalten beeinflussen – und worauf es bei der Auswahl von SoCs ankommt.

Caches sind ein übliches Verfahren der Informationstechnologie, um Zugriffe auf Daten oder Programme auf langsameren Medien wie Festplatten, Netzwerk oder Systemspeicher deutlich zu beschleunigen. Dazu werden Daten, die mit einer gewissen Wahrscheinlichkeit zur Bearbeitung verfügbar sein sollen, in einem verhältnismäßig kleinen, für die Anwendung nicht sichtbaren, und sehr schnellen Pufferspeicher vorgehalten. Caches sind im Verhältnis zum Hauptspeicher eines Systems deswegen eher klein ausgeführt, weil der Geschwindigkeitsvorteil bei immer größerer Ausführung nicht im gleichen Maße ansteigt und dieser schnelle Speicher verhältnismäßig hochpreisig ist.

Die Verwendung der Cache-Technologie bei modernen Prozessoren ein wesentlicher Aspekt für die hohe Performance und daher auch bei Systemen im Embedded-Bereich etabliert. Physikalisch sind deren Caches sehr eng mit dem Prozessor verbunden, wobei heute mehrere (meist zwei oder drei) Stufen der Caches − sogenannte Cachelevels − die Regel sind. Der am nächsten an der CPU gelegene Cache (sogenannter Level 1 Cache) ist in seiner Kapazität am kleinsten ausgeführt; dafür ermöglicht seine Architektur den schnellsten Zugriff. Weitere Stufen des Caches sind größer ausgeführt, haben aber höhere Zugriffszeiten.

Der Vorteil von Caches zeigt sich, wenn auf bestimmte Daten oder Programmteile in einer Ausführungssequenz häufig zugegriffen wird. Dann nämlich werden diese Daten einmal in den Cache geladen und dann dort darauf zugegriffen, statt zum Beispiel im langsameren Arbeitsspeicher.

Bei bestimmten Konstellationen kann der Cache in der Hardwarearchitektur jedoch so gestaltet sein, dass es insbesondere für den angestrebten Determinismus bei Echtzeitsystemen zu unerwünschten Interferenzen kommen kann. Insbesondere bei Mehrkernsystemen, in denen eine strikte Isolation der Kerne von-einander gefordert wird, können gemeinsame Caches dazu führen, dass die Anforderung an komplette Isolation der Prozessorkerne nicht erfüllt werden kann. Diese können sich negativ auf das Echtzeitverhalten auswirken und zu unerwünschten Systemlatenzen führen, sind aber allein durch den Blick auf das Datenblatt nicht unbedingt ersichtlich.

Dieser Beitrag zeigt an verschiedenen Fallstudien auf Echtzeit-Linux-Systemen mit PREEMPT_RT, wie Caches das Echtzeitverhalten in Systemen mit Mehrkernprozessoren und Kernisolation beeinflussen können, welche Lastszenarien hierfür betrachtet werden und wie die ermittelten Messwerte interpretiert werden müssen. Die Ergebnisse zeigen sehr deutlich, wann die Isolation von Prozessorkernen durch gemeinsame Cache-Speicher beeinträchtigt wird und wann nicht. Wenn eine komplette Isolation gefordert ist, sollten diese Ergebnisse bei der Entscheidung für eine bestimmte Prozessor-Architektur bzw. für einen bestimmten Prozessor berücksichtigt werden. Auf dieser Basis werden Empfehlungen zur Auswahl eines geeigneten SoC (System on chip) und zur Nutzung von Caches auf einem Echtzeitsystem gegeben.

Verbesserung der Leistungsfähigkeit von Prozessoren durch speziellen Speicher

Bei der Betrachtung der Entwicklung von Prozessoren in Computern stand anfangs der Prozessor (Central Processing Unit = CPU) mit seinen Registern, der zur Verarbeitung Daten und Programminformationen aus einem direkt mit einem Bus verbundenen Speicher ausgelesen hat. Für synchronen Datenfluss war die Geschwindigkeit für den Datenaustausch mit dem Speicher gleich der Taktfrequenz, mit der ein Prozessor betrieben wurde. Um die Leistung von Prozessoren zu steigern, wurden die Strukturen immer weiter verkleinert, wodurch höhere Taktfrequenzen möglich wurden. Durch den Anstieg dieses Arbeitstaktes der CPU (= Taktfrequenz, CPU Frequenz) kann eine heutige CPU in einem vergleichbaren Zeitabschnitt eine deutlich größere Anzahl von Rechenschritten bearbeiten als noch vor einigen Jahren.

Damit daraus auch eine Beschleunigung für die Anwendung erfolgen kann, ist nicht nur eine Erhöhung der Rechengeschwindigkeit (hier: der Taktfrequenz des Prozessors) notwendig, auch die Bereitstellung der dazu benötigten Anweisungen in Form von Programmcode und die zu bearbeitenden Daten muss in vergleichbarer Weise eine Beschleunigung erfahren. Die erforderlichen Daten werden der CPU prinzipiell durch den Hauptspeicher zur Verfügung gestellt und sind über einen sogenannten Datenbus direkt mit der CPU verbunden. Dieser Hauptspeicher ist üblicherweise in relativ kostengünstigem dynamischen RAM (DRAM) ausgeführt. Zwar hat die Weiterentwicklung im Bereich der Fertigung von DRAM-Speicher über die Jahre auch zu einer Steigerung der Zugriffsgeschwindigkeiten geführt, jedoch nicht in dem Maße in dem Geschwindigkeitssteigerung bei den CPUs stattgefunden hat. Daher ist es entscheidend, Strategien zu entwickeln, die Speichernutzung so zu optimieren, dass mit der Steigerung der Prozessorgeschwindigkeit auch ein Geschwindigkeitsvorteil für eine gesamtes System entsteht.

Die Rolle von Caches

Um dies zu erreichen, haben moderne CPUs besonders schnelle Speicher (Cache) in unmittelbarer Nähe oder heute häufiger direkt als Bestandteil des Prozessors auf der CPU implementiert. Dadurch ist die Anbindung wegen der physikalischen Nähe technisch einfacher möglich. Hier fungiert der Cache als schneller, temporäre Speicher für häufig verwendete Daten oder Programmabschnitte. Dieser Speicher ist in der im Vergleich zu DRAM wesentlich schnelleren Technologie mit statischem RAM (SRAM) ausgeführt. Die Idee des Caches ist es, Daten oder Programmcode, die oft und wieder-holt in kurzer Zeit erneut benötigt werden, für sehr schnellen Zugriff zu speichern und bereit zu stellen. Um beispielsweise Berechnungen in einer Schleife wiederholt durchzuführen, kann der Programmcode jeweils immer wieder aus dem sehr viel schnelleren Cache gelesen werden und es muss kein langsamerer Zugriff auf den Hauptspeicher erfolgen. Aktueller Stand der Technik ist, dass sich der direkt an die CPU angebundene Cache aufteilt in Instruction-Cache (I-Cache), welcher Programmcode zwischenspeichert und Daten-Cache (D-Cache), in welchem Daten abgelegt werden können. Somit dient der Cache-Speicher als Beschleuniger für das Gesamtsystem, weil der Zugriff auf Daten oder Programmabschnitte erheblich zügiger erfolgen kann.

Folgende Berechnung zeigt den erheblichen Vorteil bei der Bearbeitungsgeschwindigkeit einer Schleifenfunktion anhand der Daten CPU BCM2711, die im Raspberry Pi 4 verwendet wird, auf:

Weitere Entwicklungen (z.B. kleinere Strukturen) der Prozessortechnologie haben zu steigenden Taktfrequenzen und damit zu einer höheren Prozessorleistung geführt. Um in dieser Situation weiter für eine schnelle Bereitstellung der Daten zu sorgen, war es aus ökonomischen Gründen nicht sinnvoll, die Größe des Caches immer weiter zu erhöhen. Neben Verbesserungen der Cache-Nutzung durch Prefetching (bei dieser Technologie versucht der Prozessor, Zugriffsmuster zu erkennen und basierend auf diesen Mustern vorherzusagen, welche Daten in naher Zukunft benötigt werden) haben sich weitere Ebenen des Caches etabliert (Cachelevel). Dazu werden zwischen der ersten Cacheebene (L1-Cache) und dem Hauptspeicher eine oder sogar zwei weitere Cacheebenen (L2, L3-Cache) eingeführt.

Diese sind von ihrem Speicherplatz meist größer als die erste Cache-Ebene ausgeführt und die Zugriffszeiten sind in der Regel etwas höher als die auf der ersten Cacheebene, jedoch noch deutlich unter den Zugriffszeiten auf den Hauptspeicher. Diese höheren Cache-Ebenen können - je nach CPU - von mehreren (meist zwei) Prozessorkernen gleichzeitig verwendet werden. Wenn die CPU Daten benötigt, kann Sie diese im schnellsten Fall aus der ersten Cache-Ebene (L1) lesen, falls diese dort nicht abgelegt sind, können sie nacheinander aus den weiteren Cache-Ebenen (L2,L3) angefragt werden. Erst wenn sie im Cache nicht gefunden werden, erfolgt der lesende Zugriff auf die geforderten Daten aus dem Hauptspeicher.

Das Management des Cache-Speichers und die Zugriffe darauf werden von der CPU gesteuert und sind daher aus Sicht von außen völlig transparent und damit auch nicht direkt beeinflussbar. Ausnahmen gibt es bei einigen Prozessoren, bei welchen die Cache-Nutzung deaktiviert werden kann.

Echtzeitsysteme

Echtzeitanwendungen müssen jederzeit ohne Interferenz durch andere Tasks auf einem Prozessor ablaufen. Da jedoch auch bei einem Echtzeitsystem verschiedene andere Tasks zur Laufzeit notwendig sind, versucht man diese Systeme durch unterschiedliche Maßnahmen so zu konfigurieren, dass die Echtzeitanwendung möglichst nicht beeinflusst wird. Eine häufig verwendete Maßnahme ist die sogenannte CPU-Isolation. Mit ihr kann störender Einfluss auf die Echtzeitanwendung durch andere, aktive Programme und Anwendungen sowie das sogenannte Housekeeping (Verwaltung und Systemmanagement) des Betriebssystems von bestimmten Kernen ferngehalten werden. Auf Linux Systemen erfolgt dies, indem ausgewählte CPU-Kerne schon beim Booten des Systems durch bestimmte Startparameter des Linuxkernels von den anderen CPU-Kernen isoliert werden. Die Echtzeitanwendung kann nun auf diesen vorkonfigurierten CPU-Kernen in der Folge weitgehend ohne störenden Einfluss ablaufen.

In einer Fallstudie konnten auf Systemen mit ARM-Architektur trotz solcher Maßnahmen zur Optimierung der Echtzeiteigenschaften und bei korrekter Systemkonfiguration unerwartet hohe Latenzen oder verlängerte Bearbeitungszeiten von Echtzeitanwendungen beobachtet werden. Dieses Verhalten wurde auf unterschiedlichen Embedded Systemen mit einer auf ARM-Architektur basierenden CPU untersucht.

Beschreibung der getesteten Systeme

In der folgenden Tabelle sind die Systeme aufgeführt, auf denen die Tests durchgeführt wurden. Es handelt sich um sieben unterschiedliche ARM-Systeme. Das System mit dem i.MX8QM hat zwei verschiedene Typen von CPU-Kernen, die gesondert gemessen wurden. Daher ist es mit zwei Zeilen in der Tabelle aufgeführt. Weiterhin wurden die Versuche auch auf einem System der relativ jungen RISC-V-Architektur durchgeführt.

Testablauf

Zur gezielten Überprüfung des Einflusses von gemeinsamer Cache-Nutzung auf das Echtzeitverhalten wird folgendes Testszenario auf den ausgewählten Systemen durchgeführt:

In einer ersten Messung wird die maximale Latenz während 3.600 Sekunden Laufzeit ohne zusätzliche Beeinflussung ermittelt, indem auf einem einzelnen CPU-Kern das Programm cyclictest gestartet wird (Quellcode unter https://www.kernel.org/kernel.org/pub/linux/utils/rt-tests/ verfügbar, in den meisten Distributionen direkt installierbar durch das Paket rt-tests). Dieses Programm steht in der Versuchsreihe als Repräsentant für eine Echtzeitanwendung. Durch die Aufrufparameter wird festgelegt:

• -l18.000.000 (Anzahl der Iterationen)

• -a[n] (der CPU-Kern)

• -m (Reservieren des gesamten, benötigten Speichers)

• -p99 (Festlegen der Priorität als Echtzeitanwendung)

• -i200 (Zeitintervall 200 µs)

Die Laufzeit von 3.600 Sekunden ist festgelegt durch das Produkt aus den Iterationen l=1.8x10⁷ mit dem Zeitintervall i=2x10^-4. Aus den gemessenen Daten wird ein Histogramm erzeugt, dass die ermittelten Werte graphisch darstellt und eine schnelle Erfassung des Echtzeitverhaltens während des Messzeitraums ermöglicht.

Nach Abschluss dieser ersten Messphase erfolgt eine Pause von 300 Sekunden.

Anschließend wird erneut die Ermittlung der Latenzen mit cyclictest für eine Stunde auf dem gleichen CPU-Kern gestartet. Gleichzeitig wird auf allen anderen CPU-Kernen das Programm stress-ng (Quellcode auf GitHub unter https://github.com/ColinIanKing/stress-ng) gestartet. Mit diesem Programm wird auf dem zu testendes System ein spezifisches Lastszenario erzeugt, was zu dieser Messphase zu einer extremen Nutzung des Caches auf diesen CPU-Kernen führt.

Die Abbildung zeigt schematisch die Messung auf einer CPU mit 4 Prozessorkernen, bei denen auf den Kernen #0-#2 die Last für den Cache generiert wird und gleichzeitig auf Kern #3 die Latenzmessung stattfindet. Hier ist die Cache-Ebene L2 und L3 auf der CPU angeordnet und wird von allen Kernen gemeinsam verwendet.

Ergebnisse

Als Ergebnis der oben beschriebenen Messungen werden bei jeder Messphase die Latenzen in Tabellenform abgelegt und daraus ein Histogramm erzeugt. In dieser Darstellung sind – neben den Daten als Histogramm – wichtige Parameter die Messung betreffend eingetragen. Damit können zur Auswertung die erzeugten Histogramme von den verschiedenen Lastphasen (keine oder extreme Cache-Auslastung) bzw. unterschiedlicher Systemkonfigurationen (CPU-Kern mit/ohne Isolation) gegenübergestellt und verglichen werden.

Um die ermittelten Latenzen vergleichen und einordnen zu können, kann aus den regelmäßig in der OSADL-QA-Farm durchgeführten und ausgewerteten Langzeitmessungen ein Latenzmaximum vom Betrieb unter mittlere Last ( ~ 50% Systemlast durch Speicher-, Laufwerk- und Netzwerkoperationen) des betreffenden Systems herangezogen werden. Diese Langzeitaufzeichnungen sind für alle Systeme dieses Tests vorhanden

Bei der Darstellung der Ergebnisse wurden zu jedem System nochmals die Architekturen von CPU und Caches graphisch dargestellt. Weiterhin wurden die maximalen Latenzen als Vergleichswert eingetragen, die bis jetzt durch die Langzeitermittlung der Latenzen mit moderater Last gemessen wurden. Als Ergebnis des Messprogramms zur Ermittlung des Einflusses von Cache-Belastung auf das Echtzeitverhalten sind jeweils die Latenzhistogramme einer spezifischen CPU sowohl ohne als auch mit Cache-Belastung abgebildet. Die Messungen wurden teilweise mit isoliertem CPU-Kern durchgeführt. Dies ist jeweils vermerkt.

Zu 1.(i.MX6 Quad @996 MHz):

Hier liegen die Langzeitwerte der maximalen Latenzen bei etwa 170 µs. Das System generiert ohne Last Maxima von 113 µs, bei hoher Cache-Auslastung liegt der Höchstwert bei 140 µs. Das System zeigt trotz extremer Beanspruchung des Cache-Speichers einen vergleichsweise geringen Einfluss auf die maximalen Latenzen.

Zu 2.(i.MX8M Plus @1600 MHz):

Das System zeigt ohne Cache-Belastung mit einer höchsten Latenz von 64 µs ein erwartbares Echtzeitverhalten, in der Langzeitaufzeichnung liegt die maximale Latenz bei etwa 110 µs. Durch extreme Cache-Belastung werden höhere Latenzen ausgelöst, die hier etwa 160 µs erreichen. Als Ursache für die höheren Messwerte kann der relativ kleine L2-Cache in Betracht gezogen werden, da dieser von allen CPU-Kernen gemeinsam verwendet wird.

Zu 3.(i.MX 93 @1700 MHz):

Diese Zweikern-CPU zeigt in der Langzeitaufzeichnung bisher maximale Latenzen von etwa 180 µs. Bei der Messung ohne Belastung sind die höchsten Messwerte mit 133 µs etwas niedriger. Selbst bei extremer Cache-Auslastung sind die Messwerte mit 183 µs maximal kaum größer als bei Maxima der Langzeitaufzeichnungen. Da dieses System jede Cache-Ebene für jeden CPU-Kern extra zur Verfügung hat, ist der Einfluss extremer Cache-Auslastung nur in sehr geringem Maß vorhanden.

Zu 4.(BCM2711 @1500 MHz/Raspberry Pi 4):

Bei den Daten der Langzeitaufzeichnung sind die zu erwartenden Maximallatenzen bei etwa 140 µs. Ohne einen CPU-Kern für Echtzeitanwendung zu isolieren zeigt sich bei dieser Messung ein Maximum von 106 µs ohne Belastung. Mit Cache-Belastung tritt eine signifikante Verschlechterung auf, hier liegt der höchste Wert bei 361 µs.

Eine deutliche Änderung wird durch Isolation eines CPU-Kerns für die Echtzeitanwendung sichtbar. Hier wird ohne Last ein Maximum von 68 µs erreicht, mit dem Lastszenario sind die höchsten Messwerte mit 133 µs etwas niedriger. Hier teilen sich alle CPU-Kerne die zweite Cache-Ebene, wodurch sich sowohl ohne als auch mit CPU-Isolation die Maximallatenzen bei extremer Cache-Auslastung klar verschlechtern. Bemerkenswert ist der positive Einfluss auf das Echtzeitverhalten, der mittels Isolation der Echtzeitanwendung auf einem CPU-Kern erreicht wird.

Zu 5.(i.MX8QM @1300 MHz):

Bei dieser Architektur sind zwei unterschiedliche Architekturen der ARM-Familie in einem Chip vereint. Ein Cluster (CPU 0-3) besteht aus vier Cortex-A53 Kernen, das andere (CPU 4-5) beherbergt zwei Cortex-A72 Kerne. Die CPU-Kerne letzteren Clusters sind im System isoliert.

Das Gesamtsystem zeigt während der Langzeitaufzeichnung maximale Latenzen von etwa 250 µs. Die Messung auf den nicht isolierten Kernen zeigte ohne Last ein Maximum von 152 µs. Bei der Auslastung des Caches treten Höchstwerte von 4027 µs auf, bei den isolierten Kerne treten Maximalwerte von 104 µs ohne Last und wiederum sehr hohe Latenzen von 4177 µs auf.

Die zwei Cluster haben jeweils getrennte Bereiche für Cache, die Größe des Caches unterscheidet sich. In den Histogrammen wird ein deutlicher Einfluss der Cache-Belastung erkenntlich. Die in diesem Messzyklus ungewöhnlich hohen Werte bei Cache-Belastung weisen auf ungünstiges Echtzeitverhalten bei extremer Auslastung hin.

Zu 6.(AM69x @2000 MHz ):

In den Langzeitaufzeichnungen zeigen sich Latenzen von 70 µs. Die Ergebnisse der Messung ohne Cache-Auslastung liegen bei 32 µs, bei Auslastung des Cache-Speichers tritt ein Maximum von 119 µs auf.

Das System hat je vier Kerne auf zwei Clustern verteilt, jedes Cluster hat eine gemeinsame zweite Cache-Ebene. Der Einfluss bei Last im Cache-Speicher zeigt sich bei diesem System auch bei ansonsten guten Echtzeiteigenschaften.

Zu 7.(BCM2712 @2400 MHz/Raspberry Pi 5):

Hier tritt in der Langzeitaufzeichnung ein Maximum von etwa 120 µs auf, die Ergebnisse ohne Isolation liegen bei 60 µs und 178 µs mit Cache-Auslastung. Bei den Messungen im isolierten Betrieb ist die Maximale Latenz annähend gleich bei 33 µs ohne zu 36 µs mit Cache-Auslastung. Die Verteilung der aufgetretenen Latenzen Histogramms zeigt insgesamt geringfügig erhöhte Latenzen im Gesamtverlauf bei extremer Cache-Auslastung.

Das System ist hat neben zwei Cache-Ebenen L1 und L2 pro CPU-Kern eine dritte, von allen Kernen gemeinsam genutzte Cache-Ebene L3.

Hier zeigt sich deutlich der Vorteil der Architektur von dedizierten Caches L1 und L2 und einem dritten, geteilten Cachelevel L3, da beim isolierten Betrieb der Echtzeitanwendung selbst extremer Cache-Auslastung einen unwesentlichen Einfluss auf das Echtzeitverhalten hat.

Zu 8.(VisionFive 2 @1500MHz):

Die Messungen der Langzeitaufzeichnung weisen eine maximale Latenz von etwa 120µs auf. Bei der Messung mit und ohne zusätzliche Cache-Auslastung trete ohne CPU-Isolation Latenzen von 58 µs bzw. 78 µs auf. Bei isoliertem Kern für Echtzeitanwendung treten bei den Messungen Maxima von 40 µs bzw. 56 µs auf.

Das System hat pro Kern die erste Cache-Ebene L1, während L2 gemeinsam von allen Kernen genutzt wird. Dies ist als Ausnahme das einzige System mit RISC-V-Architektur. Es zeigt einen nur geringen Einfluss bei den Messungen mit extremer Cache-Auslastung, die Isolation des Kerns für Echtzeitaufgaben führt zu einer Verbesserung des Echtzeitverhaltens.

Fazit

Die Messungen zeigen, dass es bei der Auswahl eines CPU-Designs für Echtzeitanwendungen notwendig ist, nicht nur die reine Rechenleistung einer CPU zur Beurteilung der Leistungsfähigkeit heranzuziehen. Einen erheblichen Einfluss auf die Echtzeiteigenschaften hat die Auslegung des Caches in einem System. Bei ARM-Systemen gibt es eine Vielzahl von verschiedenen Möglichkeiten, ob der Cache mit einem bzw. mehreren CPU-Kernen angebunden ist. Häufig teilen sich mehrere Kerne verschiedene Cache-Instanzen. Das Management dieses Speichers im Zusammenspiel mit unterschiedlichen Cache-Levels, dem Hauptspeicher und der CPU ist höchst komplex und wird allein durch den Prozessor gesteuert. Bei vielen ARM-Systemen ist das Deaktivieren des Caches designbedingt nicht möglich (und aus Gründen der Performance auch nicht sinnvoll). Somit ist die Einflussnahme auf das Verhalten einer modernen CPU kaum möglich, womit die Wichtigkeit bei der Auswahl einer CPU für Echtzeit-aufgaben noch deutlicher wird. Vielmehr zeigt sich, dass es für die besonderen Herausforderungen im Echtzeitkontext (Determinismus!) dringend geboten ist, welche direkt mit der CPU verbundenen Komponenten zu analysieren und im Vorfeld abzuwägen, wo Engpässe entstehen können, die die Echtzeiteigenschaften eines Systems negativ beeinflussen können. Die Anforderungen in Bezug auf die maximalen Latenzen (inklusive Sicherheitsaufschlag) einer echtzeitpflichtigen Anwendung müssen bereits zum Projektstart festgelegt sein. Anhand dieser Daten sollte dann auf einer entsprechenden Plattform das Echtzeitverhalten analysiert und ermittelt werden. (sg)

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

* Alexander Bähr arbeitet seit 2020 als technischer Informatiker bei der Open Source Automation Development Lab (OSADL) eG, wo er unter anderem die OSADL QA-Farm betreut.

(ID:50496903)