linux-kernel - Re: [RFD] Automatic suspend

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] [thread-next>] [day] [month] [year] [list]

Date:	Tue, 17 Feb 2009 06:20:01 -0800
From:	Brian Swetland <swetland@...gle.com>
To:	Matthew Garrett <mjg59@...f.ucam.org>
Cc:	"Rafael J. Wysocki" <rjw@...k.pl>,
	Arjan van de Ven <arjan@...radead.org>,
	"Woodruff, Richard" <r-woodruff2@...com>,
	Alan Stern <stern@...land.harvard.edu>,
	Kyle Moffett <kyle@...fetthome.net>,
	Oliver Neukum <oliver@...kum.org>,
	Benjamin Herrenschmidt <benh@...nel.crashing.org>,
	pm list <linux-pm@...ts.linux-foundation.org>,
	LKML <linux-kernel@...r.kernel.org>,
	Arve Hjønnevåg <arve@...roid.com>,
	Pavel Machek <pavel@....cz>,
	Nigel Cunningham <nigel@...el.suspend2.net>,
	mark gross <mgross@...ux.intel.com>,
	Uli Luckas <u.luckas@...d.de>,
	Igor Stoppa <igor.stoppa@...ia.com>,
	Len Brown <lenb@...nel.org>
Subject: Re: [RFD] Automatic suspend

[Matthew Garrett <mjg59@...f.ucam.org>]
> On Tue, Feb 17, 2009 at 12:19:38AM +0100, Rafael J. Wysocki wrote:
> 
> > This, again, seems to be a bit x86-centric. :-)  The Android people are telling
> > us that on the hardware they deal with it does make sense to put the entire
> > system to sleep even for relatively short periods of time, since the latencies
> > involved are not too bad.
> 
> Arve said that the power state was equivalent in idle and suspend, but 
> that they preferred suspend because it stopped any periodic timers. I'd 
> be more interested in making sure that unnecessary timers aren't running 
> than focusing on automatically entering system-wide suspend - Nokia have 
> been managing this since 2005 with good results.

We'd totally agree that doing something about periodic timers would be a
big win.  There's also the situation that the longest ARM linux can sit
in idle right now is ~2s at a time (Arve can expand on the exact issue
relating to a 32bit signed nanosecond value somewhere iirc), which we'd
want to sort out as well.

Of course that still doesn't address userspace.  Aggressively going to
suspend lets us compensate for userspace programs that do somewhat silly
things (I agree that it would be best if they didn't but they do and
getting *everyone* to write their userspace code to avoid spinning or
avoid waking up on short-duration timers to poll is a losing battle).

Brian

--
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/