* Jörn Engel <joern@xxxxxxxxx> 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 _______________________________________________ linux-pm mailing list linux-pm@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/linux-pm
