[lkml]   [2006]   [May]   [18]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: rt20 scheduling latency testcase and failure data

    * Sébastien Dugué <> 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
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2006-05-18 10:50    [W:0.035 / U:1.264 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site