Evaluating SMI (System Management Interrupt) latency on Linux-CentOS/Intel machine

Question

I am interested in evaluating the behavior (latency, frequency) of SMI handling on Linux machine running CentOS and used for a (very) soft real time application.

<

Answer 1

You can check whether System Management Interrupts (SMI) are serviced or not with turbostat. For example:

# turbostat sleep 120
[check column SMI for value greater than 0]

Of course, from that you can also compute a SMI frequency.

Knowing that SMIs are actually happening at a certain rate is important information. But you also want to know how much time System Management Mode (SMM) spends in those interrupts. For example, if an SMI interruption is only very short than it might be irrelevant for your realtime application. On the other hand, if you have hardware with long SMI interruptions you probably want to talk to the vendor, configure the firmware differently (if possible) and or switch to other hardware with less intrusive SMM.

The perf tool has a mode that measures how many cycles are spend in SMM during SMIs (using the information provided by certain CPU counters). Example:

# 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

You can also look at the raw values with:

# perf stat -a -A --smi-cost --metric-only -- sleep 120

From that you can compute how much time an SMI takes on average on your machine. (divide cycles difference by the number of cycles per time unit).

It certainly makes sense to cross check the CPU counter based results with empiric ones.

You can use the Linux Hardware Latency Detector that is integrated in the Linux Kernel. Usage example:

# 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

Those tools are available on CentOS/RHEL 7 and should be available on other distributions, as well.

Regarding ballpark figures: Recently I came across a HP 2011-ish ProLiant Gen8 Xeon server that fires 504 SMIs per minute. Perf computes a rate of 0.1 % in SMM, and based on the counter values the averge time spent in an SMI is as high as several microseconds - but the Linux hwlat detector doesn't detect such high interruptions on that system.

That SMI rate matches what HP documents in its Configuring and tuning HPE ProLiant Servers for low-latency applications guide (October, 2017):

Disabling System Management Interrupts to the processor provides one of the greatest benefits to low-latency environments. Disabling the Processor Power and Utilization Monitoring SMI has the greatest effect because it generates a processor interrupt eight times a second in G6 and later servers.

(emphasis mine; and that guide also documents other SMI sources)

On a Supermicro board with Intel Atom C3758 and an Intel NUC (i5-4250U) system of mine there are exactly zero SMIs counted.

On an Intel i7-6600U based Dell laptop, the system reports 8 SMIs per minute, but the aperf counter is lower than the (unhalted) cycles counter which isn't supposed to happen.

Answer 2

Actually, SMI is used for more than just keyboard emulation. Servers use SMI to report and correct ECC memory errors, ACPI uses SMI to communicate with BIOS and perform some tasks, even enabling and disabling ACPI is done through SMI, BIOS often intercepts power state changes through SMI... there's more, this is just a few examples.

Answer 3

SMIs can certainly happen during normal operation. My home desktop has a chipset-driven SMI every second and a half which is enabled in the chipset. I've also seen some servers that have them twice a second due to a BIOS-driven CPU frequency scaling scheme. However, some systems can go long periods of time without an SMI occurring so it really depends.

Question #1: hwlatdetect is one option to detect the latency of SMIs occurring on your system. BIOSBITS is another option which is a bootable CD that can identify if SMIs are occuring. You can also write your own test by creating a kernel module that spins in a loop and takes timestamps (using RDTSC). If you see a long gap between two timestamp readings, you could consult CPU MSR 0x34 to see if the SMI counter incremented which would indicate that an SMI happened.

If you want to generate an SMI, you can make a kernel module that does an OUT CPU instruction to port 0xb2, e.g. write a value of 0 to this port. (You can also time this SMI by gathering a timestamp just before and just after the write to port 0xB2).

Question #2, SMIs operate at a layer below the OS so which OS you choose, shouldn't have any impact.

Question #3: BIOSBITS recommends that SMI latencies be kept under 150 microseconds.

Answer 4

SMI will put your system into SMM (System Management Mode) mode, which will postpone the normal execution of kernel during the SMI handling time period. In other words, SMM is neither real mode nor protected mode as we know of normal operation of kernel, instead it executes some special instruction kept in SMRAM (stored in Bios Firmware). To detect it's latency you can try to trigger an SMI (it can be software generated) and try to catch the total time spent in SMM mode. To accomplish this you can write a Linux kernel module, cause you'll be require some special privileges to issue an SMI (I think).

For real time systems I think it's nice if you can avoid these sort of interrupts like SMI.

Answer 5

According to wikipage on System Management Mode, SMI is not used during normal operation, except perhaps to emulate a PS/2 keyboard with a USB physical keyboard.

And most Linux systems are able to drive genuine USB keyboard without that emulation. You could configure your BIOS to disable it.