On Fri, May 14, 2010 at 7:25 PM, Alan Stern <stern@xxxxxxxxxxxxxxxxxxx> wrote: > On Fri, 14 May 2010, Arve Hjønnevåg wrote: > >> On Fri, May 14, 2010 at 1:27 PM, Paul Walmsley <paul@xxxxxxxxx> wrote: >> > >> > Hello, >> > >> > On Mon, 3 May 2010, Arve Hjønnevåg wrote: >> > >> >> No, suspend blockers are mostly used to ensure wakeup events are not >> >> ignored, and to ensure tasks triggered by these wakeup events >> >> complete. >> > >> > Standard Linux systems don't need these, >> >> If you don't want to lose wakeup events they do. Standard Linux >> systems support suspend, but since they usually don't have a lot of >> wakeup events you don't run into a lot of problems. > > The primary client for opportunistic suspend and suspend blockers > appears to be embedded systems. These systems are typically capable of > powering the CPU down and up again with low latency, and they typically > have very aggressive runtime PM support capable of powering down each > device when it's not in active use. Given this ability, it does seem > that opportunistic suspend and suspend blockers might be unnecessary. > With the current kernel and user-space code we run, we get significantly better battery life on the msm plaform using suspend compared to entering the same power state from idle. On some devices it takes only five wakeup events per second to cut the best case battery life in half. > I'd like to explore this avenue a little farther. In particular, what > is the issue involving loss of wakeup events? Can you describe this in > more detail? > On the desktop systems I have used I only wake the up the system by pressing a button/key or with an rtc alarm. Losing a button or key wakeup event is not usually a problem on a desktop since the user will press it again. Losing an alarm however could be a problem and this can be avoided by using opportunistic suspend and suspend blockers. >> > because the scheduler just keeps >> > the system running as long as there is work to be done. >> > >> >> That is only true if you never use suspend. > > Why would you want to use system suspend if runtime PM can do > everything you need? > Because it stops threads that wakeup every second to check if they have work to do (this includes standard kernel threads), and it prevents bad apps that never go idle from completely destroying our battery life. > Sure, I can see that an ACPI-based system needs something more. But > that's not the real issue here. > The system we started with entered a much lower power state from suspend than idle so we needed wakelocks to get more than 24 hours battery life. We kept wakelocks when we moved to the msm platform since it reduces our power consumption. -- Arve Hjønnevåg _______________________________________________ linux-pm mailing list linux-pm@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/linux-pm
