realtime:documentation:howto:debugging:smi-latency:start
Differences
This shows you the differences between two versions of the page.
| Both sides previous revision Previous revision | Next revision Both sides next revision | ||
|
realtime:documentation:howto:debugging:smi-latency:start [2018/07/12 06:34] ebugden Chage perf SMI cost title |
realtime:documentation:howto:debugging:smi-latency:start [2018/07/12 13:50] ebugden Move excess SMI identification content to separate page |
||
|---|---|---|---|
| Line 31: | Line 31: | ||
| <WRAP half column> | <WRAP half column> | ||
| ===== Identifying SMI Related Latencies ===== | ===== Identifying SMI Related Latencies ===== | ||
| - | Below are some tools for confirming and characterizing SMIs presented in a suggested order of use. Cyclictest's SMI count 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. | + | 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) | * [[realtime:documentation:howto:debugging:cyclictest-smi-count|Cyclictest - SMI count]] (Intel x86 only) | ||
| Line 41: | Line 41: | ||
| <WRAP rightalign>[[realtime:documentation:howto:debugging:smi-latency:detection|Read more about identifying SMI related latencies]]</WRAP> | <WRAP rightalign>[[realtime:documentation:howto:debugging:smi-latency:detection|Read more about identifying SMI related latencies]]</WRAP> | ||
| - | |||
| - | <WRAP center round todo 60%> | ||
| - | Move the rest of the stuff in this section to the page in the link above (also include the content at the start of the section in the other page). Also think of a better name for the page linked above. | ||
| - | </WRAP> | ||
| - | |||
| - | 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. | ||
| - | |||
| - | ==== Common SMI Triggers ==== | ||
| - | |||
| - | In order to help confirm the results from the analysis facilitated by the tools mentioned above, here are a few tasks that are often completed in system management mode: | ||
| - | |||
| - | * Emulation of legacy hardware (e.g. PC speaker, floppy disk) | ||
| - | * Emulation of missing, broken, or unsupported hardware or devices (e.g. USB keyboard, out of spec hardware) | ||
| - | * Power management | ||
| - | |||
| - | It is more likely that an apparently unexplainable latency in a situation or in code related to one of these topics is caused by an SMI. | ||
| </WRAP> | </WRAP> | ||
realtime/documentation/howto/debugging/smi-latency/start.txt ยท Last modified: 2018/08/21 13:21 by ebugden
Page Tools
Except where otherwise noted, content on this wiki is licensed under the following license: CC Attribution-Noncommercial-Share Alike 4.0 International
