From: "Rafael J. Wysocki" <rjw@sisk.pl>
To: "Arve Hjønnevåg" <arve@android.com>
Cc: linux-pm@lists.linux-foundation.org,
linux-kernel@vger.kernel.org, Greg KH <gregkh@suse.de>,
Mark Brown <broonie@opensource.wolfsonmicro.com>,
Kevin Hilman <khilman@deeprootsystems.com>,
Alan Stern <stern@rowland.harvard.edu>,
Brian Swetland <swetland@google.com>,
Daniel Walker <dwalker@fifo99.com>,
"Theodore Ts'o" <tytso@mit.edu>, Matthew Garrett <mjg@redhat.com>
Subject: Re: [PATCH 0/8] Suspend block api (version 7)
Date: Fri, 21 May 2010 00:21:15 +0200 [thread overview]
Message-ID: <201005210021.15420.rjw@sisk.pl> (raw)
In-Reply-To: <AANLkTimoU9BrzbAl7q-LZzGeRolO7gUKBoGjkPWtWn1G@mail.gmail.com>
On Wednesday 19 May 2010, Arve Hjønnevåg wrote:
...
> PM: Opportunistic suspend support.
>
> Power management features present in the current mainline kernel are
> insufficient to get maximum possible energy savings on some platforms,
> such as Android. The problem is that to save maximum amount of energy
> all system hardware components need to be in the lowest-power states
> available for as long as reasonably possible, but at the same time the
> system must always respond to certain events, regardless of the
> current state of the hardware.
>
> The first goal can be achieved either by using device runtime PM and
> cpuidle to put all hardware into low-power states, transparently from
> the user space point of view, or by suspending the whole system.
> However, system suspend, in its current form, does not guarantee that
> the events of interest will always be responded to, since wakeup
> events (events that wake the CPU from idle and the system from
> suspend) that occur right after initiating suspend will not be
> processed until another possibly unrelated event wakes the system up
> again.
>
> On hardware where idle can enter the same power state as suspend, idle
> combined with runtime PM can be used, but periodic wakeups increase
> the average power consumption. Suspending the system also reduces the
> harm caused by apps that never go idle. There also are systems where
> some devices cannot be put into low-power states without suspending
> the entire system (or the low-power states available to them without
> suspending the entire system are substantially shallower than the
> low-power states they are put into when the entire system is
> suspended), so the system has to be suspended as a whole to achieve
> the maximum energy savings.
>
> To allow Android and similar platforms to save more energy than they
> currently can save using the mainline kernel, introduce a mechanism by
> which the system is automatically suspended (i.e. put into a
> system-wide sleep state) whenever it's not doing work that's
> immediately useful to the user, called opportunistic suspend.
>
> For this purpose introduce the suspend blockers framework allowing the
> kernel's power management subsystem to decide when it is desirable to
> suspend the system (i.e. when the system is not doing anything the
> user really cares about at the moment and therefore it may be
> suspended). Add an API that that drivers can use to block
> opportunistic suspend. This is needed to avoid losing wakeup events
> that occur right after suspend is initiated.
>
> Add /sys/power/policy that selects the behavior of /sys/power/state.
> After setting the policy to opportunistic, writes to /sys/power/state
> become non-blocking requests that specify which suspend state to enter
> when no suspend blockers are active. A special state, "on", stops the
> process by activating the "main" suspend blocker.
That looks good to me.
Thanks,
Rafael
next prev parent reply other threads:[~2010-05-20 22:20 UTC|newest]
Thread overview: 50+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-05-14 4:11 [PATCH 0/8] Suspend block api (version 7) Arve Hjønnevåg
2010-05-14 4:11 ` [PATCH 1/8] PM: Add suspend block api Arve Hjønnevåg
2010-05-14 4:11 ` [PATCH 2/8] PM: suspend_block: Add driver to access suspend blockers from user-space Arve Hjønnevåg
2010-05-14 4:11 ` [PATCH 3/8] PM: suspend_block: Abort task freezing if a suspend_blocker is active Arve Hjønnevåg
2010-05-14 4:11 ` [PATCH 4/8] PM: suspend_block: Add debugfs file Arve Hjønnevåg
2010-05-14 4:11 ` [PATCH 5/8] PM: suspend_block: Add suspend_blocker stats Arve Hjønnevåg
2010-05-14 4:11 ` [PATCH 6/8] PM: Add suspend blocking work Arve Hjønnevåg
2010-05-14 4:11 ` [PATCH 7/8] Input: Block suspend while event queue is not empty Arve Hjønnevåg
2010-05-14 4:11 ` [PATCH 8/8] power_supply: Block suspend while power supply change notifications are pending Arve Hjønnevåg
2010-05-18 13:11 ` [PATCH 1/8] PM: Add suspend block api Pavel Machek
2010-05-20 9:11 ` Florian Mickler
2010-05-20 9:26 ` Florian Mickler
2010-05-20 22:18 ` Rafael J. Wysocki
2010-05-21 6:04 ` Florian Mickler
2010-05-27 15:41 ` Pavel Machek
2010-05-14 21:08 ` [PATCH 0/8] Suspend block api (version 7) Rafael J. Wysocki
2010-05-17 4:50 ` Arve Hjønnevåg
2010-05-17 19:01 ` Mike Snitzer
2010-05-17 21:42 ` Rafael J. Wysocki
2010-05-17 22:16 ` Kevin Hilman
2010-05-18 0:52 ` Arve Hjønnevåg
2010-05-18 16:18 ` Kevin Hilman
2010-05-18 18:52 ` Rafael J. Wysocki
2010-05-18 22:04 ` Kevin Hilman
2010-05-18 22:29 ` Rafael J. Wysocki
2010-05-19 0:00 ` Arve Hjønnevåg
2010-05-18 19:13 ` Rafael J. Wysocki
2010-05-18 20:47 ` Arve Hjønnevåg
2010-05-18 21:48 ` Rafael J. Wysocki
2010-05-18 22:03 ` Arve Hjønnevåg
2010-05-18 22:34 ` Rafael J. Wysocki
2010-05-18 22:52 ` Arve Hjønnevåg
2010-05-18 23:19 ` Rafael J. Wysocki
2010-05-18 23:42 ` Arve Hjønnevåg
2010-05-19 20:39 ` Rafael J. Wysocki
2010-05-19 21:34 ` Arve Hjønnevåg
2010-05-20 22:21 ` Rafael J. Wysocki [this message]
2010-05-16 19:42 ` Rafael J. Wysocki
2010-05-17 4:16 ` Arve Hjønnevåg
2010-05-17 20:40 ` Rafael J. Wysocki
2010-05-17 20:51 ` Brian Swetland
2010-05-17 21:44 ` Rafael J. Wysocki
2010-05-17 23:32 ` Arve Hjønnevåg
2010-05-18 19:38 ` Rafael J. Wysocki
2010-05-18 20:35 ` Arve Hjønnevåg
2010-05-18 21:14 ` Rafael J. Wysocki
2010-05-18 22:21 ` Arve Hjønnevåg
2010-05-18 22:56 ` Rafael J. Wysocki
2010-05-18 23:06 ` Arve Hjønnevåg
2010-05-19 20:40 ` Rafael J. Wysocki
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=201005210021.15420.rjw@sisk.pl \
--to=rjw@sisk.pl \
--cc=arve@android.com \
--cc=broonie@opensource.wolfsonmicro.com \
--cc=dwalker@fifo99.com \
--cc=gregkh@suse.de \
--cc=khilman@deeprootsystems.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pm@lists.linux-foundation.org \
--cc=mjg@redhat.com \
--cc=stern@rowland.harvard.edu \
--cc=swetland@google.com \
--cc=tytso@mit.edu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).