Attempted summary of suspend-blockers LKML thread
in [Kernel]
|
Prev: [PATCH 6/7] usb: iowarrior: fix misuse of return value of copy_to_user()
Next: Get Back To Me Immediately....
From: Paul E. McKenney on 5 Aug 2010 19:10 On Thu, Aug 05, 2010 at 03:16:51PM -0700, Brian Swetland wrote: > On Thu, Aug 5, 2010 at 3:09 PM, <david(a)lang.hm> wrote: > >> Oops, yea that's actually a really bad example, that's probably > >> something that would be handled by low-power states. �I think the > >> incoming text message example is a good one though. �There seemed to > >> be a focus on user-interaction scale time scales, and I wanted to > >> point out that there are also very short duration time scales to > >> consider as well. > > > > good point, but I do think the short time scales are less common than people > > think. > > > > I'd love to get good examples of them > > > > on my iphone when a text message arrives the phone displays an alert for > > user-interaction times (it even lights the display to show who the message > > is from, and optionally a preview of the message) > > > > so what would wake a phone up from suspend where the phone should go back to > > sleep in under a second? > > Here are some real-world examples from shipped android devices: > - battery gauging happens every 10 minutes, need to wake long enough > to chatter with the 1w interface and make sure the battery is not > exploding > - always on mail/im/calendar/etc sync often has network events that > happen every 5-10 minutes which cause devices to briefly wake up and > return to sleep > - gps tracker app might wake every couple minutes or every n gps > events to log location > - low power audio subsystems can wake you up every 1-4 seconds (pcm) > or 1-4 minutes (mp3) to fetch more data Interesting! So for an mp3 playback, does an Android suspend between data fetches? Thanx, Paul -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Paul E. McKenney on 5 Aug 2010 19:10 On Thu, Aug 05, 2010 at 03:51:35PM -0500, kevin granade wrote: > On Thu, Aug 5, 2010 at 3:31 PM, Paul E. McKenney > <paulmck(a)linux.vnet.ibm.com> wrote: > > On Thu, Aug 05, 2010 at 01:13:31PM -0500, kevin granade wrote: > >> On Thu, Aug 5, 2010 at 10:46 AM, �<david(a)lang.hm> wrote: > >> > On Thu, 5 Aug 2010, Paul E. McKenney wrote: > >> > > >> >> On Wed, Aug 04, 2010 at 10:18:40PM -0700, david(a)lang.hm wrote: > >> >>> > >> >>> On Wed, 4 Aug 2010, Paul E. McKenney wrote: > >> >>>> > >> >>>> On Wed, Aug 04, 2010 at 05:25:53PM -0700, david(a)lang.hm wrote: > >> >>>>> > >> >>>>> On Wed, 4 Aug 2010, Paul E. McKenney wrote: > >> >> > >> >> [ . . . ] > >> >> > >> >>>>>> The music player is an interesting example. �It would be idle most > >> >>>>>> of the time, given that audio output doesn't consume very much CPU. > >> >>>>>> So you would not want to suspend the system just because there were > >> >>>>>> no runnable processes. �In contrast, allowing the music player to > >> >>>>>> hold a wake lock lets the system know that it would not be appropriate > >> >>>>>> to suspend. > >> >>>>>> > >> >>>>>> Or am I misunderstanding what you are proposing? > >> >>>>> > >> >>>>> the system would need to be idle for 'long enough' (configurable) > >> >>>>> before deciding to suspend, so as long as 'long enough' is longer > >> >>>>> than the music player is idle this would not be a problem. > >> >>>> > >> >>>> From a user standpoint, having the music player tell the system when > >> >>>> it is OK to suspend (e.g., when the user has paused playback) seems > >> >>>> a lot nicer than having configurable timeouts that need tweaking. > >> >>> > >> >>> every system that I have seen has a configurable "sleep if it's idle > >> >>> for this long" knob. On the iphone (work issue, I didn't want it) > >> >>> that I am currently using it can be configured from 1 min to 5 min. > >> >>> > >> >>> this is the sort of timeout I am talking about. > >> >>> > >> >>> with something in the multi-minute range for the 'do a full suspend' > >> >>> doing a wakeup every few 10s of seconds is perfectly safe. > >> >> > >> >> Ah, I was assuming -much- shorter "do full suspend" timeouts. > >> >> > >> >> My (possibly incorrect) assumption is based on the complaint that led > >> >> to my implementing RCU_FAST_NO_HZ. �A (non-Android) embedded person was > >> >> quite annoyed (to put it mildly) at the earlier version of RCU because > >> >> it prevented the system from entering the power-saving dyntick-idle mode, > >> >> not for minutes, or even for seconds, but for a handful of -milliseconds-. > >> >> This was my first hint that "energy efficiency" means something completely > >> >> different in embedded systems than it does in the servers that I am > >> >> used to. > >> >> > >> >> But I must defer to the Android guys on this -- who knows, perhaps > >> >> multi-minute delays to enter full-suspend mode are OK for them. > >> > > >> > if the system was looking at all applications I would agree that the timeout > >> > should be much shorter. > >> > > >> > I have a couple devices that are able to have the display usable, even if > >> > the CPU is asleep (the OLPC and the Kindle, two different display > >> > technologies). With these devices I would like to see the suspend happen so > >> > fast that it can suspend between keystrokes. > >> > > >> > 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 > >> > >> 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 would be good to get some sort of range for the "timeout". �In the > > audio-output case, my understanding that the spacing between bursts of > > audio-processing activity is measured in some hundreds of milliseconds, > > in which case one would want the delays until suspend to be on the > > millisecond scale. �But does Android really suspend between bursts of > > audio processing while playing music? �Very cool if so! �;-) > > Oops, yea that's actually a really bad example, that's probably > something that would be handled by low-power states. I think the > incoming text message example is a good one though. There seemed to > be a focus on user-interaction scale time scales, and I wanted to > point out that there are also very short duration time scales to > consider as well. > > *back to lurking* I really don't know the answer myself, so I was really asking the question rather than trying to catch you out. Thanx, Paul > Kevin > > > > > � � � � � � � � � � � � � � � � � � � � � � � � � � � �Thanx, Paul > > > >> >>>>>>> if the backlight being on holds the wakelock, it would seem that > >> >>>>>>> almost every other use of the wakelock could (and probably should) > >> >>>>>>> be replaced by something that tickles the display to stay on longer. > >> >>>>>> > >> >>>>>> The problem with this approach is that the display consumes quite a > >> >>>>>> bit of power, so you don't want to leave it on unnecessarily. �So if > >> >>>>>> the system is doing something (for example, playing music) that does > >> >>>>>> not require the display, you really want the display to be off. > >> >>>>> > >> >>>>> what percentage (and types) of apps are really useful with the > >> >>>>> display off. I think that there are relativly few apps that you > >> >>>>> really want to keep running if the display is off. > >> >>>> > >> >>>> The length of time those apps are running is the governing factor > >> >>>> for battery life, and not the number of such apps, right? > >> >>> > >> >>> correct, but the number of such apps indicates the scope of the problem. > >> >> > >> >> The number of such apps certainly indicates the amount of effort required > >> >> to modify them, if required. �Is that what you are getting at? > >> > > >> > yes. > >> > > >> >>>> From another e-mail tonight it sounds like almost everything > >> >>>> already talks > >> >>> > >> >>> to a userspace daemon, so if "(the power management service in the > >> >>> system_server, possibly the media_server and the radio interface > >> >>> glue)" (plus possibly some kernel activity) are the only things > >> >>> looked at when considering if it's safe to sleep or not, all of > >> >>> these can (or already do) do 'something' every few seconds, making > >> >>> this problem sound significantly smaller than it sounded like > >> >>> before. > >> >>> > >> >>> Android could even keep it's user-space API between the system power > >> >>> daemon and the rest of userspace the same if they want to. > >> >>> > >> >>> over time, additional apps could be considered 'trusted' (or flagged > >> >>> that way by the user) and not have to interact with the power daemon > >> >>> to keep things alive. > >> >> > >> >> Hmmm... �Isn't it the "trusted" (AKA PM-driving) apps that interact with > >> >> the power daemon via suspend blockers, rather than the other way around? > >> > > >> > I was looking at it from a kernel point of view, "trusted" (AKA PM-driving) > >> > apps are ones that have permission to grab the wakelock. Any app/daemon that > >> > is so trusted can communicate with anything else in userspace as part of > >> > making it's decision on whento take the wakelock, but those other > >> > applications would not qualify as "trusted" in my eyes. > >> > > >> >>> as for intramentation, the key tool to use to see why a system isn't > >> >>> going to sleep would be powertop, just like on other linux systems. > >> >> > >> >> Powertop is indeed an extremely valuable tool, but I am not certain > >> >> that it really provides the information that the Android guys need. > >> >> If I understand Arve's and Brian's posts, here is the scenario that they > >> >> are trying to detect: > >> >> > >> >> o � � � Some PM-driving application has a bug in which it fails to > >> >> � � � �release a wakelock, thus blocking suspend indefinitely. > >> >> > >> >> o � � � This PM-driving application, otherwise being a good citizen, > >> >> � � � �blocks. > >> >> > >> >> o � � � There are numerous power-oblivious apps running, consuming > >> >> � � � �significant CPU. > >> >> > >> >> What the Android developers need to know is that the trusted application > >> >> is wrongly holding a wakelock. �Won't powertop instead tell them about > >> >> all the power-oblivious apps? > >> > > >> > in my proposal (without a wakelock), powertop would tell you what > >> > applications are running and setting timers. If we can modify the > >> > kernel/suspend decision code to only look at processes in one cgroup when > >> > deciding if the system should go to sleep, a similar modification to > >> > poewrtop should let you only show stats on the "trusted" applications. > >> > > >> > If you have a userspace power management daemon that accepts requests from > >> > untrusted programs and does something to keep the system from sleeping > >> > (either taking a wakelock or setting a 'short' timer), it needs to keep the > >> > records of this itself because otherwise all the kernel will see (with > >> > either powertop or wakelock reporting) is that the power management daemon > >> > is what kept the system from sleeping. > >> > > >> > David Lang > >> > -- > >> > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > >> > the body of a message to majordomo(a)vger.kernel.org > >> > More majordomo info at �http://vger.kernel.org/majordomo-info.html > >> > Please read the FAQ at �http://www.tux.org/lkml/ > >> > > > > -- > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majordomo(a)vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Paul E. McKenney on 5 Aug 2010 19:20 On Thu, Aug 05, 2010 at 01:26:18PM -0700, david(a)lang.hm wrote: > On Thu, 5 Aug 2010, kevin granade wrote: > > >On Thu, Aug 5, 2010 at 10:46 AM, <david(a)lang.hm> wrote: > >>On Thu, 5 Aug 2010, Paul E. McKenney wrote: > >> > >>>On Wed, Aug 04, 2010 at 10:18:40PM -0700, david(a)lang.hm wrote: > >>>> > >>>>On Wed, 4 Aug 2010, Paul E. McKenney wrote: > >>>>> > >>>>>On Wed, Aug 04, 2010 at 05:25:53PM -0700, david(a)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. ;-) Thanx, Paul -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Rafael J. Wysocki on 5 Aug 2010 19:50 On Friday, August 06, 2010, Arve Hj�nnev�g wrote: > 2010/8/5 Rafael J. Wysocki <rjw(a)sisk.pl>: > > On Thursday, August 05, 2010, Arve Hj�nnev�g wrote: > >> 2010/8/4 Rafael J. Wysocki <rjw(a)sisk.pl>: > >> > On Thursday, August 05, 2010, Arve Hj�nnev�g wrote: > >> >> On Wed, Aug 4, 2010 at 1:56 PM, Matthew Garrett <mjg59(a)srcf.ucam.org> wrote: > >> >> > On Wed, Aug 04, 2010 at 10:51:07PM +0200, Rafael J. Wysocki wrote: > >> >> >> On Wednesday, August 04, 2010, Matthew Garrett wrote: > >> >> >> > No! And that's precisely the issue. Android's existing behaviour could > >> >> >> > be entirely implemented in the form of binary that manually triggers > >> >> >> > suspend when (a) the screen is off and (b) no userspace applications > >> >> >> > have indicated that the system shouldn't sleep, except for the wakeup > >> >> >> > event race. Imagine the following: > >> >> >> > > >> >> >> > 1) The policy timeout is about to expire. No applications are holding > >> >> >> > wakelocks. The system will suspend providing nothing takes a wakelock. > >> >> >> > 2) A network packet arrives indicating an incoming SIP call > >> >> >> > 3) The VOIP application takes a wakelock and prevents the phone from > >> >> >> > suspending while the call is in progress > >> >> >> > > >> >> >> > What stops the system going to sleep between (2) and (3)? cgroups don't, > >> >> >> > because the voip app is an otherwise untrusted application that you've > >> >> >> > just told the scheduler to ignore. > >> >> >> > >> >> >> I _think_ you can use the just-merged /sys/power/wakeup_count mechanism to > >> >> >> avoid the race (if pm_wakeup_event() is called at 2)). > >> >> > > >> >> > Yes, I think that solves the problem. The only question then is whether > >> >> > >> >> How? By passing a timeout to pm_wakeup_event when the network driver > >> >> gets the packet or by passing 0. If you pass a timeout it is the same > >> >> as using a wakelock with a timeout and should work (assuming the > >> >> timeout you picked is long enough). If you don't pass a timeout it > >> >> does not work, since the packet may not be visible to user-space yet. > >> > > >> > Alternatively, pm_stay_awake() / pm_relax() can be used. > >> > > >> > >> Which makes the driver and/or network stack changes identical to using > >> wakelocks, right? > > > > Please refer to the Matthew's response. > > > >> >> > it's preferable to use cgroups or suspend fully, which is pretty much up > >> >> > to the implementation. In other words, is there a reason we're still > >> >> > >> >> I have seen no proposed way to use cgroups that will work. If you > >> >> leave some processes running while other processes are frozen you run > >> >> into problems when a frozen process holds a resource that a running > >> >> process needs. > >> >> > >> >> > >> >> > having this conversation? :) It'd be good to have some feedback from > >> >> > Google as to whether this satisfies their functional requirements. > >> >> > > >> >> > >> >> That is "this"? The merged code? If so, no it does not satisfy our > >> >> requirements. The in kernel api, while offering similar functionality > >> >> to the wakelock interface, does not use any handles which makes it > >> >> impossible to get reasonable stats (You don't know which pm_stay_awake > >> >> request pm_relax is reverting). > >> > > >> > Why is that a problem (out of curiosity)? > >> > > >> > >> Not having stats or not knowing what pm_relax is undoing? We need > >> stats to be able to debug the system. > > > > You have the stats in struct device and they are available via sysfs. > > I suppose they are insufficient, but I'd like to know why exactly. > > > > Our wakelock stats currently have > (name,)count,expire_count,wake_count,active_since,total_time,sleep_time,max_time > and last_change. Not all of these are equally important (total_time is > most important followed by active_since), but you only have count. > Also as discussed before, many wakelocks/suspendblockers are not > associated with a struct device. OK How much of that is used in practice and what for exactly? Do you _really_ have to debug the wakelocks in drivers that much? > >> If the system does not suspend > >> at all or is awake for too long, the wakelock stats tells us which > >> component is at fault. Since pm_stay_awake and pm_relax does not > >> operate on a handle, you cannot determine how long it prevented > >> suspend for. > > > > Well, if you need that, you can add a counter of "completed events" into > > We need more than that (see above). > > > struct dev_pm_info and a function similar to pm_relax() that > > will update that counter. I don't think anyone will object to that change. > > > > What about adding a handle that is passed to all three functions? I don't think that will fly at this point. > >> >> The proposed in user-space interface > >> >> of calling into every process that receives wakeup events before every > >> >> suspend call > >> > > >> > Well, you don't really need to do that. > >> > > >> > >> Only if the driver blocks suspend until user-space has read the event. > >> This means that for android to work we need to block suspend when > >> input events are not processed, but a system using your scheme needs a > >> pm_wakeup_event call when the input event is queued. How to you switch > >> between them? Do we add separate ioctls in the input device to enable > >> each scheme? If someone has a single threaded user space power manager > >> that also reads input event it will deadlock if you block suspend > >> until it reads the input events since you block when reading the wake > >> count. > > > > Well, until someone actually tries to implement a power manager in user space > > it's a bit vague. > > > > Not having clear rules for what the drivers should do is a problem. > The comments in your code seem to advocate using timeouts instead of > overlapping pm_stay_awake/pm_relax sections. I find this > recommendation strange given all the opposition to > wakelock/suspendblocker timeouts. There's no recommendation either way. > But more importantly, calling > pm_wakeup_event with a timeout of 0 is incompatible with the android > user space code, Which I don't find really relevant, sorry. > and I would prefer that the kernel interfaces would > encourage drivers to block suspend until user space has consumed the > event, which works for the android user space, instead of just long > enough to work with a hypothetical user space power manager. Well, that are your personal preferences, which I respect. I also have some personal preferences that are not necessarily followed by the kernel code. Thanks, Rafael -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Brian Swetland on 5 Aug 2010 20:20
On Thu, Aug 5, 2010 at 4:03 PM, Paul E. McKenney <paulmck(a)linux.vnet.ibm.com> wrote: >> > so what would wake a phone up from suspend where the phone should go back to >> > sleep in under a second? >> >> Here are some real-world examples from shipped android devices: >> - battery gauging happens every 10 minutes, need to wake long enough >> to chatter with the 1w interface and make sure the battery is not >> exploding >> - always on mail/im/calendar/etc sync often has network events that >> happen every 5-10 minutes which cause devices to briefly wake up and >> return to sleep >> - gps tracker app might wake every couple minutes or every n gps >> events to log location >> - low power audio subsystems can wake you up every 1-4 seconds (pcm) >> or 1-4 minutes (mp3) to fetch more data > > Interesting! > > So for an mp3 playback, does an Android suspend between data fetches? It can if the latency is long enough (which is why I point out low power audio which is usually high latency). For low latency (system sounds, etc) 10-25ms between buffers it's not practical to fully suspend but we will go to the lowest power state in idle if possible. Brian -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ |