lkml.org 
[lkml]   [2005]   [Jun]   [29]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [patch] Real-Time Preemption, -RT-2.6.12-rc6-V0.7.48-00

* William Weston <weston@sysex.net> wrote:

> I got a trace with VLC and one burnP6 instance running. The second
> included trace was started in the background immediately before firing
> up a second burnP6, but I'm not sure it covers any of the time that
> the second burnP6 was running.

there doesnt seem to be too much of an interrupt related problem:

$ grep 'do_IRQ (' trace-it.2.txt
<...>-18659 0Dnh. 228us : do_IRQ (80480d2 0 0)
<...>-18659 0Dnh. 1228us : do_IRQ (80480d6 0 0)
<...>-18659 0Dnh. 2232us : do_IRQ (80480d6 0 0)
<...>-18659 0Dnh. 3229us : do_IRQ (80480c4 0 0)
<...>-18659 0Dnh. 4227us : do_IRQ (80480e8 0 0)
<...>-18659 0Dnh. 5227us : do_IRQ (80480df 0 0)
<...>-18659 0Dnh. 6226us : do_IRQ (80480e8 0 0)
<...>-18659 0Dnh. 7226us : do_IRQ (80480df 0 0)
<...>-18659 0Dnh. 8225us : do_IRQ (80480c4 0 0)
<...>-18659 0Dnh. 9231us : do_IRQ (80480e3 0 0)
<...>-18659 0Dnh. 10225us : do_IRQ (80480e8 0 0)

you are getting a timer interrupt (IRQ 0) every 1000 usecs, as expected.

i'd suggest to capture trace-it traces only during a clearly identified
anomalous event such as an interrupt storm. For latency analysis
purposes the default latency traces are better.

> > on SMP this could occur if the TSCs of different CPUs are too apart from
> > each other. I'll probably put an automatic check for this into the
> > /proc/latency_trace code.
>
> Yup. Got another one of these.

was this on a -29 or later kernel? (-29 had a couple of latency.c fixes)

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/

\
 
 \ /
  Last update: 2005-06-29 14:58    [from the cache]
©2003-2011 Jasper Spaans