Re: suspend blockers & Android integration

[Neil Brown]

On Fri, 4 Jun 2010 01:23:02 +0200
Ingo Molnar <mingo@xxxxxxx> 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
--
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/