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: Florian Mickler on 4 Aug 2010 02:20 On Tue, 3 Aug 2010 21:55:07 -0700 (PDT) david(a)lang.hm wrote: > On Tue, 3 Aug 2010, Arjan van de Ven wrote: > > > On Tue, 3 Aug 2010 17:10:15 -0700 > > "Paul E. McKenney" <paulmck(a)linux.vnet.ibm.com> wrote: > >> > >> OK, I'll bite... > >> > >>> From an Android perspective, the differences are as follows: > >> > >> 1. Deep idle states are entered only if there are no runnable > >> tasks. In contrast, opportunistic suspend can happen even when there > >> are tasks that are ready, willing, and able to run. > > > > for "system suspend", this is an absolutely valid statement. > > for "use suspend as idle state", it's not so clearly valid. > > (but this is sort of a separate problem, basically the "when do we > > freeze the tasks that we don't like for power reasons" problem, > > which in first order is independent on what kind of idle power state > > you pick, and discussed extensively elsewhere in this thread) > > note that what I'm speculating about would never freeze some of the tasks, > it would run everything if anything is run, but it would not consider the > actions of some of the programs when deciding if it can shutdown. > > so if you have all your privilaged applications in long sleeps, but still > have your bouncing cows running, peggng the CPU, making noise, and > updating the screen, the system would decide the system is 'idle' and go > into the 'suspend' low power state until there is a wake activity. > > but if you have a privilaged application doing other stuff (say you are > talking on the phone, have a GPS mapping program running and giving you > directions, etc), the bouncing cows would continue to run and there would > never be an attempt to freeze them while leaving the other stuff active. > > David Lang I think the only difference between your proposition and the current android practice is that in your scheme the partition is along the process/task boundary (i.e. good apps vs bad apps) whereas the android looks at actions or events or ... let's call it "stuff" and blocks suspend whenever "stuff" needs to be done. The main thing is that even an process that is allowed to block suspend doesn't do so all the time. Only when it is critical that "stuff" get's done right away. One way to make an application work the same way with your scheme (as I understand it) on android could be to split the application into an "blocker" part, that is not part of the "ignore-cgroup" (the "trusted" part) and another one that is in the "ignore-cgroup" (the "untrusted" part). Whenever the untrusted part needs to block suspend it notices the "trusted" part via ipc and the trusted part goes into some sort of "activity loop". This looks kind of stupid. But I bet it is what application developers are going to do if there is no provision for a flexible runtime enable/disable "suspend blocker". hmmm... Cheers, Flo -- 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: Olivier Galibert on 4 Aug 2010 02:30 On Tue, Aug 03, 2010 at 11:03:15PM -0700, Arve Hj�nnev�g wrote: > 2010/8/3 Olivier Galibert <galibert(a)pobox.com>: > > On Tue, Aug 03, 2010 at 08:39:22PM -0700, Arve Hj�nnev�g wrote: > >> If you just program the alarm you will wake up see that the monotonic > >> clock has not advanced and set the alarm another n seconds into the > >> future. Or are proposing that suspend should be changed to keep the > >> monotonic clock running? > > > > You're supposed to fix the clock after you wake up. �That's part of > > the cost of going suspend. > > I'm not sure what you are referring to. The generic Linux timekeeping > code makes sure the monotonic clock stops while the system is > suspended regardless of what values the (hardware specific) > clocksource returns. That just means the android-like suspend should not act in that specific area the same as the generic suspend to ram. Which is not entirely surprising. In any case, it's not "keep the monotonic clock running", which would cost power. It's fix it up afterwards, using the same means you already do but perhaps at a higher level currently. People don't want to see the wrong time of the day just because the phone went to suspend. Laptop STR is different in perception because it shuts down things people don't want to see shutdown just by being idle, namely wifi connectivity. If your next polling timer is in half an hour and the screen/touchpad are off, you want to go as low in power as possible until then, and that's the deepest level of idle you can find that responds to alarms which may happen to be called suspend. But from a user point of view, it's just another idle level. And from a power management code/policy decisions point of view, it should be the same. OG. -- 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 4 Aug 2010 02:40 On Tue, 3 Aug 2010, Arve Hj?nnev?g wrote: > 2010/8/3 <david(a)lang.hm>: >> On Tue, 3 Aug 2010, Arve Hj?nnev?g wrote: >> >>> On Tue, Aug 3, 2010 at 5:51 PM, �<david(a)lang.hm> wrote: >>>> >>>> On Tue, 3 Aug 2010, Paul E. McKenney wrote: >>>> >>>>> OK, I'll bite... >>>> >>>> thanks, this is not intended to be a trap. >>>> >>>>> From an Android perspective, the differences are as follows: >>>>> >>>>> 1. ? ? ?Deep idle states are entered only if there are no runnable >>>>> tasks. >>>>> ? ? ? ?In contrast, opportunistic suspend can happen even when there >>>>> ? ? ? ?are tasks that are ready, willing, and able to run. >>>> >>>> Ok, this is a complication to what I'm proposing (and seems a little odd, >>>> but I can see how it can work), but not neccessarily a major problem. it >>>> depends on exactly how the decision is made to go into low power states >>>> and/or suspend. If this is done by an application that is able to look at >>>> either all activity or ignore one cgroup of processes at different times >>>> in >>>> it's calculations than this would work. >>>> >>>>> 2. ? ? ?There can be a set of input events that do not bring the system >>>>> ? ? ? ?out of suspend, but which would bring the system out of a deep >>>>> ? ? ? ?idle state. ?For example, I believe that it was stated that one >>>>> ? ? ? ?of the Android-based smartphones ignores touchscreen input while >>>>> ? ? ? ?suspended, but pays attention to it while in deep idle states. >>>> >>>> I see this as simply being a matter of what devices are still enabled at >>>> the >>>> different power savings levels. At one level the touchscreen is still >>>> powered, while at another level it isn't, and at yet another level you >>>> have >>>> to hit the power soft-button. This isn't fundamentally different from >>>> powering off a USB peripheral that the system decides is idle (and then >>>> not >>>> seeing input from it until something else wakes the system) >>> >>> The touchscreen on android devices is powered down long before we >>> suspend, so that is not a good example. There is still a significant >>> difference between suspend and idle though. In idle all interrupts >>> work, in suspend only interrupts that the driver has called >>> enable_irq_wake on will work (on platforms that support it). >> >> are you talking about Android here or are you talking genricly across all >> platforms? >> > > This appears to be the current Linux driver model. Old platform code > hardcoded the wakeup interrupts. not quite the question I was trying (and failing) to ask, but from the answer it sounds like setting suspend to wake up on all interrupts is the same as idle. so here suspend is looking like just a variation of low-power idle (different wakeup criteria) >>>>> 3. ? ? ?The system comes out of a deep idle state when a timer >>>>> ? ? ? ?expires. ?In contrast, timers cannot expire while the >>>>> ? ? ? ?system is suspended. ?(This one is debatable: some people >>>>> ? ? ? ?argue that timers are subject to jitter, and the suspend >>>>> ? ? ? ?case for timers is the same as that for deep idle states, >>>>> ? ? ? ?but with unbounded timer jitter. ?Others disagree. ?The >>>>> ? ? ? ?resulting discussions have produced much heat, but little >>>>> ? ? ? ?light. ?Such is life.) >>>> >>>> if you have the ability to wake for an alarm, you have the ability to >>>> wake >>>> for a timer (if from no other method than to set the alarm to when the >>>> timer >>>> tick would go off) >>>> >>> >>> If you just program the alarm you will wake up see that the monotonic >>> clock has not advanced and set the alarm another n seconds into the >>> future. Or are proposing that suspend should be changed to keep the >>> monotonic clock running? If you are, why? We can enter the same >>> hardware states from idle, and modifying suspend to wake up more often >>> would increase the average power consumption in suspend, not improve >>> it for idle. In other words, if suspend wakes up as often as idle, why >>> use suspend? >> >> no, I was thinking that you set the alarm to go off, and when it goes off >> and wakes you up, you correct other local clocks before doing anything else. >> >> even if they wake up at the same time, you would use suspend instead of idle >> if it saved more power (allowing for the power to get in and out of suspend >> vs the power to get in and out of idle) > > Suspend and idle use the same power state on the devices we shipped. > The power saving we get from suspend if from ignoring the timers. Ok, so if you set the alarm to the next time the timer for a privilaged task would run and wake up then to be completely transparent to the privilaged task, or you could decide to disable the timers as well again, this looks like suspend and idle are very closely related. >> in this case, another reason you would consider using suspend over idle is >> that you can suspend until the next timer that your privilaged applications >> have set, and skip timers set by the non-privilaged applications, resulting >> in more time asleep. > > Without wakelock or suspend blockers this can still break since a > privileged application may be waiting on a resource held by a > non-privileged application. since the non-privilaged application is never frozen when a privilaged application is running, I'm not sure how you would get this to happen that wouldn't also be a problem with wakelocks. if you want to have a privilaged application keep the system awake while it waits for a non-privilaged application, all it would need to do is to set a timer near enough in the future that it's considered 'awake' all the time. this will cost a context switch every timeout period (for the application to check that it's still waiting and set the next timer), but that's pretty cheap. one thing this would destroy is the stats currently built around the wakelock, but since they would be replaced by stats of exactly the type of thing that powertop was written to deal with, I don't see this as a problem (powertop would just have to learn a mode where it ignores the non-privilaged tasks).consolodating tools is a good thing. >>>>> There may well be others. >>>>> >>>>> Whether these distinctions are a good thing or a bad thing is one of >>>>> the topics of this discussion. ?But the distinctions themselves are >>>>> certainly very real, from what I can see. >>>>> >>>>> Or am I missing your point? >>>> >>>> these big distinction that I see as significant seem to be in the >>>> decision >>>> of when to go into the different states, and the difference between the >>>> states ?themselves seem to be less significant (and either very close to, >>>> or >>>> within the variation that already exists for power saving modes) >>>> >>>> If I'm right bout this, then it would seem to simplify the concept and >>>> change it from some really foreign android-only thing into a special case >>>> variation of existing core concepts. >>> >>> Suspend is not an android only concept. The android extensions just >>> allow us to aggressively use suspend without loosing (or delaying) >>> wakeup events. On the hardware that we shipped we can enter the same >>> power mode from idle as we do in suspend, but we still use suspend >>> primarily because it stops the monotonic clock and all the timers that >>> use it. Changing suspend to behave more like an idle mode, which seems >>> to be what you are suggesting, would not buy us anything. >> >> Ok, If I am understanding you correctly I think this is an important point. >> >> What Android calls suspend is not what other linux distros call suspend, >> it's just a low-power mode with different wakeup rules. >> >> Is this correct? >> > > No. Android suspend is Linux suspend. We just enter it more frequently. In Linux, a full suspend normally takes the system down to a mode that can't be reached by the normal idle mechnism (including powering down peripherals). It also takes significantly different actions to wake up. What you are describing seems much milder than that. >> If this is the case it seems even more so that the android suspend should be >> addressed by tieing into the power management/idle stuff rather than the >> suspend/hibernate side of things >> >> is the reason you want to stop the onotonic clock and the timers because the >> applications need to be fooled into thinking no time has passed? >> > > Yes, but this is not an Android extension, it is part of the normal > Linux suspend sequence. no, as noted by others in this thread, normal linux suspend/resume modifies the clock to show that time has passed since the suspend happened. >> or is it to prevent extranious wakeups? >> > That too. as noted above, this sounds like it's configurable. >> or is it to save additional power? >> > No (assuming you are asking about the clock), the actual hardware > clock (on msm) stops even in idle but it is resynchronized on wakeup > with a clock that never stops when used from idle. so I'm left not understanding the huge desire to stop the monotonic clock. >>>> you have many different power saving modes, the daemon (or kernel code) >>>> that >>>> is determining which mode to go into would need different logic >>>> (including, >>>> but not limited to the ability to be able to ignore one or more cgroups >>>> of >>>> processes). different power saving modes have different trade-offs, and >>>> some >>>> of them power down different peripherals (which is always a platform >>>> specific, if not system specific set of trade-offs) >>>> >>> >>> The hardware specific idle hook can (and does) decide to go into any >>> power state from idle that does not disrupt any active devices. >> >> This I know is an Andoid specific thing. On other platforms power states >> very definantly can make user visible changes. > > How is this Android specific? you are stating that this must be suspend because low-power idle must be transparent to the user. I am saying that on Linux, low-power idle commonly is not transparent to the user, so the requirement for it to be transparent (therefor putting the suspend into a different category) is an Android only requirement. David Lang
From: david on 4 Aug 2010 02:50 On Wed, 4 Aug 2010, Florian Mickler wrote: > Subject: Re: Attempted summary of suspend-blockers LKML thread > > On Tue, 3 Aug 2010 21:55:07 -0700 (PDT) > david(a)lang.hm wrote: > >> On Tue, 3 Aug 2010, Arjan van de Ven wrote: >> >>> On Tue, 3 Aug 2010 17:10:15 -0700 >>> "Paul E. McKenney" <paulmck(a)linux.vnet.ibm.com> wrote: >>>> >>>> OK, I'll bite... >>>> >>>>> From an Android perspective, the differences are as follows: >>>> >>>> 1. Deep idle states are entered only if there are no runnable >>>> tasks. In contrast, opportunistic suspend can happen even when there >>>> are tasks that are ready, willing, and able to run. >>> >>> for "system suspend", this is an absolutely valid statement. >>> for "use suspend as idle state", it's not so clearly valid. >>> (but this is sort of a separate problem, basically the "when do we >>> freeze the tasks that we don't like for power reasons" problem, >>> which in first order is independent on what kind of idle power state >>> you pick, and discussed extensively elsewhere in this thread) >> >> note that what I'm speculating about would never freeze some of the tasks, >> it would run everything if anything is run, but it would not consider the >> actions of some of the programs when deciding if it can shutdown. >> >> so if you have all your privilaged applications in long sleeps, but still >> have your bouncing cows running, peggng the CPU, making noise, and >> updating the screen, the system would decide the system is 'idle' and go >> into the 'suspend' low power state until there is a wake activity. >> >> but if you have a privilaged application doing other stuff (say you are >> talking on the phone, have a GPS mapping program running and giving you >> directions, etc), the bouncing cows would continue to run and there would >> never be an attempt to freeze them while leaving the other stuff active. >> >> David Lang > > I think the only difference between your proposition and the > current android practice is that in your scheme the partition is along > the process/task boundary (i.e. good apps vs bad apps) whereas the > android looks at actions or events or ... let's call it "stuff" and > blocks suspend whenever "stuff" needs to be done. with the caviot that only privilaged applications are allowed to define that "stuff" needs to be done > The main thing is that even an process that is allowed to block suspend > doesn't do so all the time. Only when it is critical that "stuff" get's > done right away. effectivly, only when it's important that "stuff" gets done at all. With current smartphone battery capacities it's not uncommon that the phone could be in suspend until the battery dies, since suspend is not zero power. > One way to make an application work the same way with your scheme (as > I understand it) on android could be to split the > application into an "blocker" part, that is not part of the > "ignore-cgroup" (the "trusted" part) and another one that is in the > "ignore-cgroup" (the "untrusted" part). Whenever the untrusted part > needs to block suspend it notices the "trusted" part via ipc and the > trusted part goes into some sort of "activity loop". This looks kind of > stupid. But I bet it is what application developers are going to do if > there is no provision for a flexible runtime enable/disable "suspend > blocker". remember that only "trusted" applications were allowed to set the suspend-blocker/wakelock flag in the first place. my thinking is that since "trusted" applications are assumed to be well written (or they can just raise the suspend-blocker/wakelock and keep the phone from ever sleeping) they should be able to be trusted to sleep appropriately so that if they aren't actually doing anything important the system can go ahead and go to sleep. Since powertop was designed to find ill-bahaved applications, you would still be able to point the finger at the offenders. yes, you could trivially have a 'keep me awake' daemon that other apps can talk to to request the system stay awake (the same way you could with a suspend-blocker/wakelock). The "activity loop" for such a daemon can be pretty trivial, set a timer just a little shorter than the idle-go-to-suspend timeout, sleep that long and reset the timer. I could be mistaken here, but my assumption is that since normal applications running would never get trigger the wakelock except when there is user input, the timeout here is on the order of 10s of seconds, if not a few minutes. having a privilaged application wake up once every several seconds is not going to be significant to anything other than things looking for the system being idle for X amount of time.. Even if this is done, having a userspace 'wakelock' daemon that works this way is significantly better in many people's eyes than having the kernel implement this policy. It's much easier to put application/platform specific logic in the userspace daemon than into the kernel (say, things like 'any app can request a delay for up to X amount of time, but after that they cannot request it again for Y amount of time, except ....) 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/
From: Arve Hjønnevåg on 4 Aug 2010 03:00
2010/8/3 Olivier Galibert <galibert(a)pobox.com>: > On Tue, Aug 03, 2010 at 11:03:15PM -0700, Arve Hj�nnev�g wrote: >> 2010/8/3 Olivier Galibert <galibert(a)pobox.com>: >> > On Tue, Aug 03, 2010 at 08:39:22PM -0700, Arve Hj�nnev�g wrote: >> >> If you just program the alarm you will wake up see that the monotonic >> >> clock has not advanced and set the alarm another n seconds into the >> >> future. Or are proposing that suspend should be changed to keep the >> >> monotonic clock running? >> > >> > You're supposed to fix the clock after you wake up. �That's part of >> > the cost of going suspend. >> >> I'm not sure what you are referring to. The generic Linux timekeeping >> code makes sure the monotonic clock stops while the system is >> suspended regardless of what values the (hardware specific) >> clocksource returns. > > That just means the android-like suspend should not act in that > specific area the same as the generic suspend to ram. �Which is not Huh? Android uses the generic suspend code. > entirely surprising. �In any case, it's not "keep the monotonic clock > running", which would cost power. �It's fix it up afterwards, using > the same means you already do but perhaps at a higher level currently. > People don't want to see the wrong time of the day just because the > phone went to suspend. �Laptop STR is different in perception because The monotonic clock is not the same as the realtime clock which is used for time of day. > it shuts down things people don't want to see shutdown just by being > idle, namely wifi connectivity. > > If your next polling timer is in half an hour and the screen/touchpad > are off, you want to go as low in power as possible until then, and > that's the deepest level of idle you can find that responds to alarms > which may happen to be called suspend. �But from a user point of view, Calling the deepest idle state suspend is just confusing. Linux suspend has a different api than idle. In suspend every driver that has a suspend hook is notified. Also, once cpu can be idle while another cpu is running. Suspend is a system wide. > it's just another idle level. �And from a power management code/policy > decisions point of view, it should be the same. > -- 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/ |