SMIs können durchaus im Normalbetrieb auftreten. Mein Home-Desktop hat alle anderthalb Sekunden ein chipsatzgesteuertes SMI, das im Chipsatz aktiviert ist. Ich habe auch einige Server gesehen, die sie aufgrund eines BIOS-gesteuerten CPU-Frequenzskalierungsschemas zweimal pro Sekunde haben. Einige Systeme können jedoch lange Zeit ohne Auftreten eines SMI auskommen, also kommt es wirklich darauf an.
Frage Nr. 1:hwlatdetect ist eine Option, um die Latenz von SMIs zu erkennen, die auf Ihrem System auftreten. BIOSBITS ist eine weitere Option, bei der es sich um eine bootfähige CD handelt, die erkennen kann, ob SMIs auftreten. Sie können auch Ihren eigenen Test schreiben, indem Sie ein Kernelmodul erstellen, das sich in einer Schleife dreht und Zeitstempel nimmt (mithilfe von RDTSC). Wenn Sie eine lange Lücke zwischen zwei Zeitstempelablesungen sehen, können Sie CPU MSR 0x34 konsultieren, um zu sehen, ob der SMI-Zähler inkrementiert wurde, was darauf hindeutet, dass ein SMI aufgetreten ist.
Wenn Sie ein SMI generieren möchten, können Sie ein Kernelmodul erstellen, das eine OUT-CPU-Anweisung an Port 0xb2 ausführt, z. Schreiben Sie einen Wert von 0 an diesen Port. (Sie können dieses SMI auch zeitlich festlegen, indem Sie unmittelbar vor und unmittelbar nach dem Schreiben auf Port 0xB2 einen Zeitstempel erfassen).
Frage Nr. 2, SMIs arbeiten auf einer Ebene unterhalb des Betriebssystems, sodass das von Ihnen gewählte Betriebssystem keine Auswirkungen haben sollte.
Frage Nr. 3:BIOSBITS empfiehlt, dass SMI-Latenzen unter 150 Mikrosekunden gehalten werden.
SMI versetzt Ihr System in den SMM-Modus (System Management Mode), wodurch die normale Ausführung des Kernels während der SMI-Verarbeitungszeit verschoben wird. Mit anderen Worten, SMM ist weder der Realmodus noch der geschützte Modus, wie wir den normalen Betrieb des Kernels kennen, stattdessen führt es einige spezielle Anweisungen aus, die im SMRAM (in der Bios-Firmware gespeichert) gespeichert sind. Um seine Latenz zu erkennen, können Sie versuchen, ein SMI auszulösen (es kann softwaregeneriert sein) und versuchen, die im SMM-Modus verbrachte Gesamtzeit zu erfassen. Um dies zu erreichen, können Sie ein Linux-Kernel-Modul schreiben, da Sie einige spezielle Privilegien benötigen, um ein SMI auszugeben (glaube ich).
Für Echtzeitsysteme finde ich es schön, wenn man diese Art von Interrupts wie SMI vermeiden kann.
Mit Turbostat können Sie prüfen, ob System Management Interrupts (SMI) bedient werden oder nicht. Zum Beispiel:
# turbostat sleep 120
[check column SMI for value greater than 0]
Daraus lässt sich natürlich auch eine SMI-Frequenz errechnen.
Zu wissen, dass SMIs tatsächlich mit einer bestimmten Rate stattfinden, ist eine wichtige Information. Sie möchten aber auch wissen, wie viel Zeit der System Management Mode (SMM) in diesen Interrupts verbringt. Wenn beispielsweise eine SMI-Unterbrechung nur sehr kurz ist, kann dies für Ihre Echtzeitanwendung irrelevant sein. Wenn Sie andererseits Hardware mit langen SMI-Unterbrechungen haben, möchten Sie wahrscheinlich mit dem Anbieter sprechen, die Firmware anders konfigurieren (falls möglich) und/oder zu einer anderen Hardware mit weniger aufdringlichem SMM wechseln.
Das Leistungstool hat einen Modus, der misst, wie viele Zyklen in SMM während SMIs verbracht werden (unter Verwendung der Informationen, die von bestimmten CPU-Zählern bereitgestellt werden). Beispiel:
# perf stat -a -A --smi-cost -- sleep 120
Performance counter stats for 'system wide':
SMI cycles% SMI#
CPU0 0.0% 0
CPU1 0.0% 0
CPU2 0.0% 0
CPU3 0.0% 0
120.002927948 seconds time elapsed
Sie können sich die Rohwerte auch ansehen mit:
# perf stat -a -A --smi-cost --metric-only -- sleep 120
Daraus können Sie berechnen, wie viel Zeit ein SMI auf Ihrer Maschine im Durchschnitt benötigt. (Unterschied der Zyklen durch die Anzahl der Zyklen pro Zeiteinheit dividieren).
Es ist sicherlich sinnvoll, die auf CPU-Zählern basierenden Ergebnisse mit empirischen abzugleichen.
Sie können den im Linux-Kernel integrierten Linux Hardware Latency Detector verwenden. Anwendungsbeispiel:
# echo hwlat > /sys/kernel/debug/tracing/current_tracer
# echo 1 > /sys/kernel/debug/tracing/tracing_thresh
# watch -d -n 5 cat /sys/kernel/debug/tracing/tracing_max_latency
# echo "Don't forget to disable it again"
# echo nop > /sys/kernel/debug/tracing/current_tracer
Diese Tools sind auf CentOS/RHEL 7 verfügbar und sollten auch auf anderen Distributionen verfügbar sein.
Bezüglich der ungefähren Zahlen:Kürzlich bin ich auf einen HP 2011-ähnlichen ProLiant Gen8 Xeon-Server gestoßen, der 504 SMIs pro Minute abfeuert. Perf berechnet eine Rate von 0,1 % in SMM, und basierend auf den Zählerwerten beträgt die durchschnittliche Zeit, die in einem SMI verbracht wird, mehrere Mikrosekunden - aber der Linux-Hwlat-Detektor erkennt keine so hohen Unterbrechungen auf diesem System.
Diese SMI-Rate entspricht den Dokumenten von HP in seinem Handbuch zum Konfigurieren und Optimieren von HPE ProLiant Servern für Anwendungen mit niedriger Latenz (Oktober 2017):
Das Deaktivieren von Systemverwaltungs-Interrupts für den Prozessor bietet einen der größten Vorteile für Umgebungen mit geringer Latenz. Das Deaktivieren des SMI zur Überwachung von Prozessorleistung und -auslastung hat die größte Wirkung, da es achtmal pro Sekunde einen Prozessor-Interrupt generiert in G6 und späteren Servern.
(Hervorhebung von mir; und dieser Leitfaden dokumentiert auch andere SMI-Quellen)
Auf einem Supermicro Board mit Intel Atom C3758 und einem Intel NUC (i5-4250U) System von mir werden genau null SMIs gezählt.
Auf einem Dell-Laptop auf Intel i7-6600U-Basis meldet das System 8 SMIs pro Minute, aber der Aperf-Zähler ist niedriger als der (nicht angehaltene) Zyklenzähler, was nicht passieren sollte.