* Jörn Engel <joern@logfs.org> wrote:

quoted text
> 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
--
unsubscribe notice
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/