Schwerpunkte

Software-Entwicklung

Embedded-Linux-Systeme tracen – Teil 3

27. Januar 2021, 08:30 Uhr   |  von Mohammed Billoo


Fortsetzung des Artikels von Teil 1 .

Belastung der CPU messen

Obwohl also iperf die Anweisung bekommen hat, ausschließlich auf CPU3 zu laufen, hat irgendetwas dazu geführt, dass es ebenfalls auf anderen CPUs lief. Tatsächlich ist das nicht ungewöhnlich, denn Anwendungen können ihre eigene Logik implementieren, um die richtige CPU für ihre Ausführung auszuwählen. Offensichtlich ist eine solche Logik ebenso in iperf umgesetzt.

eth0-Interrupthandler
© Percepio

Bild 4. Es gibt eine Korrelation zwischen der Zeitspanne, in der der eth0-Interrupthandler verarbeitet wird und jener, in der die iperf-Instanz ausgeführt wird.

Verringert der Anwender den Zoomfaktor beim Betrachten des Trace, ist eine Vielzahl von Verarbeitungsinstanzen des eth0-Interrupthandlers zu erkennen, die etwa zur gleichen Zeit wie das iperf-Experiment ausgeführt werden. Hieraus lässt sich der Schluss ziehen, dass es eine Korrelation gibt zwischen der Zeitspanne, in der der eth0-Interrupthandler verarbeitet wird und jener, in der die iperf-Instanz ausgeführt wird (Bild 4).

Mitte des Trace
© Percepio

Bild 5. Die Mitte des Trace in vergrößerter Form.

Betrachtet man die Mitte des Trace in vergrößerter Form (Bild 5), kann man die eigentliche Durchsatzmessung genauer ansehen und wird nicht von protokollspezifischen Transaktionen zwischen iperf-Server und iperf-Client abgelenkt. Hierbei zeichnet sich ein bestimmtes Muster ab.

Erhöht man den Zoomfaktor noch weiter und misst die Zeit zwischen dem Moment, in dem der eth0-IRQ-Handler seine Verarbeitung abgeschlossen hat, und dem Beginn der iperf-Verarbeitung, so ist das Resultat etwa 55 µs (Bild 6).

Messung
© Percepio

Bild 6. Die Zeit zwischen dem Moment, in dem der eth0-IRQ-Handler seine Verarbeitung abgeschlossen hat, und dem Beginn der iperf-Verarbeitung, ist etwa 55 µs.

Klickt man anschließend auf die betreffende iperf-Verarbeitungsinstanz und danach auf das Pluszeichen neben »Instance« in der Ansicht »Selection Details«, so sieht man, dass diese Instanz wie vorgesehen auf CPU3 läuft (Bild 7).

Bekannt ist also, dass zwischen dem Beenden des eth0-Interrupthandlers und dem Zeitpunkt, zu dem das Verarbeiten der iperf-Instanz beginnt, 55 µs vergehen. Als nächstes ist das System zu belasten, indem in das Terminal des Jetson Nano der folgende Befehl einzugeben ist, der 20 Prozesse auf allen CPUs laufen lässt:

$> stress --cpu 20

Instanz
© Percepio

Bild 7. Es ist zu sehen, dass diese Instanz wie vorgesehen auf CPU3 läuft.

Mit dem top-Befehl lässt sich zeigen, dass alle vier Prozessorkerne tatsächlich mit maximaler Leistung arbeiten (Bild 8). Eine erneute iperf-Messung lässt erkennen, dass der Durchsatz nach wie vor 851 MBit/s beträgt.

$> iperf -b1G -c 192.168.2.247 -p5001
[  3]  0.0-10.0 sec  1.10 GBytes   851 Mbits/sec

top-Befehl
© Percepio

Bild 8. Mit dem top-Befehl lässt sich zeigen, dass alle vier Prozessorkerne tatsächlich mit maximaler Leistung arbeiten.

