realtime:documentation:howto:debugging:cyclictest-smi-count
Differences
This shows you the differences between two versions of the page.
| Both sides previous revision Previous revision Next revision | Previous revision | ||
|
realtime:documentation:howto:debugging:cyclictest-smi-count [2018/07/10 15:55] ebugden Add explanation of how to use cyclictest smi option |
realtime:documentation:howto:debugging:cyclictest-smi-count [2018/08/21 12:54] ebugden Move from temporary location to main tools page |
||
|---|---|---|---|
| Line 1: | Line 1: | ||
| ====== Cyclictest - SMI count ====== | ====== Cyclictest - SMI count ====== | ||
| - | 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). | + | [[realtime:documentation:howto:tools:cyclictest:start|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 tool does not calculate the amount of time spent in system management mode, but it does help to quickly confirm whether or not SMIs are taking place and are therefore possibly causing latencies. | + | 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. |
| - | ===== Test Execution ===== | + | ===== Testing ===== |
| - | Below is a quick 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. | + | 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. |
| <code bash> | <code bash> | ||
| Line 13: | Line 13: | ||
| </code> | </code> | ||
| - | It is important to note that the combination of options in this example is not necessarily appropriate for any given 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 in the section that describes how to design a test correctly. | + | 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 [[realtime:documentation:howto:tools:cyclictest:test-design|here]]. |
| - | ===== Result Interpretation ===== | + | ===== Analysis ===== |
| After running Cyclictest, the number of SMIs that have happened in each CPU will be displayed along with the rest of the Cyclictest results. | 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 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. | + | 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. |
Page Tools
Except where otherwise noted, content on this wiki is licensed under the following license: CC Attribution-Noncommercial-Share Alike 4.0 International
