lkml.org 
[lkml]   [2010]   [Jun]   [4]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: suspend blockers & Android integration
    On Fri, 4 Jun 2010 01:23:02 +0200
    Ingo Molnar <mingo@elte.hu> wrote:

    > Btw., i'd like to summarize the scheduler based suspend scheme proposed by
    > Thomas Gleixner, Peter Zijlstra and myself. I found no good summary of it in
    > the big thread, and there are also new elements of the proposal:

    Hi
    I would like to summarise the alternate proposal that I an others have
    suggested in a variety of different forms.

    It starts from the premise that
    1/ Android developers actually like the "big hammer" aspect of suspend.
    Initiating suspend powers down some devices, puts others in low power
    states, freezes all processes and generally puts the device to sleep
    with a well defined and easily controlled (at the whole-of-system level)
    set of events that will wake from suspend. This is a big part of the
    Android approach to power-saving and I'm guessing they are not keen to
    depart from it.

    2/ The main problem with using suspend as-is is that it is racy.
    The purpose of suspend is to put the device to sleep until a wake-event
    occurs. When that wake-event occurs at much the same time that suspend is
    requested races can occur. We want a wake-event to not only wake the
    device, to be keep the device awake while the wake-event is being handled,
    and to cancel any suspend that was initiated before the wake event
    completed.
    We need to understand "wake event" in an holistic sense. If a key press is
    expected to brighten the screen and make a glyph appear, and if that key
    press is considered to be a wake-event, then the glyph appearing must also
    be a part of the wake event. For such a holistic wake-event to fully
    block/cancel a suspend there much be some mechanism for hand-over of
    wake-events from kernel-space to user-space.

    Given those premises, google's suspend-blocker approach was to allow a
    kernel thread to initiate suspend whenever nothing was stopping it, and to
    allow both drivers and user processes to block that suspend while handling
    a wake event (or anything else that needed to keep the device awake).
    In this case the hand-over is fairly straight forward as the kernel thread
    as full knowledge and can easily wait for all sorts of things.

    The alternate proposal is simply to have user-space initiate a suspend (as
    is already possible), user-space processes can then trivially block that
    suspend through any of a number of IPC approaches, and kernel space drivers
    can block/abort suspend by explicitly requesting a block.

    The variety of alternate proposals comes from a variety of ways to modify
    the semantics of "ask for a suspend" in such a way that userspace can
    discover when there are kernel-space blocks, and can wait for them to be
    released without spinning.

    A sample modification (which I think is different to all the ones
    mentioned so far, and hopefully pulls out the best of them all) is
    to allow userspace to write e.g. "mem_safe" rather than "mem" to
    /sys/power/state. The 'safe' implies it is safe from races.

    When this is written, the process sleeps in an interruptible state until
    all in-kernel suspend blocks have been dropped. If any such suspend blocks
    were found, or if a signal is received, the request aborts. Only if there
    were no suspend blocks and no pending signals does the suspend progress.

    wake-events in the kernel then need to be tracked all the way to user-space,
    and the in-kernel lock is only dropped when the event is consumed by
    user-space. User-space must take some sort of lock to ensure no new
    suspend is requested before consuming any wake-events from the kernel.

    I believe this is very close to what android has today, only with a much
    smaller change to the user-space interface, which I believe to be the thing
    that has been found most objectionable.
    I does still require a degree of event-tracking within the kernel which
    might still be objectionable - I'm not so sure about different people's
    positions on that.

    Thanks,
    NeilBrown


    \
     
     \ /
      Last update: 2010-06-04 06:41    [W:5.232 / U:0.096 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site