Re: [PATCH 0/8] Suspend block api (version 6)

[Kevin Hilman <khilman@deeprootsystems.com>]

Matthew Garrett <mjg@redhat.com> writes:

> On Mon, May 17, 2010 at 09:27:47PM +0200, Vitaly Wool wrote:
>
>> Exactly. The point is, opportunistic suspend doesn't in fact add any
>> value compared to dynamic PM + CPUIdle. It only produces some false
>> impression that one can handle power management right without using
>> dynamic PM. And this false impression is the cause for many really
>> ugly designs (like, for instance, 15 minutes touchscreen inactivity
>> delay before forcibly shutting down the wireless, as it's done in
>> stock Android framework).
>
> Run this (or equivalent code) on an N900 and on an Android. Measure the 
> screen-off power draw on both.
>
> int main() {
> 	int i;
> 	while (1)
> 		i++;
> 	return 0;
> }

This kind of rogue app will also kill my CPU performance.  For rogue
CPU-hog apps, we use _tools_ to find and fix this kind of problem:
top, renice, kill, etc. that use features of the scheduler to find
and/or solve the problem.

For rogue apps that affect PM, what is being proposed is to bypass the
root causes (timers, scheduler, activity, etc.) and just freeze the
apps.

Rogue CPU-hog apps are generally not tolerated.  The problems are
found using tools and fixed (or removed.)  Why should we do any
different for rogue power-hog apps?

Maybe the tools aren't as good for finding power-sucking apps.
Then we should be focusing on the _tools_ instead of masking the
problem.

Kevin