Re: Attempted summary of suspend-blockers LKML thread

Mark Brown
2010-08-05T16:09:17Z

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@lang.hm 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.