[lkml]   [2010]   [May]   [26]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [PATCH 1/8] PM: Opportunistic suspend support.
    On Thursday 27 May 2010, Alan Stern wrote:
    > On Wed, 26 May 2010, Rafael J. Wysocki wrote:
    > > > The reason is simple: When a user process initiates an opportunistic
    > > > suspend, you make it wait in an interruptible sleep until all the
    > > > kernel suspend blockers are released. No polling. If another user
    > > > thread decides in the meantime that it needs to block the suspend, it
    > > > sends a signal to the power manager process.
    > > >
    > > > In fact, other threads should signal the power manager process whenever
    > > > they want to block or unblock suspends. That way the power manager
    > > > process can spend all its time sleeping, without doing any polling.
    > >
    > > I still see an issue here. Namely, if the power manager is in user space and
    > > it's signaled to suspend, it has to ask the kernel to do that, presumably by
    > > writing something to a sysfs file. Then, if the kernel blocks the suspend, the
    > > power manager waits until the block is released. Now, it should go back and
    > > check if user space still doesn't block suspend and if so, wait until the block
    > > is released and start over. With all suspend blockers in the kernel this
    > > looping behavior is avoidable.
    > I must be missing something. In Arve's patch 1/8, if the system is in
    > opportunistic suspend, and a wakeup event occurs but no suspend
    > blockers get enabled by the handler, what causes the system to go back
    > into suspend after the event is handled? Isn't that a loop of some
    > sort?

    Well, yes it is.


     \ /
      Last update: 2010-05-27 00:49    [W:0.021 / U:36.764 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site