* William Weston <[email protected]> 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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]