On Thu, 6 May 2010, Tony Lindgren wrote: > Well if your hardware runs off-while-idle or even just > retention-while-idle, then the basic shell works just fine waking up > every few seconds or so. > > Then you could keep init/shell/suspend policy deamon running until > it's time to suspend the whole device. To cut down runaway timers, > you could already freeze the desktop/GUI/whatever earlier. This comes down mostly to efficiency. Although the suspend blocker patch does the actual suspending in a workqueue thread, AFAIK there's no reason it couldn't use a user thread instead. The important difference lies in what happens when a suspend fails because a driver is busy. Without suspend blockers, the kernel has to go through the whole procedure of freezing userspace and kernel threads and then suspending a bunch of drivers before hitting the one that's busy. Then all that work has to be undone. By contrast, with suspend blockers the suspend attempt can fail right away with minimal overhead. There's also a question of reliability. With suspends controlled by userspace there is a possibility of races, which could lead the system to suspend when it shouldn't. With control in the kernel, these races can be eliminated. Alan Stern -- 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