Re: [patch] Real-Time Preemption, -RT-2.6.12-rc6-V0.7.48-00

[Ingo Molnar <mingo@elte.hu>]

* 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