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: Arve Hjønnevåg on 3 Aug 2010 18:50 2010/8/2 <david(a)lang.hm>: > On Mon, 2 Aug 2010, Arve Hj?nnev?g wrote: > >> 2010/8/2 �<david(a)lang.hm>: >>> >>> On Mon, 2 Aug 2010, Arve Hj?nnev?g wrote: >>> >>>> On Mon, Aug 2, 2010 at 5:08 PM, �<david(a)lang.hm> wrote: >>>>> >>>>> On Mon, 2 Aug 2010, Paul E. McKenney wrote: >>>>> >>>>> >>>>> you are close, but I think what I'm proposing is actually simpler >>>>> (assuming >>>>> that the scheduler can be configured to generate the appropriate stats) >>>>> >>>>> my thought was not to move applications between cgroups as they >>>>> aquire/release the suspend-block lock, bur rather to say that any >>>>> application that you would trust to get the suspend-block lock should >>>>> be >>>>> in >>>>> cgroup A while all other applications are in cgroup B >>>>> >>>>> when you are deciding if the system shoudl go to sleep because it is >>>>> idle, >>>>> ignore the activity of all applications in cgroup B >>>>> >>>>> if cgroup A applications are busy, the system is not idle and should >>>>> not >>>>> suspend. >>>>> >>>> >>>> Triggering suspend from idle has been suggested before. However, idle >>>> is not a signal that it is safe to suspend since timers stop in >>>> suspend (or the code could temporarily be waiting on a non-wakeup >>>> interrupt). If you add suspend blockers or wakelocks to prevent >>>> suspend while events you care about are pending, then it does not make >>>> a lot of sense to prevent suspend just because the cpu is not idle. >>> >>> isn't this a matter of making the suspend decision look at what timers >>> have >>> been set to expire in the near future and/or tweaking how long the system >>> needs to be idle before going to sleep? >>> >> >> You are describing low power idle modes, not suspend. Most timers stop >> in suspend, so a timer set 10 seconds from now when entering suspend >> will go off 10 seconds after resume so it should have no impact on how >> long you decide to stay in suspend. > > 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..). -- 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: david on 3 Aug 2010 19:30 On Tue, 3 Aug 2010, Arve Hj?nnev?g wrote: > 2010/8/2 <david(a)lang.hm>: >> On Mon, 2 Aug 2010, Arve Hj?nnev?g wrote: >> >>> 2010/8/2 �<david(a)lang.hm>: >>>> >>>> On Mon, 2 Aug 2010, Arve Hj?nnev?g wrote: >>>> >>>>> On Mon, Aug 2, 2010 at 5:08 PM, �<david(a)lang.hm> wrote: >>>>>> >>>>>> On Mon, 2 Aug 2010, Paul E. McKenney wrote: >>>>>> >>>>>> >>>>>> you are close, but I think what I'm proposing is actually simpler >>>>>> (assuming >>>>>> that the scheduler can be configured to generate the appropriate stats) >>>>>> >>>>>> my thought was not to move applications between cgroups as they >>>>>> aquire/release the suspend-block lock, bur rather to say that any >>>>>> application that you would trust to get the suspend-block lock should >>>>>> be >>>>>> in >>>>>> cgroup A while all other applications are in cgroup B >>>>>> >>>>>> when you are deciding if the system shoudl go to sleep because it is >>>>>> idle, >>>>>> ignore the activity of all applications in cgroup B >>>>>> >>>>>> if cgroup A applications are busy, the system is not idle and should >>>>>> not >>>>>> suspend. >>>>>> >>>>> >>>>> Triggering suspend from idle has been suggested before. However, idle >>>>> is not a signal that it is safe to suspend since timers stop in >>>>> suspend (or the code could temporarily be waiting on a non-wakeup >>>>> interrupt). If you add suspend blockers or wakelocks to prevent >>>>> suspend while events you care about are pending, then it does not make >>>>> a lot of sense to prevent suspend just because the cpu is not idle. >>>> >>>> isn't this a matter of making the suspend decision look at what timers >>>> have >>>> been set to expire in the near future and/or tweaking how long the system >>>> needs to be idle before going to sleep? >>>> >>> >>> You are describing low power idle modes, not suspend. Most timers stop >>> in suspend, so a timer set 10 seconds from now when entering suspend >>> will go off 10 seconds after resume so it should have no impact on how >>> long you decide to stay in suspend. >> >> 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? David Lang
From: Paul E. McKenney on 3 Aug 2010 20:20 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>: > >>On Mon, 2 Aug 2010, Arve Hj?nnev?g wrote: > >> > >>>2010/8/2 �<david(a)lang.hm>: > >>>> > >>>>On Mon, 2 Aug 2010, Arve Hj?nnev?g wrote: > >>>> > >>>>>On Mon, Aug 2, 2010 at 5:08 PM, �<david(a)lang.hm> wrote: > >>>>>> > >>>>>>On Mon, 2 Aug 2010, Paul E. McKenney wrote: > >>>>>> > >>>>>> > >>>>>>you are close, but I think what I'm proposing is actually simpler > >>>>>>(assuming > >>>>>>that the scheduler can be configured to generate the appropriate stats) > >>>>>> > >>>>>>my thought was not to move applications between cgroups as they > >>>>>>aquire/release the suspend-block lock, bur rather to say that any > >>>>>>application that you would trust to get the suspend-block lock should > >>>>>>be > >>>>>>in > >>>>>>cgroup A while all other applications are in cgroup B > >>>>>> > >>>>>>when you are deciding if the system shoudl go to sleep because it is > >>>>>>idle, > >>>>>>ignore the activity of all applications in cgroup B > >>>>>> > >>>>>>if cgroup A applications are busy, the system is not idle and should > >>>>>>not > >>>>>>suspend. > >>>>>> > >>>>> > >>>>>Triggering suspend from idle has been suggested before. However, idle > >>>>>is not a signal that it is safe to suspend since timers stop in > >>>>>suspend (or the code could temporarily be waiting on a non-wakeup > >>>>>interrupt). If you add suspend blockers or wakelocks to prevent > >>>>>suspend while events you care about are pending, then it does not make > >>>>>a lot of sense to prevent suspend just because the cpu is not idle. > >>>> > >>>>isn't this a matter of making the suspend decision look at what timers > >>>>have > >>>>been set to expire in the near future and/or tweaking how long the system > >>>>needs to be idle before going to sleep? > >>>> > >>> > >>>You are describing low power idle modes, not suspend. Most timers stop > >>>in suspend, so a timer set 10 seconds from now when entering suspend > >>>will go off 10 seconds after resume so it should have no impact on how > >>>long you decide to stay in suspend. > >> > >>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... 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. 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. 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.) 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? 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: david on 3 Aug 2010 21:00 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) > 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) > 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. 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) 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) 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: Paul E. McKenney on 3 Aug 2010 21:10
On Tue, Aug 03, 2010 at 03:23:00PM -0700, Arve Hj�nnev�g wrote: > 2010/8/3 Paul E. McKenney <paulmck(a)linux.vnet.ibm.com>: > > On Mon, Aug 02, 2010 at 09:18:27PM -0700, Arve Hj�nnev�g wrote: > >> On Sat, Jul 31, 2010 at 10:58 AM, Paul E. McKenney > >> <paulmck(a)linux.vnet.ibm.com> wrote: > ... > >> > o � � � Statistics of the power-control actions taken by power-aware > >> > � � � �applications must be provided, and must be keyed off of program > >> > � � � �name. > >> > >> We don't key the stats off the program name, but having useful > >> statistics is critical too us. The current code in linux-next does not > >> appear to allow this (I'm referring to pm_stay_awake here, etc not > >> pm-qos.) > > > > OK, maybe I was confused earlier. �So you do not track statistics via > > the device being open throughout the application's lifetime? > > The suspend blocker patchset does track statistics while the device is > open, but it it not keyed of the program name. The name is passed from > user-space and a single process can have the device open several > times. The wakelock interface that we currently use just creates a new > object every time it sees a new name and never frees it. Ah, good to know! Thanx, Paul > ... > >> > o � � � If no power-aware or power-optimized application are indicating > >> > � � � �a need for the system to remain operating, the system is permitted > >> > � � � �(even encouraged!) to suspend all execution, even if power-naive > >> > � � � �applications are runnable. �(This requirement did appear to be > >> > � � � �somewhat controversial.) > >> > >> I would say it should suspend even if power aware applications are > >> runnable. Most applications do not exclusively perform critical work. > > > > The point being that a power-aware application does not block suspend > > -unless- it holds a suspend blocker, correct? > > Yes. > > > > > Or am I missing some other subtlety? > > No. > > ... > >> > o � � � Any initialization of the API that controls the system power > >> > � � � �state must be unconditional, so as to be free from failure. > >> > � � � �(I don't currently understand how this relates, probably due to > >> > � � � �my current insufficient understanding of the proposed patch set.) > >> > >> Unconditional initialization makes it easier to add suspend blockers > >> to existing kernel code since you don't have to add new failure exit > >> paths. It is not a strong requirement. > > > > Ah, that makes more sense! �I moved this to a new "NICE-TO-HAVES" > > section. �I also changed the last parenthesized sentence to read > > "Such unconditional initialization reduces the intrusiveness of the > > the Android patchset." �Does that work? > > > > Sure. > > > > -- > 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/ |