lkml.org 
[lkml]   [2010]   [Jun]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    SubjectRe: [linux-pm] suspend blockers & Android integration
    From
    2010/6/6 Alan Stern <stern@rowland.harvard.edu>:
    > On Sat, 5 Jun 2010, Alan Stern wrote:
    >
    >> > If you are referring to the approach that we don't use suspend but
    >> > freeze a cgroup instead, this only solves the problem of bad apps. It
    >> > does not help pause timers in trusted user space code and in the
    >> > kernel, so it does not lower our average power consumption.
    >>
    >> You can solve this problem if you restructure your "trusted" apps in
    >> the right way.  Require a trusted app to guarantee that whenever it
    >> doesn't hold any suspend blockers, it will do nothing but wait (in a
    >> poll() system call for example) for a wakeup event.  When the event
    >> occurs, it must then activate a suspend blocker.
    >>
    >> Better yet, make it more fine-grained.  Instead of trusted apps, have
    >> trusted threads.  Freeze the untrusted threads along with everything
    >> else, and require the trusted threads to satisfy this guarantee.
    >>
    >> In this way, while the system is idle no user timers will get renewed.
    >> Kernel timers are another matter, but we should be able to handle them.
    >> There's nothing Android-specific about wanting to reduce kernel timer
    >> wakeups while in a low-power mode.
    >
    > In fact it's possible to do this with only minimal changes to the
    > userspace, providing you can specify all your possible hardware wakeup
    > sources.  (On the Android this list probably isn't very large -- I
    > imagine it includes the keypad, the radio link(s), the RTC, and maybe
    > a few switches, buttons, or other things.)
    >
    > Here's how you can do it.  Extend the userspace suspend-blocker API, so
    > that each suspend blocker can optionally have an associated wakeup
    > source.
    >
    > The power-manager process should keep a list of "active" wakeup
    > sources.  A source gets removed from the list when an associated
    > suspend blocker is activated.
    >

    How do you do this safely? If you remove the active wakeup only when
    activating the suspend blocker, you will never unblock suspend if
    another wakeup event happens after user-space blocked suspend but
    before user-space read the events.

    Also, I'm not sure we can easily associate a wakeup event with a user
    space suspend blocker. For instance when an alarm triggers it is
    sometimes because of a user-space alarm and sometimes because an
    in-kernel alarm.

    > When the "active" list is empty and no suspend blockers are activated,
    > the power manager freezes ALL other processes, trusted and untrusted
    > alike.  It then does a big poll() on all the wakeup sources.  When the
    > poll() returns, its output is used to repopulate the "active" list and
    > processes are unfrozen.
    >
    > (You can also include some error detection: If a source remains on the
    > "active" list for too long then something has gone wrong.)
    >
    > To do all this you don't even need to use cgroups.  The existing PM
    > implementation allows a user process to freeze everything but itself;
    > that's how swsusp and related programs work.
    >
    > This is still a big-hammer sort of approach, but it doesn't require any
    > kernel changes.
    >
    > Alan Stern
    >
    >



    --
    Arve Hjønnevåg
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

    \
     
     \ /
      Last update: 2010-06-08 02:25    [W:4.085 / U:0.284 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site