Startseite > Embedded > Software > Embedded-Linux-Systeme tracen – Teil 1

Software-Entwicklung

Embedded-Linux-Systeme tracen – Teil 1

26. Oktober 2020, 9:23 Uhr | Autor: Mohammed Billoo, Redaktion: Tobias Schlichtmeier

▶ Diesen Artikel anhören

Fortsetzung des Artikels von Teil 1

Die wichtigsten Ansichten in dieser Phase

Nach dem Starten von Tracealyzer ist »File->Open Folder« auszuwählen sowie der Ordner »lttng-traces«. Tracealyzer analysiert den Ordner nach der erfassten Trace-Sitzung und lädt sämtliche zugehörigen Dateien (ein LTTng-Trace besteht stets aus mehreren Files). Anschließend kann die passende Ansicht gewählt werden, um die Leistungsfähigkeit des Treibers zu analysieren.

Jobangebote+ passend zum Thema

MACNICA ATD EUROPE - Ihre berufliche Zukunft

MACNICA ATD Europe GmbH, Ingolstadt

Alle Jobangebote im Elektroniknet Karrierebereich anzeigen

Tracealyzer bietet Ansichten, die nützliche Einblicke in die Interaktion zwischen Userspace und Kernel liefern. Das Hauptaugenmerk gilt jedoch dem Kernel-Space und somit den Ansichten »Trace View«, »Actor Instances«, »CPU Load Graph« und »Context Switch Intensity«. Auswählen lassen sich diese Ansichten, indem man die jeweiligen Icons in der linken Leiste des Hauptfensters von Tracealyzer anklickt (Bild 2).

Wird die Ansicht »Trace View« geöffnet, erhält der Anwender folgendes Diagramm (Bild 3). In der linken Spalte (Actor Names) ist angegeben, welche Userspace- und Kernel-Prozesse beziehungsweise Threads zum jeweiligen Zeitpunkt ausgeführt werden. Die ganz linke Spalte in der rechten Hälfte (grau-kariert) ist der Kernel-»Swapper«, bei dem es sich um die im Leerlauf befindliche Task des Linux-Kernels handelt. Weiter rechts erkennt man als blaue Linie den Kernel-Thread (»kworker«). Implementiert der Entwickler den Treiber um seine Leistung mit Tracealyzer zu überwachen, nutzt er Trace View, um zu verifizieren, dass dem Kernel-Thread genügend Verarbeitungs-Ressourcen zum Managen des DMA-Transfers zur Verfügung gestellt werden. Geht man noch weiter nach rechts, ist der lttng-Userspace-Prozess in grün dargestellt und schließlich in gelb der Userspace-Prozess rcu_sched. Leider kann hier nicht genauer auf rcu_sched eingegangen werden, aber eine gute Basis bietet der Artikel auf kernel.org. [7]

Wird das Fenster mit der rechten Maustaste angeklickt und der Menüpunkt »Zoom Out – Show Full Traces« ausgewählt, erhält man einen Überblick über sämtliche Threads und Prozesse, die während der gesamten Dauer der Erfassung ausgeführt wurden, dargestellt in Bild 4.

Erkennbar ist hier, dass der Swapper während der gesamten Zeitspanne die meisten Verarbeitungs-Ressourcen belegt. Es ist durchaus schlüssig, denn schließlich wird zurzeit noch keine entscheidende Aufgabe ausgeführt. Läuft dagegen der Treiber erst einmal und transferiert Daten vom Gerät an das Phytec Development Board, ist zu erwarten, dass größere Abschnitte des Trace-Views mit blauen Fragmenten belegt sind. Das würde darauf hindeuten, dass dem spezifischen Kernel-Thread zur Ausführung der Transfers ein größerer Teil der Verarbeitungs-Ressourcen der Plattform zugewiesen wird.

Die nächste wichtige Ansicht trägt die Bezeichnung »Actor Instances«, bei der im Dropdown-Menü oben rechts die Option »Execution Time« zu wählen ist (Bild 5).

