Le SMI possono certamente verificarsi durante il normale funzionamento. Il mio desktop di casa ha un SMI basato su chipset ogni secondo e mezzo che è abilitato nel chipset. Ho anche visto alcuni server che li hanno due volte al secondo a causa di uno schema di ridimensionamento della frequenza della CPU basato su BIOS. Tuttavia, alcuni sistemi possono passare lunghi periodi di tempo senza che si verifichi un SMI, quindi dipende davvero.
Domanda n. 1:hwlatdetect è un'opzione per rilevare la latenza degli SMI che si verificano sul tuo sistema. BIOSBITS è un'altra opzione che è un CD avviabile che può identificare se si stanno verificando SMI. Puoi anche scrivere il tuo test creando un modulo del kernel che gira in un ciclo e prende i timestamp (usando RDTSC). Se vedi un lungo intervallo tra due letture di timestamp, puoi consultare CPU MSR 0x34 per vedere se il contatore SMI è stato incrementato, il che indicherebbe che si è verificato un SMI.
Se si desidera generare una SMI, è possibile creare un modulo del kernel che esegua un'istruzione OUT CPU sulla porta 0xb2, ad es. scrivere un valore pari a 0 su questa porta. (Puoi anche cronometrare questo SMI raccogliendo un timestamp appena prima e subito dopo la scrittura sulla porta 0xB2).
Domanda n. 2, le SMI operano a un livello inferiore al sistema operativo, quindi il sistema operativo scelto non dovrebbe avere alcun impatto.
Domanda n. 3:BIOSBITS consiglia di mantenere le latenze SMI al di sotto dei 150 microsecondi.
SMI metterà il sistema in modalità SMM (System Management Mode), che posticiperà la normale esecuzione del kernel durante il periodo di gestione SMI. In altre parole, SMMi non è né in modalità reale né in modalità protetta come sappiamo del normale funzionamento del kernel, invece esegue alcune istruzioni speciali conservate in SMRAM (memorizzate nel BIOS Firmware). Per rilevare la sua latenza puoi provare ad attivare un SMI (può essere generato da software) e provare a catturare il tempo totale trascorso in modalità SMM. Per fare ciò puoi scrivere un modulo del kernel Linux, perché ti serviranno alcuni privilegi speciali per emettere un SMI (credo).
Per i sistemi in tempo reale penso che sia bello se puoi evitare questo tipo di interruzioni come SMI.
È possibile verificare se gli interrupt di gestione del sistema (SMI) sono serviti o meno con turbostat. Ad esempio:
# turbostat sleep 120
[check column SMI for value greater than 0]
Naturalmente, da quello puoi anche calcolare una frequenza SMI.
Sapere che le SMI si stanno effettivamente verificando a un certo ritmo è un'informazione importante. Ma vuoi anche sapere quanto tempo la modalità di gestione del sistema (SMM) trascorre in tali interruzioni. Ad esempio, se un'interruzione SMI è solo molto breve, potrebbe essere irrilevante per l'applicazione in tempo reale. D'altra parte, se disponi di hardware con lunghe interruzioni SMI, probabilmente vorrai parlare con il fornitore, configurare il firmware in modo diverso (se possibile) e/o passare ad altro hardware con SMM meno invadente.
Lo strumento perf ha una modalità che misura quanti cicli vengono spesi in SMM durante gli SMI (utilizzando le informazioni fornite da alcuni contatori della CPU). Esempio:
# 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
Puoi anche guardare i valori grezzi con:
# perf stat -a -A --smi-cost --metric-only -- sleep 120
Da ciò puoi calcolare quanto tempo impiega in media un SMI sulla tua macchina. (dividere la differenza di cicli per il numero di cicli per unità di tempo).
Ha sicuramente senso incrociare i risultati basati sui contatori CPU con quelli empirici.
È possibile utilizzare il Linux Hardware Latency Detector integrato nel kernel Linux. Esempio di utilizzo:
# 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
Questi strumenti sono disponibili su CentOS/RHEL 7 e dovrebbero essere disponibili anche su altre distribuzioni.
Per quanto riguarda le cifre del ballpark:di recente mi sono imbattuto in un server Xeon ProLiant Gen8 HP 2011-ish che attiva 504 SMI al minuto. Perf calcola un tasso dello 0,1% in SMM e, in base ai valori del contatore, il tempo medio trascorso in una SMI è di diversi microsecondi, ma il rilevatore hwlat di Linux non rileva interruzioni così elevate su quel sistema.
Tale percentuale SMI corrisponde a quanto documentato da HP nella sua Guida alla configurazione e all'ottimizzazione dei server HPE ProLiant per applicazioni a bassa latenza (ottobre 2017):
La disabilitazione degli interrupt di gestione del sistema al processore offre uno dei maggiori vantaggi per gli ambienti a bassa latenza. La disabilitazione dell'SMI di monitoraggio della potenza e dell'utilizzo del processore ha l'effetto maggiore perché genera un interrupt del processore otto volte al secondo nei server G6 e successivi.
(sottolineatura mia; e quella guida documenta anche altre fonti SMI)
Su una scheda Supermicro con Intel Atom C3758 e un mio sistema Intel NUC (i5-4250U) vengono conteggiate esattamente zero SMI.
Su un laptop Dell basato su Intel i7-6600U, il sistema riporta 8 SMI al minuto, ma il contatore aperf è inferiore al contatore dei cicli (non interrotto) che non dovrebbe accadere.