Messages in this thread Patch in this message | | | Date | Fri, 10 Dec 2004 23:24:32 +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:
> 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; - 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/
| |