[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: Arve Hjønnevåg on 2 Jun 2010 05:00 2010/6/2 Thomas Gleixner <tglx(a)linutronix.de>: > On Tue, 1 Jun 2010, Arve Hj�nnev�g wrote: >> 2010/6/1 Thomas Gleixner <tglx(a)linutronix.de>: >> > On Mon, 31 May 2010, Arve Hj�nnev�g wrote: >> > >> >> 2010/5/31 Rafael J. Wysocki <rjw(a)sisk.pl>: >> >> > On Monday 31 May 2010, Arve Hj�nnev�g wrote: >> >> >> 2010/5/30 Rafael J. Wysocki <rjw(a)sisk.pl>: >> >> > ... >> >> >> >> >> >> I think it makes more sense to block suspend while wakeup events are >> >> >> pending than blocking it everywhere timers are used by code that could >> >> >> be called while handling wakeup events or other critical work. Also, >> >> >> even if you did block suspend everywhere timers where used you still >> >> >> have the race where a wakeup interrupt happens right after you decided >> >> >> to suspend. In other words, you still need to block suspend in all the >> >> >> same places as with the current opportunistic suspend code, so what is >> >> >> the benefit of delaying suspend until idle? >> >> > >> >> > Assume for a while that you don't use suspend blockers, OK? �I realize you >> >> > think that anything else doesn't make sense, but evidently some other people >> >> > have that opinion about suspend blockers. >> >> > >> >> >> >> It sounded like you were suggesting that initiating suspend from idle >> >> would somehow avoid the race condition with wakeup events. All I'm >> >> saying is that you would need to block suspend in all the same places. >> >> If you don't care about ignoring wakeup events, then sure you can >> >> initiate suspend from idle. >> > >> > And why should you miss a wakeup there ? If you get an interrupt in >> > the transition, then you are not longer idle. >> > >> >> Because suspend itself causes you to not be idle you cannot abort >> suspend just because you are not idle anymore. > > You still are addicted to the current suspend mechanism. :) > No I want you to stop confusing low power idle modes with suspend. I know how to enter low power modes from idle if that low power mode is not too disruptive. > The whole point of doing it from idle in the form of a deep power > state is to avoid the massive sh*tload of work which is neccesary to > run the existing suspend code. But that needs runtime power management > and tweaks to avoid your timers waking you, etc. > > The mechanism you want to use is: suspend no matter what, like closing > the lid of the laptop, but with a few tweaks around it: > > � 1) An interrupt on a wakeup source which comes in while the suspend > � � �code runs, i.e before you transitioned into wakeup mode, must > � � �abort / prevent suspend. > > � 2) Prevent another attempt to suspend before the event has been > � � �delivered and the apps have signaled that they have not longer > � � �any work to do. > > � As a side effect you confine crappy apps with that mechanism in > � some way. > > In the laptop case we do not want the tweaks as not going into suspend > might set your backpack on fire. If that is the case you should also disable the wakeup events. > > If I understood you correctly then you can shutdown the CPU in idle > completelty already, but that's not enough due to: > > � �1) crappy applications keeping the cpu away from idle > � �2) timers firing > > Would solving those two issues be sufficient for you or am I missing > something ? Solving those two is enough for current android phones, but it may not be enough for other android devices. 1 is not solvable (meaning we cannot fix all apps), and 2 is difficult to fix since the periodic work is useful while the device is actually in use. One possible way to solve 2 is to allow timers on a not-idle clock. Unrelated to Android, I also want to use opportunistic suspend on my desktop. -- 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: Peter Zijlstra on 2 Jun 2010 05:20 On Wed, 2010-06-02 at 10:29 +0200, Thomas Gleixner wrote: > If I understood you correctly then you can shutdown the CPU in idle > completelty already, but that's not enough due to: > > 1) crappy applications keeping the cpu away from idle > 2) timers firing > > Would solving those two issues be sufficient for you or am I missing > something ? Aren't the container snapshot/resume people fighting the same set of problems here? -- 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: Peter Zijlstra on 2 Jun 2010 05:40 On Wed, 2010-06-02 at 01:54 -0700, Arve Hjønnevåg wrote: > No I want you to stop confusing low power idle modes with suspend. I think it is you who is confused. For power management purposes suspend is nothing more but a deep idle state. (and please don't mention @#$@ up x86 ACPI again, Intel knows, they're fixing it, get over it already). > Unrelated to > Android, I also want to use opportunistic suspend on my desktop. So you're going to sprinkle this suspend blocker shite all over regular userspace? Why not instead work on getting apps to behave properly and idle when there's nothing to do? After all, if you have the code to add suspend blockers into, you also have the means to fix it being stupid in the first place. -- 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 2 Jun 2010 06:10 2010/6/2 Peter Zijlstra <peterz(a)infradead.org>: > On Wed, 2010-06-02 at 01:54 -0700, Arve Hj�nnev�g wrote: >> No I want you to stop confusing low power idle modes with suspend. > > I think it is you who is confused. For power management purposes suspend > is nothing more but a deep idle state. No, idle is transparent, suspend is not. > > (and please don't mention @#$@ up x86 ACPI again, Intel knows, they're > fixing it, get over it already). > I don't think it is realistic to drop support for all existing hardware. >> Unrelated to >> Android, I also want to use opportunistic suspend on my desktop. > > So you're going to sprinkle this suspend blocker shite all over regular > userspace? I have said several times, that regular user-space will not need to be modified to maintain their current behavior. > Why not instead work on getting apps to behave properly and > idle when there's nothing to do? > > After all, if you have the code to add suspend blockers into, you also > have the means to fix it being stupid in the first place. > Why would I add suspend blockers to the code I want to prevent running? -- 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: Peter Zijlstra on 2 Jun 2010 06:30
On Wed, 2010-06-02 at 03:00 -0700, Arve Hjønnevåg wrote: > 2010/6/2 Peter Zijlstra <peterz(a)infradead.org>: > > On Wed, 2010-06-02 at 01:54 -0700, Arve Hjønnevåg wrote: > >> No I want you to stop confusing low power idle modes with suspend. > > > > I think it is you who is confused. For power management purposes suspend > > is nothing more but a deep idle state. > > No, idle is transparent, suspend is not. Which is where the problem is, it should be. > Why would I add suspend blockers to the code I want to prevent running? Because what you want might not be what others want. Suppose you're fine with your torrent client/irc client/etc.. to loose their network connection when you're not behind your desktop so you don't add suspend blockers there. Me, I'd be ready to administer physical violence if either of those lost their connections when I wasn't around to keep the screen-saver from kicking in. This leads to having to sprinkle magic dust (and lots of config options) all over userspace. Something that gets esp interesting with only a boolean interface. In the example above, having an active net connection would prevent my desktop from suspending, but what if another platform can maintain net connections while suspended? Do we then end up with arch specific code in the net-stack? I'm sure DaveM would love that. -- 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/ |