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

[Paul E. McKenney]

On Mon, Aug 09, 2010 at 11:28:02AM -0700, david@xxxxxxx 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
--
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/