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:smi-latency:start [2018/07/10 14:47] ebugden Fix typo in SMM description |
realtime:documentation:howto:debugging:smi-latency:start [2025/04/13 15:39] (current) costa.shul rdmsr |
||
---|---|---|---|
Line 31: | Line 31: | ||
<WRAP half column> | <WRAP half column> | ||
===== Identifying SMI Related Latencies ===== | ===== Identifying SMI Related Latencies ===== | ||
- | Below are some suggested tools for confirming and characterizing SMIs. The concepts of SMI and SMM are specific to x86, but some of the techniques and tools mentioned below can be used to debug similar firmware or hardware issues on other architectures. | + | Below are some tools for confirming and characterizing SMIs presented in a suggested order of use. Counting SMIs with Cyclictest is a good place to start because it is a good idea to first confirm that SMIs are happening on a system before investigating the possibility that they are causing latencies. |
- | * [[realtime:documentation:howto:debugging:cyclictest-smi-count|Cyclictest - SMI count]] (Intel x86 only) | + | * ''rdmsr -d 0x34'' |
- | * [[realtime:documentation:howto:debugging:cyclictest-smi-ftrace|Cyclictest - Function tracing]] | + | * [[realtime:documentation:howto:tools:cyclictest:options:smi-count|Cyclictest - SMI count]] (Intel x86 only) |
- | * [[realtime:documentation:howto:debugging:hwlat|Ftrace - hwlat tracer]] | + | * [[realtime:documentation:howto:debugging:smi-latency:cyclictest-tracing|Cyclictest - SMI detection with function tracing]] |
- | * [[realtime:documentation:howto:debugging:perf-smi-cost|Perf stat - Average duration of SMI handling]] (Intel x86 only) | + | * [[realtime:documentation:howto:tools:hwlat|Ftrace - hwlat tracer]] |
+ | * [[realtime:documentation:howto:tools:perf-smi-cost|Perf stat - Cost of SMI handling]] (Intel x86 only) | ||
- | It is important to note that there are intentionally only a few vague suggestions about how long it should take to handle an SMI in the pages linked above. This is because, in the case of SMI handling, the definition of "too long" depends on the application's timing requirements. More specifically, the maximum number of SMIs, the maximum frequency at which they can occur, and the maximum amount of time it can take to handle them, all depend on the application's requirements. One application might be able to handle several SMIs that take 10-15 us to resolve whereas those times may be way too long for another application. Additionally, an SMI related latency of over 100 us is generally bad, but again the timing requirements of certain applications could allow for such latencies. So, a knowledge of the system's deadline requirements is absolutely necessary for interpreting the results of the suggested tests. | + | The concepts of SMI and SMM are specific to x86, but some of the techniques and tools mentioned above can be used to debug similar firmware or hardware issues on other architectures. |
+ | |||
+ | <WRAP rightalign>[[realtime:documentation:howto:debugging:smi-latency:detection|Read more about identifying SMI related latencies]]</WRAP> | ||
</WRAP> | </WRAP> | ||
Line 52: | Line 55: | ||
</WRAP> | </WRAP> | ||
+ | |||
+ | **Read also** | ||
+ | * [[realtime:documentation:howto:debugging:start|RT latency debugging]] | ||
+ |