From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Paul E. McKenney" Subject: Re: Attempted summary of suspend-blockers LKML thread, take three Date: Mon, 9 Aug 2010 11:54:47 -0700 Message-ID: <20100809185447.GL3026@linux.vnet.ibm.com> References: <20100807061558.GA28087@thunk.org> <20100808155719.GB3635@thunk.org> <20100808213821.GD3635@thunk.org> <20100809112453.77210acc@lxorguk.ukuu.org.uk> <20100809181638.GI3026@linux.vnet.ibm.com> Reply-To: paulmck@linux.vnet.ibm.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Content-Disposition: inline In-Reply-To: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: linux-pm-bounces@lists.linux-foundation.org Errors-To: linux-pm-bounces@lists.linux-foundation.org To: david@lang.hm Cc: Ted Ts'o , peterz@infradead.org, Brian Swetland , Felipe Contreras , linux-kernel@vger.kernel.org, James.Bottomley@suse.de, galibert@pobox.com, florian@mickler.org, menage@google.com, linux-pm@lists.linux-foundation.org, swmike@swm.pp.se, tglx@linutronix.de, Alan Cox , arjan@infradead.org List-Id: linux-pm@vger.kernel.org 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