PM: Opportunistic suspend support.
in [Kernel]
|
Prev: direct-io: do not merge logically non-contiguous requests
Next: [PATCH] linux/elfcore.h: hide kernel functions
From: Peter Zijlstra on 26 May 2010 05:00 On Wed, 2010-05-26 at 10:42 +0200, Peter Zijlstra wrote: > What Dmitry proposes is that, the app _before_ it consumes the event, > pokes at this suspend manager, it increases a blocker count, then > consumes the event (the kernel will _not_ auto-suspend), handles it and > then again pokes the suspend manager, this time decreasing the blocker > count. > > The suspend manager will, upon reaching a 0 block count, suspend the > machine. If that fails, it means there's something to do, an app will > inc, work, dec its count, and it will try again once it reaches 0 again. Alternatively the suspend manager could simply cancel the opportunistic suspend mode on !0, and re-instate it on 0. -- 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: Florian Mickler on 26 May 2010 05:30 On Wed, 26 May 2010 10:42:22 +0200 Peter Zijlstra <peterz(a)infradead.org> wrote: > On Tue, 2010-05-25 at 15:33 -0700, Arve Hj�nnev�g wrote: > > The biggest problem here is not that it is hard to change our > > user-space, but that the proposed change is inferior to what we have > > now. It forces us to poll until all drivers stop aborting suspend. On > > one hand we have people telling us that all code that polls is broken > > and must be fixed (instead of suspending to limit the damage), and on > > the other hand we have people suggesting we implement opportunistic > > suspend by polling from user-space until suspend succeeds. > > No it does _not_. You're really not getting that Dmitry is proposing. > > > So your proposal is that when we wake userspace, it > opens /dev/suspend_blocker _before_ it consumes whatever event, consumes > the event, deals with the event, then closes the suspend_blocker. Then > the kernel, upon reaching a 0 suspend_blocker count, will try to suspend > again. > > > What Dmitry proposes is that, the app _before_ it consumes the event, > pokes at this suspend manager, it increases a blocker count, then > consumes the event (the kernel will _not_ auto-suspend), handles it and > then again pokes the suspend manager, this time decreasing the blocker > count. > > The suspend manager will, upon reaching a 0 block count, suspend the > machine. If that fails, it means there's something to do, an app will > inc, work, dec its count, and it will try again once it reaches 0 again. > > There is no polling what-so-ever in this model. > > The only thing is that the kernel will not try to auto-suspend and there > is no user-space suspend blocker API. There is polling, because the suspend manager in userspace doesn't have the whole picture. i.e. it doesn't know if a suspend will be successfull. So for aggressive suspending as a powersave-feature you need to poll (i.e. retry upon failure). because you don't want to stay unsuspended. This discussion really is going in circles. You could all may well be just posting references to postings by now, instead of actually writing mails. 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: Peter Zijlstra on 26 May 2010 05:40 On Wed, 2010-05-26 at 11:23 +0200, Florian Mickler wrote: > There is polling, because the suspend manager in userspace doesn't have > the whole picture. i.e. it doesn't know if a suspend will be > successfull. > So for aggressive suspending as a powersave-feature you need to poll > (i.e. retry upon failure). because you don't want to stay unsuspended. Clearly if it fails, there something to be done, right? So whoever does the thing will communicate with the suspend manager that it's going to do and has finished doing its thing, at which point it will try again. That's event driven, not polled. Also, if you want you can keep the kernel-side auto-suspend side, and have the suspend manager clear on !0 and re-establish the auto-suspend state on 0. But you really don't need this device thingy. -- 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 26 May 2010 06:00 On Wed, May 26, 2010 at 2:33 AM, Peter Zijlstra <peterz(a)infradead.org> wrote: > On Wed, 2010-05-26 at 11:23 +0200, Florian Mickler wrote: > >> There is polling, because the suspend manager in userspace doesn't have >> the whole picture. i.e. it doesn't know if a suspend will be >> successfull. >> So for aggressive suspending as a powersave-feature you need to poll >> (i.e. retry upon failure). because you don't want to stay unsuspended. > > Clearly if it fails, there something to be done, right? So whoever does > the thing will communicate with the suspend manager that it's going to > do and has finished doing its thing, at which point it will try again. > If you are talking about user-space code here, then that does not work. Not all kernel events that need to block suspend make it to user-space. > That's event driven, not polled. > > Also, if you want you can keep the kernel-side auto-suspend side, and > have the suspend manager clear on !0 and re-establish the auto-suspend > state on 0. > > But you really don't need this device thingy. > I'm not sure what you are proposing that we use instead. Both user-space and kernel code needs to block suspend. If we don't have suspend blockers in the kernel then user-space needs to poll when a driver blocks suspend by returning an error from its suspend hook. -- 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 26 May 2010 06:10
On Wed, 2010-05-26 at 02:54 -0700, Arve Hjønnevåg wrote: > > I'm not sure what you are proposing that we use instead. Both > user-space and kernel code needs to block suspend. If we don't have > suspend blockers in the kernel then user-space needs to poll when a > driver blocks suspend by returning an error from its suspend hook. In particular I'm suggesting you ditch the /dev/suspend_block thing. With a single suspend manager process that manages the suspend state you can achieve the same goal. When the suspend manager has a !0 busy-task count, it ensures the kernel won't auto-suspend, when it again reaches a 0 busy-task count, it re-instates the auto-suspend feature. That's pretty much what that device would do too. Ideally we would not do the auto-suspend thing at all and have runtime-PM improved. Not running apps when they expect to run is like the world turned upside down. 'Evil' apps could always report themselves as blocker anyway. -- 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/ |