lkml.org 
[lkml]   [2010]   [Aug]   [4]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: Attempted summary of suspend-blockers LKML thread
    On Wed, Aug 04, 2010 at 05:35:09PM +0100, Matthew Garrett wrote:
    > On Wed, Aug 04, 2010 at 09:32:16AM -0700, Paul E. McKenney wrote:
    >
    > > If this doesn't work for the Android folks for whatever reason, another
    > > approach would be to do the freeze in user code, which could track
    > > whether any user-level resources (pthread mutexes, SysV semas, whatever)
    > > where held, and do the freeze on a thread-by-thread basis within each
    > > "victim" application as the threads reach safe points.
    >
    > The main problem I see with the cgroups solution is that it doesn't seem
    > to do anything to handle avoiding loss of wakeup events.

    cgroups alone don't but there is a solution which doesn't require routing
    all event data through a single server -- use SIGIO.

    Suppose we've got two cgroups of tasks -- those in the initial freezer
    cgroup and those in a freezer cgroup meant for power-naive apps. Let's
    call the second cgroup the naive cgroup.

    One task -- let's call it the "waker" -- is in the initial cgroup is normaly
    asleep waiting for SIGIO. Note it's not an "app" -- it's been trusted/blessed
    to be a non-power-naive task. It will be signaled via SIGIO by the
    applications which want to be unfrozen when an event comes in.

    When the power-naive app in the naive cgroup opens a file descriptor it's
    going through the Android interpretter to make the syscall. The interpretter
    can do fcntl() on the fd to cause SIGIO to be delivered to the waker task.
    When the waker gets SIGIO it unfreezes the naive cgroup and thus wakes the
    power-naive app. When the power-naive app wakes it will
    poll/return-from-poll/read/return-from-read and thus retrieve the event.

    Then it's just a matter of choosing when to freeze the naive cgroup. That
    requires a userspace implementation of the suspend blockers API plus
    opportunistic suspend but does not require any other kernel pieces. Then you
    can use sigprocmask to prevent the freeze/wake-event race. You would
    probably even merge the waker with the daemon which implements
    opportunistic suspend.

    Cheers,
    -Matt Helsley


    \
     
     \ /
      Last update: 2010-08-05 04:01    [W:3.495 / U:0.048 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site