On Mon, 2010-05-17 at 08:40 -0700, Kevin Hilman wrote: > > Also, how does it handle the issue of ill-behaved apps? > > For userspace, apps that have polling behavior or are ill-behaved must > be found and fixed. Thanks to tools like powertop, this is a farily > easy task. That's a bit glib ... powertop can detect power consumption stats on a running system ... if you have a polling app preventing your system from suspending, powertop isn't necessarily going to find it ... especially if the polling interval is of the order of powertop's. Powertop can find the bad tens of wakeups per second, but it only takes one wakup every few seconds or so to drain the battery significantly when operating on suspend from idle. > But really, I don't consider the "ill-behaved app" problem to be a > real-world problem. Both in maemo/meego and Android, if someone > writes an app that kills battery life, it will get reported as a bug, > or get bad ratings etc. On these kinds of devices, there is a *stong* > developer incentive to not write battery sucking apps. I'm not sure this is real world, either. Developers can fire up powertop from the command line when their phone isn't idling for as long as it should. But a phone is a consumer device: the average smart phone user just wants to browse the web, get email, go to facebook and play with some cool apps. If one of those cool apps is rogue, they're not really going to know which one or how to find it (and firing up powertop from the command line isn't something which will occur to them as a matter of routine). One of the nice things that suspend blockers actually does is to give the kernel a clear name for the process blocking suspend (and thus consuming power). This allows a nice way to assign power budget to the application and present who's using what in a nice visible form, which does facilitate the reporting of bad apps, even for the non-developer user. James -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
