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? And even if it isn't, so what? What's wrong with looping behavior? Especially a loop that's as short as this one and spends almost all of its time sleeping. Think how much harder it would be to write programs if you weren't allowed to use any loops. :-) Alan Stern _______________________________________________ linux-pm mailing list linux-pm@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/linux-pm
