* Sébastien Dugué <[email protected]> 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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
