Echtzeitfähigkeit von Linux-Systemen empirisch bestimmen

Echtzeitfähigkeit von Linux-Systemen empirisch bestimmen

Es stehen vier verschiedene Histogramme zur Verfügung, wobei die Daten für jeden Prozessor bzw. für jeden Prozessorkern oder bei Hyperthreading-Systemen für jeden Hyperthread getrennt abrufbar sind:

• Wakup-Latency: eingeschaltet, wenn die entsprechende Konfigurationsoption (Beispiel 7) konfiguriert ist. Der Dateiname der Daten der ersten CPU lautet: »/sys/kernel/debug/tracing/ latency_hist/wakeup_latency/ CPU0«.
• IRQ-off-Latency: eingeschaltet, wenn die entsprechende Konfigurationsoption (Beispiel 8) konfiguriert ist. Der Dateiname der Daten der ersten CPU lautet: »/sys/kernel/debug/tracing/ latency_hist/interrupt_off_latency/ CPU0«.
• Preemption-off-Latency: eingeschaltet, wenn die entsprechende Konfigurationsoption (Beispiel 9) konfiguriert ist. Der Dateiname der Daten der ersten CPU lautet: »/sys/kernel/debug/tracing/latency_ hist/preempt_off_latency/ CPU0«.
• IRQ-und-Preemption-off-Latency: eingeschaltet, wenn die beiden Konfigurationen IRQ-off-Latency und Preemption-off-Latency konfiguriert sind. Der Dateiname der Daten der ersten CPU lautet: »/sys/kernel/debug/tracing/ latency_hist/preempt_interrupts_ off_latency/CPU0«.

Jobangebote+ passend zum Thema

MACNICA ATD EUROPE - Ihre berufliche Zukunft

MACNICA ATD Europe GmbH, Ingolstadt

---

Alle Jobangebote im Elektroniknet Karrierebereich anzeigen

Die Zeitwerte des Wakeup-Histogramms entsprechen der Dauer zwischen der Aufnahme eines zu aktivierenden Prozesses in die Warteschleife und dessen tatsächlichem Ausführungsbeginn. Normalerweise sollten diese Messwerte also mit den Messergebnissen des Programms »cyclictest« übereinstimmen, wenn die Messung mit »cyclictest« über eine genügend lange Messdauer lief. Die anderen Histogramme enthalten jeweils die Dauer einzelner Kernel-Ausführungspfade, in denen Preemption, Interrupts oder beide abgeschaltet sind. Form und Werte dieser Histogramme können im Einzelfall wichtige Hinweise liefern, wo Latenzen entstanden sein mögen, wenn ein Prüfling kein zufriedenstellendes Echtzeitverhalten aufweist.

Als Nachteil der Histogramm-Messungen darf nicht unerwähnt bleiben, dass diese natürlich ihrerseits einen gewissen – wenn auch relativ geringen – Beitrag zur Latenz leisten. Daher ist mit einer Verschlechterung des Echtzeitverhaltens um, je nach Prozessortakt, einige Mikrosekunden zu rechnen. Auf der anderen Seite hat diese eingebaute Messung aber den unschätzbaren Vorteil, dass sie nicht nur eine bestimmte Auswahl an künstlichen Messprozessen schafft und misst, sondern jeden einzelnen Vorgang (Scheduling und Abschaltung von Interrupts beziehungsweise Preemption) erfasst, es also keinen Messfehler im Sinne einer zu optimistischen Schätzung gibt. Ähnlich wie bei der Messung mit der »OSADL-Latency-Box« stehen allerdings auch bei den internen Histogrammen keine Informationen über den Zeitpunkt der gemessenen Latenz und der dabei ausgeführten Kernelfunktionen zur Verfügung. Bei zu hohen gemessenen Latenzwerten muss auch hier im Anschluss eine spezielle Messung mit Funktions-Tracing zur weiteren Diagnose erfolgen.

Vor Beginn einer definitiven Messung sind alle Histogrammzähler auf »0« zu setzen. Für diesen Zweck ist die virtuelle Datei »reset« in den jeweiligen Verzeichnissen vorgesehen. Das Zurücksetzen erfolgt zum Beispiel mit dem in Codebeispiel 10 dargestellten Shell-Skript. Im Prüffeld bietet es sich an, die internen Kernellatenz-Histogramme regelmäßig automatisch auszulesen und eine entsprechende Warnmeldung auszulösen, wenn erhöhte Werte festgestellt werden.

Schließlich ist auch zu erwähnen, dass das Konzept vieler Steuerungsprogramme eine zyklisch ausgeführte Hauptschleife vorsieht, deren Ausführungsdauer naturgemäß nicht länger sein darf als das vorgesehene Zyklusintervall. Entsprechend bietet sich an, bei jedem Durchlauf der Hauptschleife zu prüfen, ob der Durchlauf rechtzeitig gestartet ist, und eine Warnmeldung auszugeben, sollte dies nicht der Fall sein. Aber auch bei dieser Methode schließen sich dann weitere spezielle Messungen – zum Beispiel mit aktiviertem Kernel-Funktions-Tracing – an, um die jeweilige Ursache der zu langen Ausführungsdauer der Hauptschleife zu ermitteln. (cg)

Die Codebeispiele zum Beitrag

1.
 while true; do hackbench 25; done
2.
 while true; do ls -Ral /; done
3.
 preempt_disable();
 local_irq_disable(); while (nops--)
 	 asm(„nop“); 
 local_irq_enable(); 
 preempt_enable();
4.
 cyclictest -a -t -n -p99 -i100 -d25
5.
 mount -t debugfs nodev /sys/kernel/debug
6.
 nodev /sys/kernel/debug debugfs defaults 0 0
7.
 CONFIG_WAKEUP_LATENCY_HIST=y
8.
 CONFIG_INTERRUPT_OFF_HIST=y
9.
 CONFIG_PREEMPT_OFF_HIST=y
10.
 cd /sys/kernel/debug/tracing/latency_hist
 for i in */reset
 do
	echo 1 >$i
 done

1. Echtzeitfähigkeit von Linux-Systemen empirisch bestimmen
2. Echtzeitfähigkeit von Linux-Systemen empirisch bestimmen
3. Echtzeitfähigkeit von Linux-Systemen empirisch bestimmen
4. Echtzeitfähigkeit von Linux-Systemen empirisch bestimmen
5. Echtzeitfähigkeit von Linux-Systemen empirisch bestimmen
6. Echtzeitfähigkeit von Linux-Systemen empirisch bestimmen
7. Echtzeitfähigkeit von Linux-Systemen empirisch bestimmen