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: david on 5 Aug 2010 16:40 On Thu, 5 Aug 2010, Brian Swetland wrote: > On Thu, Aug 5, 2010 at 11:13 AM, kevin granade <kevin.granade(a)gmail.com> wrote: >> 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. > > The display being on should not prevent suspend unless the particular > platform is incapable of suspending while the display is on. if that is the case, I'll go back to my question about the untrusted reader app. what is it that will prevent the system from going to sleep while I am reading the page? >> 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. > > Yeah, we much prefer the wakelock model where the moment the resource > (system-needing-to-not-be-suspended) is released we return to the > lowest power state, rather than waiting for a timer to expire (and/or > burning cycles polling for "can we suspend yet?" when we're definitely > not ready to suspend). at the micro level it is definantly better for power, but at the macro level I don't think it needs to make much difference in the overall battery life of the device. To borrow a phrase, I think you may be into premature optimization of power :-) David Lang
From: kevin granade on 5 Aug 2010 17:00 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* 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/
From: Arve Hjønnevåg on 5 Aug 2010 18:10 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. >> 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? >> >> 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. But more importantly, calling pm_wakeup_event with a timeout of 0 is incompatible with the android user space code, 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. -- Arve Hj�nnev�g -- 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 18:20 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 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/
From: david on 5 Aug 2010 18:20
On Thu, 5 Aug 2010, 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: >>>> >>>>> >>>>> [ . . . ] >>>>> >>>>> >>>>> 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. 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? David Lang |