[lkml]   [2010]   [Aug]   [3]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: Attempted summary of suspend-blockers LKML thread
    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
    > <> wrote:
    > ...

    First, thank you very much for your review and feedback!

    > >
    > > 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
    application's lifetime.

    > > 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
    > pm-qos.)

    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
    > application.

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

    Thanx, Paul
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2010-08-03 17:43    [W:0.064 / U:5.124 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site