linux-kernel - Re: [PATCH 1/8] PM: Opportunistic suspend support.

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]

Message-ID: <1274866402.5882.5051.camel@twins>
Date:	Wed, 26 May 2010 11:33:22 +0200
From:	Peter Zijlstra <peterz@...radead.org>
To:	Florian Mickler <florian@...kler.org>
Cc:	Arve Hjønnevåg <arve@...roid.com>,
	"Rafael J. Wysocki" <rjw@...k.pl>,
	Alan Stern <stern@...land.harvard.edu>,
	Dmitry Torokhov <dmitry.torokhov@...il.com>,
	Linux-pm mailing list <linux-pm@...ts.linux-foundation.org>,
	Kernel development list <linux-kernel@...r.kernel.org>,
	Len Brown <len.brown@...el.com>, Pavel Machek <pavel@....cz>,
	Randy Dunlap <rdunlap@...otime.net>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Andi Kleen <ak@...ux.intel.com>,
	Cornelia Huck <cornelia.huck@...ibm.com>,
	Tejun Heo <tj@...nel.org>,
	Jesse Barnes <jbarnes@...tuousgeek.org>,
	Nigel Cunningham <nigel@...onice.net>,
	Ming Lei <tom.leiming@...il.com>,
	Wu Fengguang <fengguang.wu@...el.com>,
	Maxim Levitsky <maximlevitsky@...il.com>,
	linux-doc@...r.kernel.org, Matthew Garrett <mjg59@...f.ucam.org>,
	Greg KH <gregkh@...e.de>, tytso@....edu,
	James Bottomley <James.Bottomley@...e.de>
Subject: Re: [PATCH 1/8] PM: Opportunistic suspend support.

On Wed, 2010-05-26 at 11:23 +0200, Florian Mickler wrote:

> There is polling, because the suspend manager in userspace doesn't have
> the whole picture. i.e. it doesn't know if a suspend will be
> successfull. 
> So for aggressive suspending as a powersave-feature you need to poll
> (i.e. retry upon failure). because you don't want to stay unsuspended. 

Clearly if it fails, there something to be done, right? So whoever does
the thing will communicate with the suspend manager that it's going to
do and has finished doing its thing, at which point it will try again.

That's event driven, not polled.

Also, if you want you can keep the kernel-side auto-suspend side, and
have the suspend manager clear on !0 and re-establish the auto-suspend
state on 0.

But you really don't need this device thingy.
--
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/