Jetzt ist Tracealyzer mit einem Capture zu öffnen, der während des bewusst herbeigeführten Belastens der CPU-Kerne aufgenommen wurde. Anschließend zoomt man in die Mitte des Captures hinein, um die Verarbeitungsabfolge des eth0-Interrupthandlers und der iperf-Instanz zu betrachten. Wie zu sehen ist, vergehen zwischen dem Beenden des Verarbeitens des eth0-Interrupthandlers und dem Beginn der iperf-Verarbeitung jetzt etwa 40 µs (Bild 9).

Beginn der iperf-Verarbeitung
© Percepio

Bild 9. Zwischen dem Beenden des Verarbeitens des eth0-Interrupthandlers und dem Beginn der iperf-Verarbeitung vergehen jetzt etwa 40 µs.

Die absolute Höhe des Werts ist nicht wichtig, selbst wenn es interessant ist, dass die Zeit beim Belasten kürzer ist. Relevant ist vielmehr, dass die Zeitspanne bei belastetem und unbelastetem System dieselbe Größenordnung hat, nämlich 40 beziehungsweise 55 µs. Das stellt ein herausragendes Merkmal des Linux-Kernels dar, denn selbst wenn eine Userspace-Anwendung scheinbar alle vier Kerne des Systems belegt, ist nach wie vor gewährt, dass den anderen Userspace-Anwendungen nicht die CPU-Ressourcen ausgehen und dass die Kommunikation zwischen den Cores nicht beeinträchtigt wird. Geht man einen Schritt zurück, so sind sämtliche Prozesse der »Stress«-Anwendung (Bild 10) zu erkennen, was bestätigt, dass die CPU in der Tat stark belastet wird.

»Stress«-Anwendung
© Percepio

Bild 10. Geht man einen Schritt zurück, so sind sämtliche Prozesse der »Stress«-Anwendung zu erkennen, was bestätigt, dass die CPU in der Tat stark belastet wird.

Linux-Kernel teilt Leistung auf

Um noch einmal zusammenzufassen: In dem soeben beschriebenen Projekt wurde Tracealyzer genutzt, um eine Vermutung zu überprüfen, welche sich auf die Folgen bezog, die das Festlegen der CPU-Affinität eines Prozesses auf seine Leistungsfähigkeit hat. Die Vergleichsanalyse der Interaktionen zwischen den verschiedenen Verarbeitungselementen unter normalen Bedingungen gegenüber hoher Belastung brachte eine attraktive Eigenschaft des Linux-Kernels ans Licht. Er nämlich setzt alles daran, sämtlichen Prozessen einen gerechten Anteil an den CPU-Ressourcen zu geben. Anschließend wurde noch einmal genauer hingesehen, um herauszufinden, weshalb die ursprüngliche Vermutung – nämlich, dass das Einstellen der CPU-Affinität eines Prozesses auf das Verarbeiten von Paketen die Paketverluste reduziert – falsch war. Da die Analyse nicht vollständig und abschließend war, wurden noch andere Bereiche identifiziert, die ein weitergehendes Betrachten nötig machen, wie etwa der Scheduler des Linux-Kernels und die iperf-Codebasis.

Das ist der dritte Artikel einer Serie von Beiträgen über den Einsatz von Tracealyzer zum Erfassen und Analysieren von Traces von Embedded-Linux-Systemen.

Mohammed Billoo
© Percepio

Mohammed Billoo ist Gründer von MAB Labs, LLC, einem Anbieter kundenspezifischer Embedded-Linux-Anwendungen.

Der Autor

Mohammed Billoo ist Gründer von MAB Labs, LLC, einem Anbieter kundenspezifischer Embedded-Linux-Anwendungen für eine Vielzahl von Hardware-Plattformen. Billoo verfügt über einen Master in Elektrotechnik und mehr als 12 Jahre Erfahrung in Design, Implementierung und Test von Embedded-Software. Er trägt aktiv zum Linux-Kernel sowie zahlreichen Open-Source-Bemühungen bei und unterrichtet zudem als außerordentlicher Professor für Elektrotechnik an der Cooper Union for the Advancement of Science and Art.

Seite 2 von 2

1. Embedded-Linux-Systeme tracen – Teil 3
2. Belastung der CPU messen

Auf Facebook teilen Auf Twitter teilen Auf Linkedin teilen Via Mail teilen

Das könnte Sie auch interessieren

Verwandte Artikel

Percepio AB