Re: [patch] Real-Time Preemption, -RT-2.6.10-rc2-mm3-V0.7.32-15

[Ingo Molnar]

* Mark_H_Johnson@xxxxxxxxxxxx <Mark_H_Johnson@xxxxxxxxxxxx> 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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/