Re: rt20 scheduling latency testcase and failure data

[Ingo Molnar]

* 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.

	Ingo
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/