Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753432Ab0HISa6 (ORCPT ); Mon, 9 Aug 2010 14:30:58 -0400 Received: from mail.lang.hm ([64.81.33.126]:42933 "EHLO bifrost.lang.hm" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752547Ab0HISa5 (ORCPT ); Mon, 9 Aug 2010 14:30:57 -0400 Date: Mon, 9 Aug 2010 11:28:02 -0700 (PDT) From: david@lang.hm X-X-Sender: dlang@asgard.lang.hm To: "Paul E. McKenney" cc: Alan Cox , "Ted Ts'o" , Felipe Contreras , Brian Swetland , linux-pm@lists.linux-foundation.org, linux-kernel@vger.kernel.org, arve@android.com, mjg59@srcf.ucam.org, pavel@ucw.cz, florian@mickler.org, rjw@sisk.pl, stern@rowland.harvard.edu, peterz@infradead.org, tglx@linutronix.de, menage@google.com, david-b@pacbell.net, James.Bottomley@suse.de, arjan@infradead.org, swmike@swm.pp.se, galibert@pobox.com, dipankar@in.ibm.com Subject: Re: Attempted summary of suspend-blockers LKML thread, take three In-Reply-To: <20100809181638.GI3026@linux.vnet.ibm.com> Message-ID: References: <20100806225453.GA3947@linux.vnet.ibm.com> <20100807061558.GA28087@thunk.org> <20100808155719.GB3635@thunk.org> <20100808213821.GD3635@thunk.org> <20100809112453.77210acc@lxorguk.ukuu.org.uk> <20100809181638.GI3026@linux.vnet.ibm.com> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2420 Lines: 49 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. 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? well bahaved applications (not doing unnecessary wakeups, etc) are well bahaved, no matter what system they are on (explicitly setting allowable timer fuzz is linux specific, but will again help on any system) David Lang -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/