lkml.org 
[lkml]   [2010]   [May]   [31]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [linux-pm] [PATCH 1/8] PM: Opportunistic suspend support.
    On Mon, 31 May 2010 09:03:29 +1000
    Neil Brown <neilb@suse.de> wrote:

    > > Well, please have a look at the Alan Stern's proposal here:
    > > http://lkml.org/lkml/2010/5/29/77
    > >
    >
    > Thanks for the reference.
    > Some of the details are different, but the idea seems almost exactly the same
    > as mine.
    > The apparent dependence on signals makes me feel a little uncomfortable
    > (interfaces that depend on using signals seem to be easy to use wrongly), but
    > I don't think that is a serious flaw.
    >
    > Maybe the biggest difference is philosophical. Alan's proposal appears to be
    > adding a new feature. Mine presents as trying to fix an existing feature so
    > that it can be used reliably.
    > It is easier to argue against a feature than against a bug-fix (??).

    Addendum...

    The use of signals by Alan here got me thinking.. and combining it which what
    Alan Cox and Thomas Gleixner (and others?) have been saying about detecting
    idleness led me down an interesting path that I thought I would share.

    An absolutely minimal change to allow a user-space initiated auto-suspend to
    be race-free would be achieved by placing an interruptible wait between
    pm_notifier_call_chain(PM_SUSPEND_PREPARE);
    and
    suspend_freeze_processes();

    which waits for all kernel threads to have passed through an 'idle' state.

    Then any wake event that happened after the PM_SUSPEND_PREPARE would
    presumably either abort the suspend later, or would cause an immediate
    wake-up.
    Any event that happened before the PM_SUSPEND_PREPARE would have been fully
    processed by any kernel thread and so would be queued for user-space (or have
    been discarded).

    If we then require any process that handles wakeup events to use the
    equivalent of fcntl(F_SETOWN) to direct a SIGIO (or other signal) at the
    process which requests the suspend, then wakeup events won't be lost.
    They will either send a signal to the suspend-daemon in time to abort the
    suspend, or will be late enough to either abort the suspend in-kernel, or
    trigger an immediate wakeup.

    Yes: this would require quite a large change of the android code, and the
    F_SETOWN usage is fairly ugly, but balanced against it actually working and
    it being minimal, that might be OK.

    The hardest part would be waiting for all kernel-threads to pass through idle
    (or all threads to pass through idle or user-space). We'd need help to make
    that work, but at least it would be a fairly localised change.

    Maybe it is something to keep in mind when other possibilities have proven
    intractable.

    NeilBrown


    \
     
     \ /
      Last update: 2010-05-31 07:59    [W:4.588 / U:0.168 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site