Re: Attempted summary of suspend-blockers LKML thread
From: Paul E. McKenney
Date: Tue Aug 03 2010 - 11:41:34 EST
On Mon, Aug 02, 2010 at 09:18:27PM -0700, Arve Hjønnevåg wrote:
> On Sat, Jul 31, 2010 at 10:58 AM, Paul E. McKenney
> <paulmck@xxxxxxxxxxxxxxxxxx> wrote:
First, thank you very much for your review and feedback!
> > REQUIREMENTS
> > o Reduce the system's power consumption in order to (1) extend
> > battery life and (2) preserve state until AC power can be obtained.
> > o It is necessary to be able to use power-naive applications.
> > Many of these applications were designed for use in PC platforms
> > where power consumption has historically not been of great
> > concern, due to either (1) the availability of AC power or (2)
> > relatively undemanding laptop battery-lifetime expectations. The
> > system must be capable of running these power-naive applications
> > without requiring that these applications be modified, and must
> > be capable of reasonable power efficiency even when power-naive
> > applications are available.
> > o If the display is powered off, there is no need to run any
> > application whose only effect is to update the display.
> > Although one could simply block such an application when it next
> > tries to access the display, it appears that it is highly
> > desirable that the application also be prevented from
> > consuming power computing anything that will not be displayed.
> > Furthermore, whatever mechanism is used must operate on
> > power-naive applications that do not use blocking system calls.
> > o In order to avoid overrunning hardware and/or kernel buffers,
> > input events must be delivered to the corresponding application
> > in a timely fashion. The application might or might not be
> > required to actually process the events in a timely fashion,
> > depending on the specific application.
> > In particular, if user input that would prevent the system
> > from entering a low-power state is received while the system is
> > transitioning into a low-power state, the system must transition
> > back out of the low-power state so that it can hand the user
> > input off to the corresponding application.
> > o If a power-aware application receives user input, then that
> > application must be given the opportunity to process that
> > input.
> > o A power-aware application must be able to efficiently communicate
> > its needs to the system, so that such communication can be
> > performed on hot code paths. Communication via open() and
> > close() is considered too slow, but communication via ioctl()
> > is acceptable.
> The problem with using open and close to prevent an allow suspend is
> not that it is too slow but that it interferes with collecting stats.
> The wakelock code has a sysfs interface that allow you to use a
> open/write/close sequence to block or unblock suspend. There is no
> limit to the amount of kernel memory that a process can consume with
> this interface, so the suspend blocker patchset uses a /dev interface
> with ioctls to block or unblock suspend and it destroys the kernel
> object when the file descriptor is closed.
Ah, I missed this point. What I am doing to adjust is to strike the
above requirement, and to add verbiage to the "statistics" requirement
about using ioctl() to implement suspend-blocker operations, so that the
statistics can be tracked based on the device being open throughout the
> > o Power-naive applications must be prohibited from controlling
> > the system power state. One acceptable approach is through
> > use of group permissions on a special power-control device.
> > o Statistics of the power-control actions taken by power-aware
> > applications must be provided, and must be keyed off of program
> > name.
> We don't key the stats off the program name, but having useful
> statistics is critical too us. The current code in linux-next does not
> appear to allow this (I'm referring to pm_stay_awake here, etc not
OK, maybe I was confused earlier. So you do not track statistics via
the device being open throughout the application's lifetime?
I am not familiar with pm_stay_awake(), but will take a look at it.
> > o Power-aware applications can make use of power-naive infrastructure.
> > This means that a power-aware application must have some way,
> > whether explicit or implicit, to ensure that any power-naive
> > infrastructure is permitted to run when a power-aware application
> > needs it to run.
> > o When a power-aware application is preventing the system from
> > shutting down, and is also waiting on a power-naive application,
> > the power-aware application must set a timeout to handle
> > the possibility that the power-naive application might halt
> > or otherwise fail. (Such timeouts are also used to limit the
> > number of kernel modifications required.)
> wake-lock/suspend-blocker timeouts have nothing to do with the timeout
> used by applications when waiting for a response from a less trusted
OK, I moved this to a new "SUGGESTED USAGE" section and removed the
last (parenthesized) sentence.
> > o If no power-aware or power-optimized application are indicating
> > a need for the system to remain operating, the system is permitted
> > (even encouraged!) to suspend all execution, even if power-naive
> > applications are runnable. (This requirement did appear to be
> > somewhat controversial.)
> I would say it should suspend even if power aware applications are
> runnable. Most applications do not exclusively perform critical work.
The point being that a power-aware application does not block suspend
-unless- it holds a suspend blocker, correct?
Or am I missing some other subtlety?
> > o Transition to low-power state must be efficient. In particular,
> > methods based on repeated attempts to suspend are considered to
> > be too inefficient to be useful.
> It must be power-efficient. Repeated attempts to suspend will kill the
> idle battery life.
Good point! I changed "Transition to low-power state must be efficient"
to instead read "Transition to low-power state must be power-efficient."
> > o Individual peripherals and CPUs must still use standard
> > power-conservation measures, for example, transitioning CPUs into
> > low-power states on idle and powering down peripheral devices
> > and hardware accelerators that have not been recently used.
> > o The API that controls the system power state must be
> > accessible both from Android's Java replacement, from
> > userland C code, and from kernel C code (both process
> > level and irq code, but not NMI handlers).
> > o Any initialization of the API that controls the system power
> > state must be unconditional, so as to be free from failure.
> > (I don't currently understand how this relates, probably due to
> > my current insufficient understanding of the proposed patch set.)
> Unconditional initialization makes it easier to add suspend blockers
> to existing kernel code since you don't have to add new failure exit
> paths. It is not a strong requirement.
Ah, that makes more sense! I moved this to a new "NICE-TO-HAVES"
section. I also changed the last parenthesized sentence to read
"Such unconditional initialization reduces the intrusiveness of the
the Android patchset." Does that work?
> > o The API that controls the system power state must operate
> > correctly on SMP systems of modest size. (My guess is that
> > "modest" means up to four CPUs, maybe up to eight CPUs.)
> > o Any QoS-based solution must take display and user-input
> > state into account. In other words, the QoS must be
> > expressed as a function of the display and the user-input
> > states.
> > o Transitioning to extremely low power states requires saving
> > and restoring DRAM and/or cache SRAM state, which in itself
> > consumes significant energy. The power savings must therefore
> > be balanced against the energy consumed in the state
> > transitions.
> > o The current Android userspace API must be supported in order
> > to support existing device software.
Thank you again for looking this over and for your comments!!!
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/