[lkml]   [2010]   [Jun]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [RFC][PATCH] PM: Avoid losing wakeup events during suspend
    On Sun, 20 Jun 2010 22:23:38 -0400 (EDT)
    Alan Stern <> wrote:

    > On Sun, 20 Jun 2010, Rafael J. Wysocki wrote:

    > > > In what way is this better than suspend blockers?
    > >
    > > It doesn't add any new framework and it doesn't require the users of
    > > pm_wakeup_event() to "unblock" suspend, so it is simpler. It also doesn't add
    > > the user space interface that caused so much opposition to appear.
    > Okay. A quick comparison shows that in your proposal:
    > There's no need to register and unregister suspend blockers.
    > But instead you create the equivalent of a suspend blocker
    > inside every struct device.
    > Drivers (or subsystems) don't have to activate suspend
    > blockers. But instead they have to call pm_wakeup_event().
    > Drivers don't have to deactivate suspend blockers. You don't
    > have anything equivalent, and as a result your scheme is
    > subject to the race described below.
    > There are no userspace suspend blockers and no opportunistic
    > suspend. Instead a power-manager process takes care of
    > initiating or preventing suspends as needed.
    > In short, you have eliminated the userspace part of the suspend blocker
    > approach just as in some of the proposals posted earlier, and you have
    > replaced the in-kernel suspend blockers with new data in struct device
    > and a new PM API. On the whole, it doesn't seem very different from
    > the in-kernel part of suspend blockers. The most notable difference is
    > the name: pm_wake_event() vs. suspend_blocker_activate(), or whatever
    > it ended up being called.
    > This is the race I was talking about:
    > > > What happens if an event arrives just before you read
    > > > /sys/power/wakeup_count, but the userspace consumer doesn't realize
    > > > there is a new unprocessed event until after the power manager checks
    > > > it?
    > > I think this is not the kernel's problem. In this approach the kernel makes it
    > > possible for the user space to avoid the race. Whether or not the user space
    > > will use this opportunity is a different matter.
    > It is _not_ possible for userspace to avoid this race. Help from the
    > kernel is needed.

    It is possible if every (relevant) userspace program implements a
    callback for the powermanager to check if one of it's wakeup-sources
    got activated.

    That way the powermanager would read /sys/power/wakeup_count, then do
    the roundtrip to all it's registered users and only then suspend.

    This turns the suspend_blockers concept around. Instead of actively
    signaling the suspend_blockers, the userspace programs only answer
    "yes/no" when asked. (i.e. polling?)

    You _can not_ implement userspace suspend blockers with this approach,
    as it is vital for every userspace program to get scheduled and check
    it's wakeup-source (if even possible) before you know that the right
    parties have won the race.


     \ /
      Last update: 2010-06-21 07:35    [W:0.032 / U:11.552 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site