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: Arjan van de Ven on 3 Aug 2010 21:40 On Mon, 2 Aug 2010 21:56:10 -0700 Arve Hjønnevåg <arve(a)android.com> wrote: > > non-obvious dependencies. > > > > The dependencies is what made this solution uninteresting to us. For > instance, we currently use cgroup scheduling to reduce the impact of > some background tasks, but we occasionally saw a watchdog restart of > the system process were critical services were waiting on a kernel > mutex owned by a background task for more than 20 seconds. If we froze > a cgroup instead, we would not hit this particular problem since tasks > cannot be frozen while executing kernel code the same way they can be > preempted, but nothing prevents a task from being frozen while holding > a user-space resource. > one of the solutions we're looking at to solve this is to unfreeze the cgroup on a regular basis (say, every 15 to 30 seconds) briefly to avoid this kind of deadlock... -- Arjan van de Ven Intel Open Source Technology Centre For development, discussion and tips for power savings, visit http://www.lesswatts.org -- 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 3 Aug 2010 23:40 On Tue, Aug 3, 2010 at 5:51 PM, <david(a)lang.hm> wrote: > On Tue, 3 Aug 2010, Paul E. McKenney wrote: > >> On Tue, Aug 03, 2010 at 04:19:25PM -0700, david(a)lang.hm wrote: >>> >>> On Tue, 3 Aug 2010, Arve Hj?nnev?g wrote: >>> >>>> 2010/8/2 �<david(a)lang.hm>: >>>>> >>>>> so what is the fundamental difference between deciding to go into >>>>> low-power >>>>> idle modes to wake up back up on a given point in the future and >>>>> deciding >>>>> that you are going to be idle for so long that you may as well suspend >>>>> until >>>>> there is user input? >>>>> >>>> >>>> Low power idle modes are supposed to be transparent. Suspend stops the >>>> monotonic clock, ignores ready threads and switches over to a separate >>>> set of wakeup events/interrupts. We don't suspend until there is user >>>> input, we suspend until there is a wakeup event (user-input, incoming >>>> network data/phone-calls, alarms etc..). >>> >>> s/user input/wakeup event/ and my question still stands. >>> >>> low power modes are not transparent to the user in all cases (if the >>> screen backlight dimms/shuts off a user reading something will >>> notice, if the system switches to a lower clock speed it can impact >>> user response time, etc) The system is making it's best guess as to >>> how to best srve the user by sacraficing some capibilities to save >>> power now so that the power can be available later. >>> >>> as I see it, suspending until a wakeup event (button press, incoming >>> call, alarm, etc) is just another datapoint along the same path. >>> >>> If the system could not wake itself up to respond to user input, >>> phone call, alarm, etc and needed the power button pressed to wake >>> up (or shut down to the point where the battery could be removed and >>> reinstalled a long time later), I would see things moving into a >>> different category, but as long as the system has the ability to >>> wake itself up later (and is still consuming power) I see the >>> suspend as being in the same category as the other low-power modes >>> (it's just more expensive to go in and out of) >>> >>> >>> why should the suspend be put into a different category from the >>> other low-power states? >> >> 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). > >> 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? >> 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. > > 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 all depends on the ability for the code that decides to switch power > modes (including to trigger suspend) to be able to see things in sufficient > detail to be able to do different things depending on the class of programs. > I don't know enough about this code to know if this is the case or not, I > really wish that someone familiar with the power saving code could either > confirm that this is possible, or state that it's not possible (or at least, > not without major surgery) > -- 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: Arjan van de Ven on 4 Aug 2010 00:00 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) > > 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 would argue that this is both a hardware specific issue, but also a policy issue. From the user point of view, screen off with idle and screen off with suspend aren't all that different (if my phone would decide to idle rather than suspend because some app blocks suspend... I wouldn't expect a difference in behavior when I touch the screen). "Screen off -> don't honor touch after a bit" is almost an independent, but very real, policy problem (and a forced one in suspend, I'll grant you that). I could even argue that the policy decision "we don't care about the touch screen input" is a pre-condition for entering suspend (or in android speak, caring for touch screen input/having the touch screen path active would be a suspend blocker) > > 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.) I'll debate it even harder in that it's platform specific whether timers can get the system out of suspend or not. Clearly on the Android platform in question that's not the case, but for some of the Intel phone silicon for example, timers CAN be wake sources to get you out of suspend just fine. It just depend on which exact hw you talk about. Generally, even if the fast timers aren't wake up sources, there'll be some sort of alarm thing that you can pre-wake.. but yes you are right in saying that's rather lame. Either way, it's not a general property of suspend, but a property of suspend on the specific platform in question. -- Arjan van de Ven Intel Open Source Technology Centre For development, discussion and tips for power savings, visit http://www.lesswatts.org -- 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 00:50 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: >> >>> On Tue, Aug 03, 2010 at 04:19:25PM -0700, david(a)lang.hm wrote: >>>> >>>> On Tue, 3 Aug 2010, Arve Hj?nnev?g wrote: >>>> >>>>> 2010/8/2 �<david(a)lang.hm>: >>>>>> >>>>>> so what is the fundamental difference between deciding to go into >>>>>> low-power >>>>>> idle modes to wake up back up on a given point in the future and >>>>>> deciding >>>>>> that you are going to be idle for so long that you may as well suspend >>>>>> until >>>>>> there is user input? >>>>>> >>>>> >>>>> Low power idle modes are supposed to be transparent. Suspend stops the >>>>> monotonic clock, ignores ready threads and switches over to a separate >>>>> set of wakeup events/interrupts. We don't suspend until there is user >>>>> input, we suspend until there is a wakeup event (user-input, incoming >>>>> network data/phone-calls, alarms etc..). >>>> >>>> s/user input/wakeup event/ and my question still stands. >>>> >>>> low power modes are not transparent to the user in all cases (if the >>>> screen backlight dimms/shuts off a user reading something will >>>> notice, if the system switches to a lower clock speed it can impact >>>> user response time, etc) The system is making it's best guess as to >>>> how to best srve the user by sacraficing some capibilities to save >>>> power now so that the power can be available later. >>>> >>>> as I see it, suspending until a wakeup event (button press, incoming >>>> call, alarm, etc) is just another datapoint along the same path. >>>> >>>> If the system could not wake itself up to respond to user input, >>>> phone call, alarm, etc and needed the power button pressed to wake >>>> up (or shut down to the point where the battery could be removed and >>>> reinstalled a long time later), I would see things moving into a >>>> different category, but as long as the system has the ability to >>>> wake itself up later (and is still consuming power) I see the >>>> suspend as being in the same category as the other low-power modes >>>> (it's just more expensive to go in and out of) >>>> >>>> >>>> why should the suspend be put into a different category from the >>>> other low-power states? >>> >>> 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? >> >>> 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) 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. >>> 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? 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? or is it to prevent extranious wakeups? or is it to save additional power? >> 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. >> This all depends on the ability for the code that decides to switch power >> modes (including to trigger suspend) to be able to see things in sufficient >> detail to be able to do different things depending on the class of programs. >> I don't know enough about this code to know if this is the case or not, I >> really wish that someone familiar with the power saving code could either >> confirm that this is possible, or state that it's not possible (or at least, >> not without major surgery)
From: david on 4 Aug 2010 01:00
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 -- 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/ |