* Jörn Engel <[email protected]> wrote:
> On Mon, 3 December 2007 01:57:02 +0100, Jörn Engel wrote:
> >
> > After an eternity of compile time, this config does generate some useful
> > output. qemu is not to blame.
>
> Or is it? The output definitely looks suspicious. Large amounts of
> code get processed within a microsecond, while update_wall_time()
> appears to cause huge delays every time it is called:
> http://logfs.org/~joern/trace
>
> Does this output make sense or does it rather indicate some sloppiness
> wrt. time in the qemu virtual machine?
not sure. It could be qemu being scheduled away? You could try to run
qemu with nice -20 or so, to avoid getting preempted. If time lapses
like this still show up:
trace-cm 434 0D.h. 1008us!: do_timer (tick_periodic)
trace-cm 434 0D.h. 1972us+: update_wall_time (do_timer)
trace-cm 434 0D.h. 1008us!: do_timer (tick_periodic)
trace-cm 434 0D.h. 1972us+: update_wall_time (do_timer)
then that could indicate a timekeeping weirdness, OR it could mean that
qemu is simply very slow. (there could be timer hw access between those
two function calls)
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]
