On Thu, Aug 05, 2010 at 05:09:17PM +0100, Mark Brown wrote: > On Thu, Aug 05, 2010 at 08:12:11AM -0700, Paul E. McKenney wrote: > > On Wed, Aug 04, 2010 at 10:18:40PM -0700, david@xxxxxxx wrote: > > > > as for intramentation, the key tool to use to see why a system isn't > > > going to sleep would be powertop, just like on other linux systems. > > > Powertop is indeed an extremely valuable tool, but I am not certain > > that it really provides the information that the Android guys need. > > If I understand Arve's and Brian's posts, here is the scenario that they > > are trying to detect: > > > o Some PM-driving application has a bug in which it fails to > > release a wakelock, thus blocking suspend indefinitely. > > > o This PM-driving application, otherwise being a good citizen, > > blocks. > > > o There are numerous power-oblivious apps running, consuming > > significant CPU. > > Or otherwise doing something power hungry. > > > What the Android developers need to know is that the trusted application > > is wrongly holding a wakelock. Won't powertop instead tell them about > > all the power-oblivious apps? > > Right, and this isn't just information for developers - Android handsets > expose this information to end users (so they can indentify any badly > behaved applications they have installed or otherwise modify their > handset usage if they are disappointed by their battery life). That > said, powertop and similar applications could always be extended to also > include data from wakelocks. Good point!!! Of course, powertop would need to interact with Android's user-level daemon for this to work, but perhaps this could be arranged. (There is a user-level daemon in Android that acquires kernel-level suspend blockers on behalf of applications, so a naive mod to powertop would just finger the user-level daemon.) Thanx, Paul _______________________________________________ linux-pm mailing list linux-pm@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/linux-pm
