Messages in this thread |  | | | Date | Wed, 29 Jun 2005 14:54:09 +0200 | | From | Ingo Molnar <> | | Subject | Re: [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/
|  |