On Wed, May 26, 2010 at 3:12 PM, Alan Stern <stern@xxxxxxxxxxxxxxxxxxx> 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? > Yes it is a loop. I think what you are missing is that it only loops repeatedly if the driver that aborts suspend does not use a suspend blocker. > And even if it isn't, so what? What's wrong with looping behavior? It is a significant power drain. > 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 > > -- Arve Hjønnevåg -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html