[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20090217152811.GA12686@bulgaria.corp.google.com>
Date: Tue, 17 Feb 2009 07:28:11 -0800
From: Brian Swetland <swetland@...gle.com>
To: Arjan van de Ven <arjan@...radead.org>
Cc: Matthew Garrett <mjg59@...f.ucam.org>,
"Rafael J. Wysocki" <rjw@...k.pl>,
"Woodruff, Richard" <r-woodruff2@...com>,
Alan Stern <stern@...land.harvard.edu>,
Kyle Moffett <kyle@...fetthome.net>,
Oliver Neukum <oliver@...kum.org>,
Benjamin Herrenschmidt <benh@...nel.crashing.org>,
pm list <linux-pm@...ts.linux-foundation.org>,
LKML <linux-kernel@...r.kernel.org>,
Arve Hjønnevåg <arve@...roid.com>,
Pavel Machek <pavel@....cz>,
Nigel Cunningham <nigel@...el.suspend2.net>,
mark gross <mgross@...ux.intel.com>,
Uli Luckas <u.luckas@...d.de>,
Igor Stoppa <igor.stoppa@...ia.com>,
Len Brown <lenb@...nel.org>
Subject: Re: [RFD] Automatic suspend
[Arjan van de Ven <arjan@...radead.org>]
> On Tue, 17 Feb 2009 06:20:01 -0800
> Brian Swetland <swetland@...gle.com> wrote:
>
> > Of course that still doesn't address userspace. Aggressively going to
> > suspend lets us compensate for userspace programs that do somewhat
> > silly things (I agree that it would be best if they didn't but they
> > do and getting *everyone* to write their userspace code to avoid
> > spinning or avoid waking up on short-duration timers to poll is a
> > losing battle).
>
> actually with powertop... on the open source side things are actually
> won. It took all of 6 months...
> I don't see that as a valid excuse. In fact, if this kind of solution
> makes real userspace scheduled timers to be missed then I consider it a
> serious functionality misfeature.
While you can't expect the kernel to solve all the problems of
userspace, here's the broad situation one could end up in
(note this specific sequence is generic and not based on any one
specific product experience):
- carrier deploys a device
- carrier agrees to allow installation of arbitrary third party apps
without some horrible certification program requiring app authors
to jump through hoops, wait ages for approval, etc
- users rejoice and install all kinds of apps
- some apps are poorly written and impact battery life
- users complain to carrier about battery life
You will end up with some crappy apps that do really dumb things.
However, even if they're badly written users may still install and use
these apps because hey, they do something the user likes.
>From the Android standpoint, we're trying to balance protecting the
system from poorly designed apps and somehow letting the user know "hey
app X is chewing up a lot of power" (work in progress on this).
While I'd love for every app developer to actively tune their apps for a
good mobile experience, I am skeptical that this is going to happen.
Brian
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists