linux-kernel - Re: [BUG] Strange 1-second pauses during Resume-from-RAM

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

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/