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

Date:	Mon, 16 Feb 2009 00:10:15 +0100
From:	"Rafael J. Wysocki" <rjw@...k.pl>
To:	pm list <linux-pm@...ts.linux-foundation.org>
Cc:	LKML <linux-kernel@...r.kernel.org>,
	Arve Hjønnevåg <arve@...roid.com>,
	Alan Stern <stern@...land.harvard.edu>,
	Benjamin Herrenschmidt <benh@...nel.crashing.org>,
	Pavel Machek <pavel@....cz>,
	Nigel Cunningham <nigel@...el.suspend2.net>,
	Matthew Garrett <mjg59@...f.ucam.org>,
	mark gross <mgross@...ux.intel.com>,
	"Woodruff, Richard" <r-woodruff2@...com>,
	Uli Luckas <u.luckas@...d.de>,
	Igor Stoppa <igor.stoppa@...ia.com>,
	Brian Swetland <swetland@...gle.com>,
	Len Brown <lenb@...nel.org>
Subject: [RFD] Automatic suspend

Hi,

The recent descussion about the Android PM patches sent by Arve shows that
there is a need to introduce a mechanism allowing us to:
(1) automatically put the system as a whole into a sleep state (eg. suspend to
    RAM) when it is found to be "idle", where the meaning of "idle" has to be
    defined too,
(2) put given subset of devices into low power states whenever they are not
    used, without putting the entire system into a sleep state.
To allow these two things to happen, the Andriod patches introduced the
wakelocks with the associated infrastructure and the "early suspend" mechanism.
However, quite a number of reviewers did not like these patches, for various
reasons, so they cannot be regarded as generally acceptable.  For this reason,
I think, we should discuss the problem in detail from the beginning and try to
find a solution that everyone interested will be comfortable with.

For this purpose, IMO, we should at least reach an agreement on what the
kernel's and the userland's roles in (1) and (2) are going to be.  There also
are quite a few questions that need to be answered.  For instance, what
conditions are going to be used to decide whether or not the system is idle
enough so that we can put it into a sleep state?  How are we going to check
these conditions?  What is going to happen if one (or more) of them changes
while a system-wide power transition (eg. suspend) is in progress?  Are we
going to allow the user space to take part in this and if so, to what extent?
What mechanisms are going be used to put devices into low power states at run
time (ie. before starting any system-wide power transition) and how are they
going to be related to the suspend-resume infrastructure used during
system-wide power transitions?  The answers to these (and other related)
questions will likely affect all of the future Linux PM developlent, so IMO
this is a very important matter.

Opinions and comments welcome.

Thanks,
Rafael
--
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/