Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S935012Ab0HFRYR (ORCPT ); Fri, 6 Aug 2010 13:24:17 -0400 Received: from e6.ny.us.ibm.com ([32.97.182.146]:47634 "EHLO e6.ny.us.ibm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S933884Ab0HFRYO (ORCPT ); Fri, 6 Aug 2010 13:24:14 -0400 Date: Fri, 6 Aug 2010 10:24:09 -0700 From: "Paul E. McKenney" To: david@lang.hm Cc: kevin granade , Arve =?iso-8859-1?B?SGr4bm5lduVn?= , Matthew Garrett , "Rafael J. Wysocki" , Arjan van de Ven , linux-pm@lists.linux-foundation.org, linux-kernel@vger.kernel.org, pavel@ucw.cz, florian@mickler.org, stern@rowland.harvard.edu, swetland@google.com, peterz@infradead.org, tglx@linutronix.de, alan@lxorguk.ukuu.org.uk Subject: Re: Attempted summary of suspend-blockers LKML thread Message-ID: <20100806172409.GI2432@linux.vnet.ibm.com> Reply-To: paulmck@linux.vnet.ibm.com References: <20100805001716.GO24163@linux.vnet.ibm.com> <20100805004802.GP24163@linux.vnet.ibm.com> <20100805151211.GA10080@linux.vnet.ibm.com> <20100805231936.GS2447@linux.vnet.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 6314 Lines: 145 On Fri, Aug 06, 2010 at 01:29:57AM -0700, david@lang.hm wrote: > On Thu, 5 Aug 2010, Paul E. McKenney wrote: > > >On Thu, Aug 05, 2010 at 01:26:18PM -0700, david@lang.hm wrote: > >>On Thu, 5 Aug 2010, kevin granade wrote: > >> > >>>On Thu, Aug 5, 2010 at 10:46 AM, wrote: > >>>>On Thu, 5 Aug 2010, Paul E. McKenney wrote: > >>>> > >>>>>On Wed, Aug 04, 2010 at 10:18:40PM -0700, david@lang.hm wrote: > >>>>>> > >>>>>>On Wed, 4 Aug 2010, Paul E. McKenney wrote: > >>>>>>> > >>>>>>>On Wed, Aug 04, 2010 at 05:25:53PM -0700, david@lang.hm wrote: > >>>>>>>> > >>>>>>>>On Wed, 4 Aug 2010, Paul E. McKenney wrote: > >>>>> > >>>>>[ . . . ] > >>>>> > >>>>however, in the case of Android I think the timeouts have to end up being > >>>>_much_ longer. Otherwise you have the problem of loading an untrusted book > >>>>reader app on the device and the device suspends while you are reading the > >>>>page. > >>>> > >>>>currently Android works around this by having a wakelock held whenever the > >>>>display is on. This seems backwards to me, the display should be on because > >>>>the system is not suspended, not the system is prevented from suspending > >>>>because the display is on. > >>>> > >>>>Rather than having the display be on causing a wavelock to be held (with the > >>>>code that is controls the display having a timeout for how long it leaves > >>>>the display on), I would invert this and have the timeout be based on system > >>>>activity, and when it decides the system is not active, turn off the display > >>>>(along with other things as it suspends) > >>> > >>>IIRC, this was a major point of their (Android's) power management > >>>policy. User input of any kind would reset the "display active" > >>>timeout, which is the primary thing keeping random untrusted > >>>user-facing programs from being suspended while in use. They seemed > >>>to consider this to be a special case in their policy, but from the > >>>kernel's point of view it is just another suspend blocker being held. > >>> > >>>I'm not sure this is the best use case to look at though, because > >>>since it is user-facing, the timeout durations are on a different > >>>scale than the ones they are really worried about. I think another > >>>category of use case that they are worried about is: > >>> > >>>(in suspend) -> wakeup due to network -> process network activity -> suspend > >>> > >>>or an example that has been mentioned previously: > >>> > >>>(in suspend) -> wakeup due to alarm for audio processing -> process > >>>batch of audio -> suspend > >> > >>when you suspend the audio will shut off, so it's sleep ->wake -> > >>sleep, not suspend > >> > >>>In both of these cases, the display may never power on (phone might > >>>beep to indicate txt message or email, audio just keeps playing), so > >>>the magnitude of the "timeout" for suspending again should be very > >>>small. Specifically, they don't want there to be a timeout at all, so > >>>as little time as possible time is spent out of suspend in addition to > >>>the time required to handle the event that caused wakeup. > >> > >>it really depnds on the frequency of the wakeups. > >> > >>if you get a network packet once every 5 min and need to wake to > >>process it, staying awake for 20 seconds after finishing procesing > >>is FAR more significant than if you get a network packet once every > >>hour. It's not just the factor of 20 that simple math would indicate > >>because the time in suspend eats power as well. > >> > >>I don't know real numbers, so these are made up for this example > >> > >>if suspend (with the cell live to receive packets) is 10ma average > >>current and full power is 500ma average current > >> > >>packets every 5 min with .1 sec wake time will eat ~13maH per hour > >> > >>packets every 5 min with 10 second wake time will eat ~37maH per hour > >> > >>packets every hour with .1 sec wake time will eat ~10maH per hour > >> > >>packets every hour with 10 sec wake time will eat ~11maH per hour > >> > >>so if you have frequent wakeups, staying awake 100 times as long > >>will cut your battery life to 1/3 what it was before. > >> > >>if your wakeups are rare, it's about a 10% hit to stay awake 100 > >>times as long. > >> > >>there is a lot of room for tuning the timeouts here. > > > >Especially given different scenarios, for example, audio playback > >when the device is in airplane mode. ;-) > > hmm, I've been thinking and talking in terms of two classes of > cgroups, trusted and untrusted. I wonder if it would be possible to > set timeouts for each cgroup instead) > > the system would go to sleep IFF all cgroups have been idle longer > than the idle time (with -1 idle time being 'ignore this cgroup') > > if this could be done you could set longer times for things designed > for user-interaction than you do for other purposes. > > you could set media to 0 idle time (so that as soon as it finishes > processing the system can sleep until the next timer) > > to do this, the code making the decision would have to be able to > find out the following fairly cheaply. > > 1. for this cgroup, what was the last time something ran > > 2. for this cgroup, what is the next timer set > > it would be nice to get network traffic/connection stats. > > so two questions. > > first, what else would you need to get accumulated for the cgroup > > second, is there a fairly easy way to have these stats available? > > for the 'last time it ran' stat, this seems like you could have a > per-cpu variable per cgroup that's fairly cheap to update, but you > would need to take a global lock to read accuratly (the lock may be > expensive enough that it's worth trying to read the variables from > the other cpu without a lock, just to see if it's remotely possible > to sleep/suspend) > > with timers, is it possible to have multiple timer wheels (one per > cgroup)? I apologize in advance for what I am about to write, but... If you continue in this vein, you are likely to make suspend blockers look very simple and natural. ;-) Thanx, Paul -- 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/