Les SMI peuvent certainement se produire pendant le fonctionnement normal. Mon bureau personnel a un SMI piloté par chipset toutes les secondes et demie qui est activé dans le chipset. J'ai également vu certains serveurs les avoir deux fois par seconde en raison d'un schéma de mise à l'échelle de la fréquence du processeur piloté par le BIOS. Cependant, certains systèmes peuvent passer de longues périodes sans qu'un SMI ne se produise, cela dépend donc vraiment.
Question #1 :hwlatdetect est une option pour détecter la latence des SMI se produisant sur votre système. BIOSBITS est une autre option qui est un CD amorçable qui peut identifier si des SMI se produisent. Vous pouvez également écrire votre propre test en créant un module de noyau qui tourne en boucle et prend des horodatages (à l'aide de RDTSC). Si vous voyez un long intervalle entre deux lectures d'horodatage, vous pouvez consulter le CPU MSR 0x34 pour voir si le compteur SMI a augmenté, ce qui indiquerait qu'un SMI s'est produit.
Si vous souhaitez générer une SMI, vous pouvez créer un module noyau qui exécute une instruction OUT CPU sur le port 0xb2, par ex. écrire une valeur de 0 sur ce port. (Vous pouvez également chronométrer cette SMI en recueillant un horodatage juste avant et juste après l'écriture sur le port 0xB2).
Question n ° 2, les SMI fonctionnent à une couche sous le système d'exploitation, donc le système d'exploitation que vous choisissez ne devrait pas avoir d'impact.
Question #3 :BIOSBITS recommande que les latences SMI soient maintenues en dessous de 150 microsecondes.
SMI mettra votre système en mode SMM (System Management Mode), ce qui retardera l'exécution normale du noyau pendant la période de traitement SMI. En d'autres termes, SMMis n'est ni en mode réel ni en mode protégé comme nous le savons du fonctionnement normal du noyau, à la place, il exécute une instruction spéciale conservée dans la SMRAM (stockée dans le micrologiciel du Bios). Pour détecter sa latence, vous pouvez essayer de déclencher un SMI (il peut être généré par un logiciel) et essayer de capturer le temps total passé en mode SMM. Pour ce faire, vous pouvez écrire un module de noyau Linux, car vous aurez besoin de privilèges spéciaux pour émettre un SMI (je pense).
Pour les systèmes en temps réel, je pense que c'est bien si vous pouvez éviter ce genre d'interruptions comme SMI.
Vous pouvez vérifier si les interruptions de gestion du système (SMI) sont desservies ou non avec le turbostat. Par exemple :
# turbostat sleep 120
[check column SMI for value greater than 0]
Bien sûr, à partir de là, vous pouvez également calculer une fréquence SMI.
Savoir que les SMI se produisent réellement à un certain rythme est une information importante. Mais vous voulez également savoir combien de temps le mode de gestion du système (SMM) passe dans ces interruptions. Par exemple, si une interruption SMI n'est que très courte, cela peut ne pas être pertinent pour votre application en temps réel. D'un autre côté, si vous avez du matériel avec de longues interruptions SMI, vous voudrez probablement parler au fournisseur, configurer le micrologiciel différemment (si possible) et/ou passer à un autre matériel avec un SMM moins intrusif.
L'outil de performance a un mode qui mesure le nombre de cycles passés dans SMM pendant les SMI (en utilisant les informations fournies par certains compteurs CPU). Exemple :
# 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
Vous pouvez également consulter les valeurs brutes avec :
# perf stat -a -A --smi-cost --metric-only -- sleep 120
À partir de là, vous pouvez calculer le temps qu'une SMI prend en moyenne sur votre machine. (divisez la différence de cycles par le nombre de cycles par unité de temps).
Il est certainement logique de vérifier les résultats basés sur le compteur CPU avec des résultats empiriques.
Vous pouvez utiliser le détecteur de latence matérielle Linux intégré au noyau Linux. Exemple d'utilisation :
# 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
Ces outils sont disponibles sur CentOS/RHEL 7 et devraient également être disponibles sur d'autres distributions.
En ce qui concerne les chiffres approximatifs :récemment, je suis tombé sur un serveur HP ProLiant Gen8 Xeon 2011-ish qui déclenche 504 SMI par minute. Perf calcule un taux de 0,1 % dans SMM, et sur la base des valeurs du compteur, le temps moyen passé dans un SMI peut atteindre plusieurs microsecondes - mais le détecteur Linux hwlat ne détecte pas des interruptions aussi élevées sur ce système.
Ce taux SMI correspond à ce que HP documente dans son guide de configuration et de réglage des serveurs HPE ProLiant pour les applications à faible latence (octobre 2017) :
La désactivation des interruptions de gestion du système sur le processeur offre l'un des plus grands avantages pour les environnements à faible latence. dans les serveurs G6 et ultérieurs.
(c'est moi qui souligne ; et ce guide documente également d'autres sources SMI)
Sur une carte Supermicro avec Intel Atom C3758 et un de mes systèmes Intel NUC (i5-4250U), il n'y a exactement aucun SMI compté.
Sur un ordinateur portable Dell basé sur Intel i7-6600U, le système signale 8 SMI par minute, mais le compteur aperf est inférieur au compteur de cycles (ininterrompu), ce qui n'est pas censé se produire.