[PATCH 0/8] Suspend block api (version 8)
in [Kernel]
|
Prev: [ANN] Linux Security Summit 2010 - Announcement and CFP
Next: [PATCH 4/8] PM: suspend_block: Add debugfs file
From: Rafael J. Wysocki on 29 May 2010 16:30 On Saturday 29 May 2010, Arve Hj�nnev�g wrote: > 2010/5/28 Rafael J. Wysocki <rjw(a)sisk.pl>: > > On Friday 28 May 2010, Arve Hj�nnev�g wrote: > >> On Fri, May 28, 2010 at 1:44 AM, Florian Mickler <florian(a)mickler.org> wrote: > >> > On Thu, 27 May 2010 20:05:39 +0200 (CEST) > >> > Thomas Gleixner <tglx(a)linutronix.de> wrote: > > ... > >> > To integrate this with the current way of doing things, i gathered it > >> > needs to be implemented as an idle-state that does the suspend()-call? > >> > > >> > >> I think it is better no not confuse this with idle. Since initiating > >> suspend will cause the system to become not-idle, I don't think is is > >> beneficial to initiate suspend from idle. > > > > It is, if the following two conditions hold simultaneously: > > > > (a) Doing full system suspend is ultimately going to bring you more energy > > savings than the (presumably lowest) idle state you're currently in. > > > > (b) You anticipate that the system will stay idle for a considerably long time > > such that it's worth suspending. > > > > I still don't think this matters. If you are waiting for in interrupt > that cannot wake you up from suspend, then idle is not an indicator > that it is safe to enter suspend. I also don't think you can avoid any > user-space suspend blockers by delaying suspend until the system goes > idle since any page fault could cause it to go idle. Therefore I don't > see a benefit in delaying suspend until idle when the last suspend > blocker is released (it would only mask possible race conditions). I wasn't referring to suspend blockers, but to the idea of initiating full system suspend from idle, which I still think makes sense. If you are waiting for an interrupt that cannot wake you from suspend, then _obviously_ suspend should not be started. However, if you're not waiting for such an interrupt and the (a) and (b) above hold, it makes sense to start suspend from idle. Thanks, Rafael -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Rafael J. Wysocki on 29 May 2010 16:50 On Saturday 29 May 2010, Alan Stern wrote: > On Sat, 29 May 2010, Florian Mickler wrote: > > > On Sat, 29 May 2010 12:42:37 +0200 > > Peter Zijlstra <peterz(a)infradead.org> wrote: > > > > Now, all I'm interested in is providing interfaces from the kernel where > > > needed, so that userspace can be optimally frugal with power usage, and > > > can monitor/contain badly behaving tasks. > > > > > > > I think this is a sensible approach. > > Here is an attempt to satisfy everyone as much as possible. But first > an explicit disclaimer: When I say "suspend", I mean it as in > "suspend-to-RAM"; i.e., a forced suspend and not a cpuidle mode. > > In place of in-kernel suspend blockers, there will be a new type of QoS > constraint -- call it QOS_EVENTUALLY. It's a very weak constraint, > compatible with all cpuidle modes in which runnable threads are allowed > to run (which is all of them), but not compatible with suspend. > > The Android people want debugging and accountability. So in the most > objectionable part of this proposal, we add a new way of registering > QoS constraints: monitored constraints. The "monitored" implies that: > > The constraint has a name, which can be used for debugging > and accounting; > > The kernel maintains statistics on the constraint's use and > makes them available to userspace; and > > The PM core is notified whenever the number of active monitored > constraints drops to 0. > > There is no /sys/power/policy file. In place of opportunistic suspend, > we have "QoS-based suspend". This is initiated by userspace writing > "qos" to /sys/power/state, and it is very much like suspend-to-RAM. > However a QoS-based suspend fails immediately if there are any active > normal QoS constraints incompatible with system suspend, in other > words, any constraints requiring a throughput > 0 or an interrupt > latency shorter than the time required for a suspend-to-RAM/resume > cycle. > > If no such constraints are active, the QoS-based suspend blocks in an > interruptible wait until the number of active QOS_EVENTUALLY > constraints drops to 0. When that happens, it carries out a normal > suspend-to-RAM -- except that it checks along the way to make sure that > no new QoS constraints are activated while the suspend is in progress. > If they are, the PM core backs out and fails the QoS-based suspend. > > Userspace suspend blockers don't exist at all, as far as the kernel is > concerned. In their place, the Android runs a power-manager program > that receives IPC requests from other processes when they need to > prevent the system from suspending or allow it to suspend. The power > manager's main loop looks like this: > > for (;;) { > while (any IPC requests remain) > handle them; > if (any processes need to prevent suspend) > sleep; > else > write "qos" to /sys/power/state; > } > > The idea is that receipt of a new IPC request will cause a signal to be > sent, interrupting the sleep or the "qos" write. > > There remains a question as to which kernel drivers should create > monitored QOS_EVENTUALLY constraints. Perhaps userspace could be > allowed to specify this (I don't know how). In any case, this is a > relatively minor point. > > The advantages of this scheme are that this does everything the Android > people need, and it does it in a way that's entirely compatible with > pure QoS/cpuidle-based power management. It even starts along the path > of making suspend-to-RAM just another kind of dynamic power state. > > If people such as Peter still want to complain that using > suspend-to-RAM in Android phones isn't a good way to do power > management, that's okay -- it's the designers' decision to program > their phones the way they want. At least the kernel can give them the > ability to do so in a way that doesn't compromise everybody else. This sounds reasonable to me. Rafael -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Arve Hjønnevåg on 29 May 2010 18:00 2010/5/29 Rafael J. Wysocki <rjw(a)sisk.pl>: > On Saturday 29 May 2010, Arve Hj�nnev�g wrote: >> 2010/5/28 Rafael J. Wysocki <rjw(a)sisk.pl>: >> > On Friday 28 May 2010, Arve Hj�nnev�g wrote: >> >> On Fri, May 28, 2010 at 1:44 AM, Florian Mickler <florian(a)mickler.org> wrote: >> >> > On Thu, 27 May 2010 20:05:39 +0200 (CEST) >> >> > Thomas Gleixner <tglx(a)linutronix.de> wrote: >> > ... >> >> > To integrate this with the current way of doing things, i gathered it >> >> > needs to be implemented as an idle-state that does the suspend()-call? >> >> > >> >> >> >> I think it is better no not confuse this with idle. Since initiating >> >> suspend will cause the system to become not-idle, I don't think is is >> >> beneficial to initiate suspend from idle. >> > >> > It is, if the following two conditions hold simultaneously: >> > >> > (a) Doing full system suspend is ultimately going to bring you more energy >> > � �savings than the (presumably lowest) idle state you're currently in. >> > >> > (b) You anticipate that the system will stay idle for a considerably long time >> > � �such that it's worth suspending. >> > >> >> I still don't think this matters. If you are waiting for in interrupt >> that cannot wake you up from suspend, then idle is not an indicator >> that it is safe to enter suspend. I also don't think you can avoid any >> user-space suspend blockers by delaying suspend until the system goes >> idle since any page fault could cause it to go idle. Therefore I don't >> see a benefit in delaying suspend until idle when the last suspend >> blocker is released (it would only mask possible race conditions). > > I wasn't referring to suspend blockers, but to the idea of initiating full > system suspend from idle, which I still think makes sense. �If you are > waiting for an interrupt that cannot wake you from suspend, then > _obviously_ suspend should not be started. �However, if you're not waiting for > such an interrupt and the (a) and (b) above hold, it makes sense to start > suspend from idle. > What about timers? When you suspend timers stop (otherwise it is just a deep-idle mode), and this could cause problems. Some drivers rely on timers if the hardware does not have a completion interrupt. It is not uncommon to see send command x then wait 200ms in a some hardware specs. -- 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: Arve Hjønnevåg on 29 May 2010 18:20 On Sat, May 29, 2010 at 7:10 AM, Alan Stern <stern(a)rowland.harvard.edu> wrote: > On Sat, 29 May 2010, Florian Mickler wrote: > >> On Sat, 29 May 2010 12:42:37 +0200 >> Peter Zijlstra <peterz(a)infradead.org> wrote: > >> > Now, all I'm interested in is providing interfaces from the kernel where >> > needed, so that userspace can be optimally frugal with power usage, and >> > can monitor/contain badly behaving tasks. >> > >> >> I think this is a sensible approach. > > Here is an attempt to satisfy everyone as much as possible. �But first > an explicit disclaimer: When I say "suspend", I mean it as in > "suspend-to-RAM"; i.e., a forced suspend and not a cpuidle mode. > > In place of in-kernel suspend blockers, there will be a new type of QoS > constraint -- call it QOS_EVENTUALLY. �It's a very weak constraint, > compatible with all cpuidle modes in which runnable threads are allowed > to run (which is all of them), but not compatible with suspend. > This sound just like another API rename. It will work, but given that suspend blockers was the name least objectionable last time around, I'm not sure what this would solve. > The Android people want debugging and accountability. �So in the most > objectionable part of this proposal, we add a new way of registering > QoS constraints: monitored constraints. �The "monitored" implies that: > > � � � �The constraint has a name, which can be used for debugging > � � � �and accounting; > > � � � �The kernel maintains statistics on the constraint's use and > � � � �makes them available to userspace; and > > � � � �The PM core is notified whenever the number of active monitored > � � � �constraints drops to 0. > > There is no /sys/power/policy file. �In place of opportunistic suspend, > we have "QoS-based suspend". �This is initiated by userspace writing > "qos" to /sys/power/state, and it is very much like suspend-to-RAM. Why do you want to tie it to a specific state? > However a QoS-based suspend fails immediately if there are any active Fail or block? Your next paragraph said that it blocks for QOS_EVENTUALLY, but if normal constraints fail, you are still stuck in a retry loop. > normal QoS constraints incompatible with system suspend, in other > words, any constraints requiring a throughput > 0 or an interrupt > latency shorter than the time required for a suspend-to-RAM/resume > cycle. > > If no such constraints are active, the QoS-based suspend blocks in an > interruptible wait until the number of active QOS_EVENTUALLY How do you implement this? > constraints drops to 0. �When that happens, it carries out a normal > suspend-to-RAM -- except that it checks along the way to make sure that > no new QoS constraints are activated while the suspend is in progress. > If they are, the PM core backs out and fails the QoS-based suspend. > > Userspace suspend blockers don't exist at all, as far as the kernel is > concerned. �In their place, the Android runs a power-manager program > that receives IPC requests from other processes when they need to > prevent the system from suspending or allow it to suspend. �The power > manager's main loop looks like this: > > � � � �for (;;) { > � � � � � � � �while (any IPC requests remain) > � � � � � � � � � � � �handle them; > � � � � � � � �if (any processes need to prevent suspend) > � � � � � � � � � � � �sleep; > � � � � � � � �else > � � � � � � � � � � � �write "qos" to /sys/power/state; > � � � �} > > The idea is that receipt of a new IPC request will cause a signal to be > sent, interrupting the sleep or the "qos" write. What happen if the signal is right before (or even right after) calling write "qos". How does the signal handler stop the write? > > There remains a question as to which kernel drivers should create > monitored QOS_EVENTUALLY constraints. �Perhaps userspace could be > allowed to specify this (I don't know how). �In any case, this is a > relatively minor point. > > The advantages of this scheme are that this does everything the Android > people need, and it does it in a way that's entirely compatible with > pure QoS/cpuidle-based power management. �It even starts along the path > of making suspend-to-RAM just another kind of dynamic power state. > > If people such as Peter still want to complain that using > suspend-to-RAM in Android phones isn't a good way to do power > management, that's okay -- it's the designers' decision to program > their phones the way they want. �At least the kernel can give them the > ability to do so in a way that doesn't compromise everybody else. > > Alan Stern > > -- 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: Nigel Cunningham on 29 May 2010 19:10
Hi. I like the sound of this much better too, but... On 30/05/10 08:13, Arve Hj�nnev�g wrote: > On Sat, May 29, 2010 at 7:10 AM, Alan Stern<stern(a)rowland.harvard.edu> wrote: >> There is no /sys/power/policy file. In place of opportunistic suspend, >> we have "QoS-based suspend". This is initiated by userspace writing >> "qos" to /sys/power/state, and it is very much like suspend-to-RAM. > > Why do you want to tie it to a specific state? I do agree here. I would suggest that all /sys/power/state possibilities should have a qos- equivalent. You might not want to use any or all of them, but they should be available. Regards, Nigel -- 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/ |