Explain the background of the trace variable tracing_max_latency in the context of the wakeup and the wakeup_rt tracer and why it does not necessarily measure the worst-case latency of the system. Signed-off-by: Carsten Emde <C.Emde@xxxxxxxxx> Index: linux-2.6.33-rc2/Documentation/trace/ftrace.txt =================================================================== --- linux-2.6.33-rc2.orig/Documentation/trace/ftrace.txt +++ linux-2.6.33-rc2/Documentation/trace/ftrace.txt @@ -117,9 +117,25 @@ of ftrace. Here is a list of some of the For example, the time interrupts are disabled. This time is saved in this file. The max trace will also be stored, and displayed by "trace". - A new max trace will only be recorded if the + A new max trace will only be recorded, if the latency is greater than the value in this - file. (in microseconds) + file (in microseconds). NOTE: The max latency + recorded by the wakeup and the wakeup_rt tracer + do not necessarily reflect the worst-case latency + of the system. If two or more processes share the + highest priority of the system and may be woken + up shortly after each other, the max latency + recorded by the wakeup and the wakeup_rt tracers + equal the worst-case latency of the system *plus* + the longest possible runtime duration of all tasks + that share the same priority. An exact measurement + of the worst-case wakeup latency of the system can + be achieved using the wakekup latency histograms + that are part of the PREEMPT_RT patches. These + histograms separately determine the wakeup latency + of a task that exclusively uses the highest + priority of the system and of tasks that share the + highest priority of the system with other tasks. buffer_size_kb: -- To unsubscribe from this list: send the line "unsubscribe linux-rt-users" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
