[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20071204093451.GA4541@elte.hu>
Date: Tue, 4 Dec 2007 10:34:51 +0100
From: Ingo Molnar <mingo@...e.hu>
To: Jörn Engel <joern@...fs.org>
Cc: Mark Lord <lkml@....ca>, Pavel Machek <pavel@....cz>,
Mark Lord <liml@....ca>, Thomas Gleixner <tglx@...utronix.de>,
len.brown@...el.com, Andrew Morton <akpm@...ux-foundation.org>,
linux-kernel@...r.kernel.org, linux-pm@...ts.linux-foundation.org,
rjw@...k.pl
Subject: Re: [BUG] Strange 1-second pauses during Resume-from-RAM
* Jörn Engel <joern@...fs.org> 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 majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists