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

[Kevin Hilman <khilman@deeprootsystems.com>]

tytso@mit.edu writes:

> On Fri, May 14, 2010 at 03:32:58PM -0700, Kevin Hilman wrote:
>> Another likely reason that that there hasn't been an alternate
>> proposal (at least from some of us that are raising concerns) is
>> because we already have a working solution to dynamic, system-wide PM
>> that is 1) already in mainline and 2) shipping on consumer devices
>> with very strict power budgets (as already pointed out in detail by
>> Paul[2].)
>
> The examples cited where the things like the Palm Pre, and the Nokia
> N770/800/810 series.  #1, what works on one embedded
> chipset/architecture might not work on another, 

In my experience with embedded SoCs they are all remarkably similar in
power management capabilities and control.

> and #2, the battery lifetime on the N770 and N800 (both of which I have)
> is **appalling** **bad**.

Appalling bad compared to what?  

What's probably more interesting in terms of rough comparisons is
comparing similar devices with and without opportunistic suspend.  The
Nokia n900 (maemo) and the Moto Droid (android) use the same SoC (TI
OMAP3) and roughly the same kernel (2.6.2[89], although both are
heavily patched from mainline.)

The n900 *never* suspends.  It only uses dynamic PM + CPUidle.
The droid uses opportunistic suspend (as well as dynamic PM + CPUidle)

I don't know of any more objective comparison of the two, but as a
user of both devices I can say that the active usage is basically the
same (around a day) and the idle use is similar as well, even though
the Droid has a slightly bigger battery (1400 mAh vs. 1320 mAh.)  My
own usage suggests the n900 is a bit better in idle time, but I have
not done any measuring or objective tests.  I'm guessing the
difference is probably because the Droid does not use the deepest
off-mode power states either in idle or suspend (IIRC) where the n900
does.  I suspect that if both were using off-mode and had the same
battery, these differences would go away.

While this is not really a scientific comparison, it at least gives a
rough idea.  If using opportunistic suspend was adding noticably
better battery life, I think this would be a different discussion.

> I really don't understand why people are so opposed to merging code
> that works well for a very large set of devices and products.  Just
> because *you* don't need it is not a sufficiently good reason to argue
> for it not be merged.  If you don't want to use it, then don't CONFIG
> it in.

At least for OMAP, I don't consider "config it out" a viable option.

We would like one kernel (in particular one PM core) to be usable for
a broad range of devices: maemo/meego, Android, webOS, Archos, and
whatever else we haven't seen yet.  Having to config in/out something
as important as core PM functionality has other consequences.  It
makes PM-aware driver and subsystem writers (and maintainers) to have
to develop and validate against two different types of PM
functionality.

As co-maintainer of the PM subsystem for an architecture (OMAP) where
people *really* care about power, I don't consider that a viable or
scalable option.

Kevin