Re: Attempted summary of suspend-blockers LKML thread, take three

Paul E. McKenney
2010-08-09T18:54:47Z

On Mon, Aug 09, 2010 at 11:28:02AM -0700, david@lang.hm wrote:
> On Mon, 9 Aug 2010, Paul E. McKenney wrote:
>
> >On Mon, Aug 09, 2010 at 11:24:53AM +0100, Alan Cox wrote:
> >
> >[ . . . ]
> >
> >>>would agree that in the ideal world, it would be nice if you could
> >>>have applications that make the correct performance/battery
> >>>utilization tradeoff for devices running on 800 mWh batteries, 94,000
> >>>mWh batteries, and while running on the AC mains. But I don't believe
> >>>that it's likely to be true, and if you want to try to beat up on
> >>>application writers one at a time to be power optimized --- as far as
> >>>I'm concerned, that's an argument *for* suspend blockers, since I'm
> >>>not big believer in plans that begin, "First, you command the tides of
> >>>the sea to go back", King Canute style. :-)
> >>
> >>Suspend blockers drive the system policy part way into the apps, that in
> >>turn makes the apps very vulnerable to change in their environment because
> >>you've specialised them. I am sure that in the Android world it's
> >>considered fine, and that the marketing and business people even like
> >>this binding together - but it doesn't generalise and will blow up in
> >>people's faces in the future.
> >>
> >>To consider your tide analogy - suspend blockers is like trying to
> >>program the waves individually. Show me a suspend blocker aware open
> >>office patch 8)
> >
> >But wouldn't an office suite run as a power-oblivious application on an
> >Android device? After all, office applications do not need to run when
> >the screen is turned off, so these the applications do not need to use
> >suspend blockers. That said, I could easily imagine that significant
> >work would be required to make OpenOffice run on Android, not due to
> >suspend blockers, but rather due to Android's unusual user space.
>
> pick your application if you don't like the example.

I like the office-suite example just fine.

> but also, which android system should the applicaton be written for?
> the phone with a 800maH battery or a larger device with a 94,000maH
> battery?

Does battery size make a difference in this particular case?

> well bahaved applications (not doing unnecessary wakeups, etc) are
> well bahaved, no matter what system they are on

Yep. Your point being what exactly? That all applications should be
required to be power-optimized, and that any technology that automates
energy efficiency should be rejected out of hand? If so, please justify
your position.

> (explicitly setting
> allowable timer fuzz is linux specific, but will again help on any
> system)

Setting aside the question of how timer fuzz will help on non-Linux
systems if timer fuzz is specific to Linux...

Thanx, Paul