lkml.org 
[lkml]   [2004]   [Dec]   [10]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
Patch in this message
/
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:

> 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/
\
 
 \ /
  Last update: 2005-03-22 14:08    [W:0.068 / U:0.040 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site