Ein Aufwand für das Ausführen von Programmen unter Linux im Vergleich zu eingebettetem Bare-Metal

Nehmen wir an, ich habe einen Multi-Core-ARM Cortex-A.

Jetzt habe ich dort ein Linux, mit RT_PREEMPT- Patch (sog. Echtzeit-Linux ). Ich führe einen Prozess mit Affinität auf einen Kern und hoher Priorität (über 50) aus.

Dank Echtzeit-Patch kann sogar der Kernel-Scheduler meinen Prozess nicht unterbrechen, und dank Affinität kann er die ganze Zeit auf einem einzelnen Kern (und Betriebssystem auf anderen) laufen.

Gibt es unter solchen Bedingungen einen Unterschied (dh Overhead) zwischen der Ausführung eines solchen Codes unter Linux und Bare-Metal?
Wird die Leistung gleich sein? Wenn nicht, warum?

Nun, wäre der Overhead nicht immer noch das gesamte Betriebssystem mit all seinen High-Level-Treibern und allem?
@Rev1.0 nein, es sei denn, Sie können nachweisen, dass diese Treiber a) verwendet werden und b) erheblich weniger effizient sind als ein tatsächlich vorhandener Treiber, der in einer Bare-Bone-Implementierung verwendet wird.

Antworten (1)

Overhead bezieht sich nicht auf Vorkaufsrecht. Preemption stoppt Ihren Prozess und führt einen anderen Prozess aus. Wenn Sie das zB für einen CPU-Kern deaktivieren, haben Sie nur noch den CPU-Kern für Ihren Prozess.

Dennoch gibt es einen Overhead, wenn Sie E/A über die Linux-E/A-Funktionen ausführen, anstatt z. B. die E/A-Leitungen direkt über Ihren Prozess zu steuern. Aber für jede einigermaßen komplizierte I/O mussten Sie selbst eine Funktion mit ähnlichem Aufwand implementieren, und Sie können davon ausgehen, dass die Linux-Leute darin besser sind als Sie – mehr Erfahrung und mehr Testfälle.

Die einzige Möglichkeit, das Overhead-Rennen zu gewinnen, besteht also darin, mit sehr einfachen I/O-Funktionen (z. B. Bitbangen eines exotischen, schnellen Protokolls) selbst in "Ihrem Kernel" zu implementieren, anstatt es durch die verschiedenen Abstraktionsschichten des Linux-GPIO-Subsystems laufen zu lassen und machen Sie dasselbe in "Ihrem Userspace-Prozess".

Vielen Dank. Ich bekomme das viel zu oft: "Aber die Kernel-Abstraktion macht die Dinge langsam!" und die ehrliche Wahrheit ist, dass Sie wahrscheinlich so ziemlich dasselbe wie der Kernel tun möchten, wenn Ihre Verwendung eines Geräts ausreichend komplex ist. Und in diesem Fall ist das Schreiben Ihres eigenen Kernel-Space-Codes normalerweise der einfachere Weg zum Erfolg. Ihre Antwort ist also sehr gut für meine gequälte Seele.
Die Leute fühlen sich manchmal unsicher, weil die Verwendung des GPIO-Subsystems etwa 20-mal länger dauert als eine einzelne Out- Anweisung. Das stimmt, aber wer macht das für zeitkritische Dinge? Wenn Sie Dinge so schnell herausschieben müssen, denken Sie an DMA und erledigen Sie es viel, viel schneller.
Exakt. Bei praktisch allen ARM-Prozessoren ist die gesamte E/A speicherzugeordnet, sodass es buchstäblich keinen Kernel-Overhead gibt, wenn Sie nur diesen Speicher in Ihrem Prozessbereich abbilden.
Ja, ich habe vergessen zu erwähnen, dass ich genau den gleichen C-Code Bare-Metal im Vergleich zu Linux meine . Selbst wenn Sie Linux verwenden, meine ich damit nicht, irgendetwas zu verwenden, das von Linux kommt (Treiber, Systemaufrufe usw.). Nur reines C. Ich verstehe also, dass es dann keinen Overhead für die Verwendung von Linux gibt? Ich habe mich zum Beispiel über die Tatsache gewundert, dass Linux virtuellen Speicher verwendet (während Bare-Metal direkte Adressen verwendet). Wenn ich einige Variablen deklariere, haben sie unter Linux eine virtuelle Speicheradresse. Es gibt keinen Overhead für die Übersetzung einer virtuellen Adresse in eine physische? Einige Paging usw.?
Die MMU ist ein Stück Hardware, und es ist die Geschwindigkeit des RAM. Sie haben immer virtuelle Adressen in Ihrem Programm, die MMU nicht zu verwenden bedeutet einfach, dass beim Systemstart nur eine feste Zuordnungstabelle geladen wird. Wenn Sie das Paging für eine Seite oder einen Prozess deaktivieren möchten, können Sie den Kernel anweisen, die Mappings für Ihren Prozess mit mlock() und mlockall() als nicht-pageable zu markieren.
Danke @Janka, das ist interessant. So kann ich Paging deaktivieren. Aber hat das Paging irgendeinen Overhead? Ich meine, wenn ich Paging deaktiviere, wird es dann auch nur geringfügig schneller? Oder ist MMU komplett Hardware und es spielt keine Rolle?
Paging hat einen Overhead, sobald die Summe des Speichers, der von allen Programmen auf dem System verwendet wird, größer ist als der physische Arbeitsspeicher, über den das System verfügt. Denn dann würde der Kernel selten genutzte Seiten auf Festplatte oder Flash-Speicher ablegen, was auch immer als Swapspace installiert ist. Werden sie wieder benötigt, müssen sie neu ins RAM eingelesen werden. mlock() und mlockall() weisen den Kernel an, dies nicht mit einigen/irgendwelchen Seiten zu tun, die Ihr Prozess benötigt. Diese Seiten befinden sich also immer im RAM und müssen nie aus dem Swapspace wiederhergestellt werden.
Ein Aufwand für das Ausführen von Programmen unter Linux im Vergleich zu eingebettetem Bare-Metal
AntwortenHierDatenschutz-Bestimmungen1y, 0v