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. Rafael _______________________________________________ linux-pm mailing list linux-pm@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/linux-pm
