Cyclictest v1.0 has an option (–smi) which enables counting the number of SMIs that occur on a system. The count comes from a model-specific register (MSR) which stores the number of SMIs that have happened on a CPU, so this Cyclictest option will only work if the CPU has that MSR. The required MSR is exclusively available on Intel x86 processors from after around 2008 (as of the Nehalem microarchitecture).

This Cyclictest option is useful because it helps to quickly confirm whether or not SMIs are taking place. This is an important step in the debugging process, because if no SMIs are taking place then they cannot be causing latencies and other latency sources must be investigated.

Below is an example of a Cyclictest command for an SMP system that includes the smi option. The '#' before the command is to indicate that it must be run as root, with sudo, or as a member of the realtime group.

# cyclictest --mlockall --smp --priority=80 --interval=200 --distance=0 --smi

The combination of options in this example is not appropriate for every test situation. More details about how to choose the right options for measuring a specific latency on a given system can be found in the Cyclictest documentation here.

After running Cyclictest, the number of SMIs that have happened in each CPU will be displayed along with the rest of the Cyclictest results.

If this test is being used to generally evaluate the system and not for debugging a specific issue, as soon as the test results show that SMIs are occurring, even only a couple, it is worth further investigation into why they are happening. This is because most of the time SMI handlers perform operations that are not strictly necessary or useful for the system. In other words, eliminating the root cause of SMIs is usually possible and generally eliminates potential latency problems.