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

[Ingo Molnar <mingo@elte.hu>]

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

> Here is my get_ltrace.sh script (at the end).
> 
> So I read the preempt_max_latency (to see if its changed) before I
> copy the latency_trace output. I am not so sure that cat is really
> doing an "atomic" read when some of the latency traces are over 300
> Kbytes in length.

reading preempt_max_latency ought to be fine to detect changes.

yes, even a 300 KB trace should be read atomically too, even if it takes
3 seconds to save, hence all the different layers of trace buffers. The
kernel does not update the output buffer until the 'cat' has finished.
(unless a parallel 'cat' interferes - all your scripts are serialized,
right?)

> Also note that some of the files were empty :-(. I don't think I've
> seen that symptom before.

hm, an empty file occurs if the saved output trace is empty. This should
only be the case shortly after resetting preempt_max_latency. (or after
bootup, until it's set for the first time.)

> Note that the preempt_max_latency value DID match the last line of the
> trace output in the example I described. It is just the header that
> had some stale data in it.

yeah. It's weird. Ahh .. reviewing the header-generation code again i
noticed a buglet, which could cause spuriously wrong latency values on
SMP systems. Does the patch below fix this particular symptom?

	Ingo

--- linux/kernel/latency.c.orig
+++ linux/kernel/latency.c
@@ -542,7 +542,7 @@ static void update_out_trace(void)
 	 * trace buffer.
 	 */
 	tmp_out = out_tr.traces + 0;
-	*tmp_out = max_tr.traces[0]; // TODO: dont copy the traces
+	*tmp_out = max_tr.traces[max_tr.cpu]; // TODO: dont copy the traces
 	out_tr.cpu = max_tr.cpu;
 	out_entry = tmp_out->trace + 0;