Estimated SMI (System Management Interruption) Delay on a Linux-CentOS / Intel Computer

Question

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

• What tools are recommended (hwlatdetect for CentOS?), And what is the best course of action for this?

• If there are no good tools for CentOS, can I assume that installing different OS on the same machine should give the same results, since the basic equipment / BIOS is the same?

• Is there any source for the numbers of balls by these parameters.

Machines is an X86_64 architecture running under CentOS 6.4 (kernel 2.6.32-358.23.2.el2.centos.plus.x86_64.)

Answer 1

SMIs can certainly occur during normal operation. My home desktop has an SMI with chipsets, every second and second, which is included in the chipset. I also saw several servers that have them twice per second due to the BIOS-based processor frequency scaling scheme. However, some systems can last a long time without the advent of SMI, so it really depends.

Question # 1: hwlatdetect is one way to detect the SMI latency that occurs in your system. BIOSBITS is another option that is a bootable CD that can determine if SMI is occurring. You can also write your own test by creating a kernel module that rotates in a loop and takes time stamps (using RDTSC). If you see a large gap between the two timestamp readings, you can check the MSR 0x34 CPU to see if the SMI counter has increased, which indicates that the SMI has occurred.

If you want to generate SMI, you can make a kernel module that executes the OUT CPU command for port 0xb2, for example. write a value of 0 on this port. (You can also run this SMI by collecting the timestamp immediately before and immediately after writing to port 0xB2).

Question No. 2, SMIs operate at a level below the OS, so the OS you choose should not have any effect.

Question # 3: BIOSBITS recommends keeping delays in SMI less than 150 microseconds.

Answer 2

SMI will put your system in SMM (system management mode) mode, which will delay normal kernel execution during the SMI processing period. In other words, SMM is neither a real mode, nor a protected mode, as we know about the normal operation of the kernel; instead, it executes some special instruction stored in SMRAM (stored in Bios Firmware). To detect the delay, you can try to run SMI (it can be generated by software) and try to catch the total time spent in SMM mode. You can write a Linux kernel module for this because you need some special privileges to issue SMI (I think).

For real-time systems, I find it nice if you can avoid interrupts like SMI.

Answer 3

Actually, SMI is used not only to emulate the keyboard. Servers use SMI to report and correct ECC memory errors, ACPI uses SMI to communicate with the BIOS and perform some tasks, even enable or disable ACPI through SMI, the BIOS often intercepts power state changes through SMI ... there are more, these are just a few examples .

Answer 4

You can check if the Interrupt System Management (SMI) is being serviced using a turbostat . For instance:

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

Of course, from this you can also calculate the SMI frequency.

Knowing that the media is really happening at a certain speed is important information. But you also want to know how much time System Management Mode (SMM) spends on these interrupts. For example, if the SMI interrupt is very short than it may not be relevant for your real-time application. On the other hand, if you have equipment with long SMI interruptions, you probably want to talk to your supplier, configure the firmware differently (if possible), or switch to other equipment with less intrusive SMM.

The perf tool has a mode that measures how many cycles are spent in SMM during SMI (using the information provided by specific 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 

Based on this, you can calculate how much time the average SMI takes on your machine. (divide the difference of cycles by the number of cycles per unit time).

Of course, it makes sense to double-check the results obtained on the basis of the processor counter with empirical results.

You can use the Linux hardware delay detector , which is built into 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 

These tools are available on CentOS / RHEL 7 and should be available on other distributions.

As for the approximate indicators: I recently came across a 2011 HP ProLiant Gen8 Xeon server that runs 504 SMI per minute. Perf calculates the 0.1% frequency in SMM, and based on the counter values, the average time spent in SMI reaches several microseconds, but the Linux hwlat detector does not detect such high interruptions in this system.

This SMI is consistent with HP docs when setting up and configuring it. HPE ProLiant Server Guide for Low Latency Applications (October 2017):

Disabling system control interruptions to the processor provides one of the greatest benefits for low latency environments. Turning off power monitoring and using the SMI processor has the greatest effect, because it generates a processor interrupt eight times per second in G6 and later servers.

(my emphasis; and this guide also documents other media sources)

On a Supermicro board with an Intel Atom C3758 processor and my Intel NUC system (i5-4250U), the number of SMIs is exactly zero.

On a Dell laptop based on the Intel i7-6600U, the system reports 8 SMI per minute, but the aperture counter is lower than the (undistorted) cycle counter, which should not be.

Answer 5

According to wikipage in system control mode , SMI is not used during normal operation, except possibly for emulating a PS / 2 keyboard with a USB physical keyboard interface.

And most Linux systems can control a genuine USB keyboard without this emulation. You can configure your BIOS to disable it.