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

[William Weston]

On Wed, 29 Jun 2005, Ingo Molnar 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)

This one was on -50-30.

--ww
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/