lkml.org 
[lkml]   [2004]   [Dec]   [10]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [patch] Real-Time Preemption, -RT-2.6.10-rc2-mm3-V0.7.32-15

    * Mark_H_Johnson@Raytheon.com <Mark_H_Johnson@Raytheon.com> wrote:

    > Hmm. Now that I look at it, the duration in the header (99 usec) is
    > the duration of lt.01 (as reported by the script) but the total
    > duration of the trace (248 usec) is the duration from the script for
    > lt.02.

    how do your collection scripts access /proc/latency_trace? The output is
    only atomic if the file is read as a whole, i.e.:

    cat /proc/latency_trace > wherever

    or:

    cp /proc/latency wherever

    but i guess you are doing this already ...

    obviously tracing goes on while the scripts are saving the latency
    trace, so the kernel goes to great lengths to try to guarantee
    atomicity. There are 3 levels of tracing buffers:

    - 'current' trace buffers (per CPU)
    - 'max' trace buffer
    - 'output' trace buffer

    the max trace is updated whenever a new max latency is detected. (not
    stricly true: if one CPU is already saving a trace and this CPU detects
    a new latency too then this CPU skips the trace, instead of spinning
    waiting for the other CPU. This makes the tracing code more atomic, but
    it opens up a window to 'lose' a latency - but statistically every
    _type_ of latency should be saved sooner or later, since the 'dropping'
    of traces is random, not systematic.)

    the output trace is atomically filled in from the max trace, whenever
    userspace accesses offset 0 of /proc/latency_trace. It will stay the
    same until userspace finishes reading /proc/latency_trace (arrives to
    the maximum offset of the file). Hence userspace can take all time it
    wants to save a trace, it will stay the same. At least this is the
    theory.

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

    \
     
     \ /
      Last update: 2005-03-22 14:08    [W:4.011 / U:0.008 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site