Los SMI ciertamente pueden ocurrir durante el funcionamiento normal. El escritorio de mi hogar tiene un SMI controlado por chipset cada segundo y medio que está habilitado en el chipset. También he visto algunos servidores que los tienen dos veces por segundo debido a un esquema de escalado de frecuencia de CPU controlado por BIOS. Sin embargo, algunos sistemas pueden pasar largos períodos de tiempo sin que ocurra un SMI, por lo que realmente depende.
Pregunta n.º 1:hwlatdetect es una opción para detectar la latencia de las SMI que se producen en su sistema. BIOSBITS es otra opción que es un CD de arranque que puede identificar si se están produciendo SMI. También puede escribir su propia prueba creando un módulo de kernel que gira en un bucle y toma marcas de tiempo (usando RDTSC). Si ve una brecha larga entre dos lecturas de marca de tiempo, puede consultar CPU MSR 0x34 para ver si el contador SMI aumentó, lo que indicaría que ocurrió un SMI.
Si desea generar un SMI, puede crear un módulo de kernel que realice una instrucción de CPU OUT al puerto 0xb2, p. escriba un valor de 0 en este puerto. (También puede cronometrar este SMI recopilando una marca de tiempo justo antes y después de escribir en el puerto 0xB2).
Pregunta n.º 2:las SMI funcionan en una capa por debajo del sistema operativo, por lo que el sistema operativo que elija no debería tener ningún impacto.
Pregunta #3:BIOSBITS recomienda que las latencias SMI se mantengan por debajo de los 150 microsegundos.
SMI pondrá su sistema en modo SMM (Modo de administración del sistema), lo que pospondrá la ejecución normal del kernel durante el período de tiempo de manejo de SMI. En otras palabras, SMM no es ni modo real ni modo protegido como sabemos del funcionamiento normal del kernel, sino que ejecuta alguna instrucción especial guardada en SMRAM (almacenada en Bios Firmware). Para detectar su latencia, puede intentar activar un SMI (puede ser generado por software) e intentar capturar el tiempo total pasado en el modo SMM. Para lograr esto, puede escribir un módulo del kernel de Linux, porque necesitará algunos privilegios especiales para emitir un SMI (creo).
Para los sistemas en tiempo real, creo que es bueno si puede evitar este tipo de interrupciones como SMI.
Puede verificar si las interrupciones de administración del sistema (SMI) están atendidas o no con turbostato. Por ejemplo:
# turbostat sleep 120
[check column SMI for value greater than 0]
Por supuesto, a partir de eso también puede calcular una frecuencia SMI.
Saber que los SMI están ocurriendo realmente a un cierto ritmo es información importante. Pero también desea saber cuánto tiempo pasa el modo de administración del sistema (SMM) en esas interrupciones. Por ejemplo, si una interrupción de SMI es muy breve, podría ser irrelevante para su aplicación en tiempo real. Por otro lado, si tiene hardware con largas interrupciones de SMI, probablemente desee hablar con el proveedor, configurar el firmware de manera diferente (si es posible) o cambiar a otro hardware con SMM menos intrusivo.
La herramienta perf tiene un modo que mide cuántos ciclos se gastan en SMM durante SMI (usando la información proporcionada por ciertos contadores de CPU). Ejemplo:
# 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
También puede ver los valores sin procesar con:
# perf stat -a -A --smi-cost --metric-only -- sleep 120
A partir de eso, puede calcular cuánto tiempo tarda en promedio un SMI en su máquina. (divida la diferencia de ciclos por el número de ciclos por unidad de tiempo).
Ciertamente tiene sentido cotejar los resultados basados en el contador de la CPU con los empíricos.
Puede usar el detector de latencia de hardware de Linux que está integrado en el kernel de Linux. Ejemplo de uso:
# 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
Esas herramientas están disponibles en CentOS/RHEL 7 y también deberían estar disponibles en otras distribuciones.
Con respecto a las cifras aproximadas:recientemente me encontré con un servidor HP ProLiant Gen8 Xeon 2011-ish que dispara 504 SMI por minuto. Perf calcula una tasa del 0,1 % en SMM y, según los valores de los contadores, el tiempo promedio que se pasa en un SMI es de varios microsegundos, pero el detector hwlat de Linux no detecta interrupciones tan altas en ese sistema.
Esa tasa de SMI coincide con lo que HP documenta en su guía de configuración y ajuste de servidores HPE ProLiant para aplicaciones de baja latencia (octubre de 2017):
La desactivación de las interrupciones de administración del sistema en el procesador proporciona uno de los mayores beneficios para los entornos de baja latencia. La desactivación del SMI de monitoreo de uso y energía del procesador tiene el mayor efecto porque genera una interrupción del procesador ocho veces por segundo. en servidores G6 y posteriores.
(énfasis mío; y esa guía también documenta otras fuentes de SMI)
En una placa Supermicro con Intel Atom C3758 y un sistema Intel NUC (i5-4250U) mío, se cuentan exactamente cero SMI.
En una computadora portátil Dell basada en Intel i7-6600U, el sistema informa 8 SMI por minuto, pero el contador de rendimiento es más bajo que el contador de ciclos (ininterrumpidos), lo que no debería suceder.