Messages in this thread | | | Date | Fri, 10 Dec 2004 22:54:43 +0100 | From | Ingo Molnar <> | Subject | Re: [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/
| |