Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

[Brian Swetland]

On Fri, May 28, 2010 at 5:26 AM, Igor Stoppa <igor.stoppa@xxxxxxxxx> wrote:
> ext Matthew Garrett wrote:
>> On Fri, May 28, 2010 at 10:37:13AM +0100, Alan Cox wrote:
>>> The other vendors appear to be managing nicely without magic blockers. I
>>> conjecture therefore there are other solutions.
>>
>> Actually, no. A badly behaved application will kill the N900's battery
>> life. Nobody else has "managed nicely" - they've just made life harder for
>> application developers and users, which may have something to do with the
>> relative levels of market adoption of Maemo and Android. I'm not aware of
>> any form of resource management framework in MeeGo either, so as far as I
>> know it'll have exactly the same problem.
>
> It's true that a braindead app can kill the battery.
>
> However we provide a version of powertop that is tailored to the N900, there
> is a nokia energy profiler meant to give graphical representation of the
> battery current, there is htop available and you can even get the processor
> activity visualized on the leftmost and rightmost keyboard backlight LEDS,
> when in RD mode and with screen blanked.
>
> I would advice you to not start debating on company strategies, this is not
> the right place.

At a certain point, if one side of the argument is using "N900 / OMAP3
works just fine as is" (which has certainly been the case stated by a
number of folks throughout these discussions), I think it's a little
unrealistic to express shock that somebody argues the opposing point.

I've personally avoided commenting on specific power management issues
or properties of competitive platforms because it can easily be viewed
as rather rude or unprofessional.  (though in theory we all could
benefit from any improvements to the kernel regarding power
management, no?).

I am quite willing to state that on both MSM and OMAP based Android
platforms, we've found that the suspend blocker model allows us to
obtain a lower average power draw than if we don't use it -- Mike Chan
provided some numbers earlier in another thread in the trivial device
idle case, the win is of course much larger in the case of several
poorly behaved apps being active.

I do think that everyone involved agrees that it is beneficial to
educate users and developers in hopes that users will understand that
some apps are non-optimal and developers will be encouraged to write
better apps.

I think we also all agree that striving to obtain the lowest power
state at all times through cpu frequency scaling, runtime pm, drivers
that aggressively clock/power down when idle, etc is a worthy goal.
Some have argued that suspend blockers may deter further development
in these areas, but I think this is unlikely -- power usage while the
device is active and the user is interacting with it is just as
critical as when it's not being used interactively.  We (Android)
certainly pursue aggressive low power optimization in both states.

There appears to be some disagreement in terms of what one should do
in the face of poorly behaved applications.  The Android approach has
been to both gather as much data as possible for education of user and
developer and to mitigate the impact of poorly written apps on
endusers, goals which are aided by the suspend blocker model.

A reality of a mass market device with a completely open and
unrestricted application development and distribution ecosystem is
that there will be plenty of non-optimal apps available to users
(Sturgeon's Law applies everywhere, after all).  Worse yet, many of
these non-optimal apps may be beloved by users for various reasons.  I
think there's value in trying to do the best you can power-wise even
in the face of such horrible foes as the dreaded Bouncing Cows App
that Matthew is fond of citing as an example.

Brian
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/