Re: rt20 scheduling latency testcase and failure data

From: Ingo Molnar
Date: Thu May 18 2006 - 04:47:12 EST

* Sébastien Dugué <sebastien.dugue@xxxxxxxx> wrote:

> Darren,
> On Mon, 2006-05-15 at 18:30 -0700, Darren Hart wrote:
> > Following Ingo's example I have included the modified test case (please see
> > the original mail for librt.h) that starts the trace before each sleep and
> > disables it after we wake up. If we have missed a period, we print the
> > trace.
> >
> Your test program fails (at least on my box) as the overhead of
> starting and stopping the trace in the 5 ms period is just too high.
> By moving the latency_trace_start() at the start of the thread
> function and latency_trace_stop() at the end, everything runs fine. I
> did not have any period missed even under heavy load.

could you send us the fixed testcase?

thanks for tracking this down. FYI, the latency of stopping the trace is
that expensive because we are copying large amounts of trace data
around, to ensure that /proc/latency_trace is always consistent and is
updated atomically, and to make sure that we can update the trace from
interrupt contexts too - without /proc/latency_trace accesses blocking
them. The latency of stopping the trace is hidden from the tracer itself
- but it cannot prevent indirect effects such as your app from missing
periods, if the periods are in the 5msec range.

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at
Please read the FAQ at