realtime:documentation:howto:debugging:cyclictest:debugging
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:debugging [2018/07/17 15:03] ebugden [Selecting Instrumentation] Clarify section start |
— (current) | ||
|---|---|---|---|
| Line 1: | Line 1: | ||
| - | ====== Cyclictest - Latency debugging with tracing ====== | ||
| - | Tracing is useful when trying to determine the cause of a latency because it can reveal relevant details about program execution. There are several options in Cyclictest that can be used to produce traces via Ftrace. These traces can then be consulted via tracefs. | ||
| - | |||
| - | ===== Break Trace Option ===== | ||
| - | |||
| - | A trace can be collected through Cyclictest by using the break trace option together with one of the tracing options. The break trace option (--breaktrace) will stop tracing and end Cyclictest if it detects a latency that is longer than a specified limit. This option is intended to be used with one of the Cyclictest options that enables a specific Ftrace tracer. | ||
| - | |||
| - | ===== Selecting Instrumentation ===== | ||
| - | |||
| - | Cyclictest offers a number options which use different Ftrace tracers and instrumentation. These options are described in the Cyclictest help text (--help) and on the man page. The most important things to keep in mind when choosing instrumentation are the trace detail and the resulting overhead. A trace with more detail will require a higher overhead. In general, it is best to start with a small amount of instrumentation, which produces a simple trace, and to corner the source of the latency over several iterations of tracing and analysis while gradually increasing the trace detail. One good option would be to start by tracing when interrupts or preemption are disabled to first eliminate the most obvious possible sources of latency. | ||
| - | |||
| - | It can sometimes be tempting to immediately jump to enabling function tracing. A full function trace is highly detailed because it includes all of the function calls that were made in the kernel. Function tracing can be very useful in the debugging process, but starting with such a highly detailed trace is not recommended. Analyzing a full function trace can be time consuming and confusing, especially if the issue to debug is complex. To make matters worse, function tracing has a significant overhead so it has a higher chance of affecting the behavior of the system. Because of this high overhead, it is possible that in some cases the targeted latency will not occur when function tracing is enabled. | ||
realtime/documentation/howto/debugging/cyclictest/debugging.1531839810.txt.gz ยท Last modified: 2018/07/17 15:03 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