Die y-Achse gibt an, wieviel Zeit von jedem einzelnen »Actor«, also einem Verarbeitungselement, wie etwa einem Thread oder Prozess, beansprucht wird. Wählt man nun einen der Kernel-Threads aus, so ist zu erkennen, dass die Verarbeitungszeit einige Spitzen aufweist. Ebenso ist zu erkennen, dass diese Spitzen etwa 350, 450 und 550 Mikrosekunden betragen. Um beurteilen zu können, ob das von Belang ist, muss man entweder die Timing-Anforderungen des Systems kennen oder evaluieren, wie das System unter »normalen« Bedingungen arbeitet.

Da keine Anforderungen vorliegen, kann jeder selbst schlussfolgern, ob die Spitzen ein Problem sind. Hierfür ist eine weitere Ansicht zu nutzen. Wählt man einen anderen Kernel-Thread aus, so sieht man den folgenden abnormalen Graphen in Bild 6. Hier ist eine relativ große Spitze in der Verarbeitungszeit des Kernel-Threads. Ebenso ist hier die weitere Ansicht zu nutzen, um zu ermitteln, ob das Anlass zu Bedenken gibt.

Die vorhin erwähnte weitere Ansicht »CPU Load Graph« gibt Auskunft über die CPU-Auslastung der verschiedenen Aktoren – der entsprechende Graph sieht wie folgt aus (Bild 7). Wie man sieht, waren Bedenken nicht angebracht, denn die CPU-Auslastung über beide Kernel-Threads war zu keinem Zeitpunkt größer als 1,1 Prozent. Was also im »Actor Instance«-Graphen zu sehen war, war einfach eine Spitze in der Ausführungszeit des grünen Kernel-Threads bezogen auf den blauen Kernel-Thread.

In dem Zusammenhang ist es wichtig zu wissen, dass Tracealyzer die y-Achse standardmäßig so einteilt, dass eine deutliche Präsentation der Daten erfolgt. Also endet die y-Achse nicht bei 100 Prozent (dann würde man nämlich nicht sehr viel sehen). Wird im CPU-Load-Graph der Aktor »lttng-sessiond« ausgewählt, ist folgende Darstellung (Bild 8) zu sehen.

Prozent auslastet (Tracealyzer hat auch hier die y-Achse so skaliert, dass eine aussagefähige Darstellung entsteht). Die beträchtliche Auslastung war zu erwarten, da der lttng Userspace Daemon die notwendigen Initialisierungen zum Erfassen der Traces vornehmen muss. Hinzu kommt, dass ansonsten nicht viel vor sich geht, was um die CPU-Zeit konkurrieren könnte. Zu Vergleichszwecken kann zusätzlich die CPU-Auslastung der Kernel-Threads betrachtet werden.

Als letztes folgt die Ansicht »Context Switch Intensity«, mit der validiert werden kann, dass der Kernel-Treiber funktioniert und keinen Absturz des Kernels provoziert. In Bild 9 ist die Ansicht dargestellt. Man sieht, dass kein bestimmter Kernel-Thread deutlich mehr Kontextwechsel verursacht als ein anderer. Wäre im verwendeten Treiber ein Performance-Problem aufgetaucht, wären möglicherweise übermäßig viele Kontextwechsel des Kernel-Threads zu erkennen gewesen. Dann hätte der Kernel-Scheduler dem Kernel-Thread Verarbeitungszeit zugewiesen, wäre nach einiger Zeit zu einem anderen Thread gewechselt jedoch anschließend sofort zurück zum Kernel-Thread, wenn er weitere Ressourcen angefordert hätte. Ob die ungefähr 20 Kontextwechsel, die aus dem obigen Diagramm hervorgehen, angemessen sind, hängt entweder von den Systemanforderungen oder von einem Vergleich mit Messungen ab, die bei »normaler« Funktion des Systems gemacht wurden.

Embedded-Linux-Systeme tracen – Teil 1
Die wichtigsten Ansichten in dieser Phase
Lokalisieren von »Hotspots« oder Anomalien

Online-Kompendium