Differences

This shows you the differences between two versions of the page.

--- realtime:documentation:howto:debugging:cyclictest:debugging [2018/07/17 15:15]
ebugden Start trace producing section
+++ — (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.
-===== Producing a Trace =====
-There are a couple steps that can help correctly produce a trace that includes the relevant latency. Before tracing, make sure that the correct options for measuring the have been chosen and that Cyclictest detects the latency without having any tracing enabled. Adding tracing will not help if the latency is never detected in the first place.
-The following tips are relevant if the goal is to produce a trace that includes the system's maximum latency. In general, it is a good idea to start by resolving the longest latencies in a system and to work down towards solving the shorter latencies.
-When trying to produce a trace that includes a specific latency it is important to always adjust the break trace limit based on the observed tracing overhead.

Wiki

User Tools

Site Tools

Differences

Page Tools