[PATCH 1/8] PM: Add suspend block api.
in [Kernel]
|
Prev: [PATCH 7/8] Input: Block suspend while event queue is not empty.
Next: [PATCH 3/8] PM: suspend_block: Abort task freezing if a suspend_blocker is active.
From: James Kosin on 6 May 2010 23:20 On 5/6/2010 11:10 PM, Arve Hj�nnev�g wrote: > 2010/5/6 James Kosin <james.kosin.04(a)cnu.edu>: > >> On 5/6/2010 10:53 PM, Arve Hj�nnev�g wrote: >> >>> On Thu, May 6, 2010 at 7:41 PM, James Kosin <james.kosin.04(a)cnu.edu> wrote: >>> >>> >>>> On 5/5/2010 8:10 PM, Tony Lindgren wrote: >>>> >>>> >>>>> * Brian Swetland <swetland(a)google.com> [100505 16:51]: >>>>> >>>>> >>>>>> On Wed, May 5, 2010 at 4:47 PM, Tony Lindgren <tony(a)atomide.com> wrote: >>>>>> >>>>>> >>>>>>> * Brian Swetland <swetland(a)google.com> [100505 14:34]: >>>>>>> >>>>>>> >>>>>>>> On Wed, May 5, 2010 at 2:12 PM, Alan Stern <stern(a)rowland.harvard.edu> wrote: >>>>>>>> >>>>>>>> >>>> <<-- snip -->> >>>> >>>> >>>>>>>>> At no point does the user program have to communicate anything to the >>>>>>>>> modem driver, and at no point does it have to do anything out of the >>>>>>>>> ordinary except to enable and disable a suspend blocker. >>>>>>>>> >>>>>>>>> >>>>>>>> Exactly -- and you can use the same style of overlapping suspend >>>>>>>> blockers with other drivers than input, if the input interface is not >>>>>>>> suitable for the particular interaction. >>>>>>>> >>>>>>>> >>>>>>> Would the suspend blockers still be needed somewhere in the example >>>>>>> above? >>>>>>> >>>>>>> >>>>>> How often would we retry suspending? >>>>>> >>>>>> >>>>> Well based on some timer, the same way the screen blanks? Or five >>>>> seconds of no audio play? So if the suspend fails, then reset whatever >>>>> userspace suspend policy timers. >>>>> >>>>> >>>>> >>>> Tony, >>>> Wouldn't this be handled by the idle task, or task manager? >>>> >>>> When all tasks are suspended and not doing anything that should be the >>>> first clue that a real suspend cycle could be attempted. >>>> >>>> >>>> >>> One if the benefit we get from using suspend is that an unprivileged >>> app that does not have access to suspend blockers cannot prevent >>> suspend. You lose this advantage if you trigger suspend only from the >>> idle task. >>> >>> >>> >> If the process (privileged or unprivileged) doesn't want to suspend, why >> not just provide an interface to allow suspend to be turned off at the >> user level. This could block the suspend cycle in itself, and you >> shouldn't need fine grained off/on cycles. If an application really >> needs the system not to suspend then they (the user) should know the >> consequences and power requirements for such a task. >> >> I didn't say it had to be only from the idle task; but, that is the most >> logical place. If the other threads are not idle then they really >> require work and will most likely already have a bock on the suspend anyway. >> >> > I think you missed my point. Unprivileged processes should not be > allowed to prevent suspend. > > Ah, you want a way for the system to suspend (and enforce the suspend) when only unprivileged processes are the only thing running.... That would mean a lot of work defining the unprivileged (or privileged) processes, and properly suspending (or enforcing) when needed. Yuck. Sorry I commented then, this is really getting deep into what I love to do at work. -- 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: mgross on 7 May 2010 00:00 On Thu, May 06, 2010 at 10:14:53AM -0700, Tony Lindgren wrote: > * Matthew Garrett <mjg(a)redhat.com> [100506 10:05]: > > On Thu, May 06, 2010 at 10:01:51AM -0700, Tony Lindgren wrote: > > > > > Or are you suspending constantly, tens of times per minute even if > > > there's no user activity? > > > > In this case you'd be repeatedly trying to suspend until the modem > > driver stopped blocking it. It's pretty much a waste. > > But then the userspace knows you're getting data from the modem, and > it can kick some inactivity timer that determines when to try to > suspend next. Thank you for thinking. --mgross > > Why would you need to constantly try to suspend in that case? > > Regards, > > Tony -- 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 7 May 2010 00:20 On Thu, May 6, 2010 at 8:45 PM, mgross <markgross(a)thegnar.org> wrote: > On Thu, May 06, 2010 at 06:09:56PM +0100, Matthew Garrett wrote: >> On Thu, May 06, 2010 at 10:01:51AM -0700, Tony Lindgren wrote: >> >> > Or are you suspending constantly, tens of times per minute even if >> > there's no user activity? >> >> In this case you'd be repeatedly trying to suspend until the modem >> driver stopped blocking it. It's pretty much a waste. > > > lets not go off in the weeds for the wrong things now. �The answer to > the retry is at most one time. �The first time would be blocked, then > the suspend enable would need to re-enabled under user mode control that > would, buy that time, know it has to ack to the modem to stop rejecting > the suspend attempt. > This is incorrect in the general case. User-space has no way of knowing which driver blocked suspend or when it will stop blocking suspend. -- 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: Tony Lindgren on 7 May 2010 12:00 * Arve Hjønnevåg <arve(a)android.com> [100506 17:05]: > 2010/5/6 Tony Lindgren <tony(a)atomide.com>: > > * Arve Hjønnevåg <arve(a)android.com> [100505 21:11]: <snip> > >> This is not a rare event. For example, the matrix keypad driver blocks > >> suspend when a key is down so it can scan the matrix. > > > > Sure, but how many times per day are you suspending? > > > > How many times we successfully suspend is irrelevant here. If the > driver blocks suspend the number of suspend attempts depend on your > poll frequency. I guess what I'm trying to say is that a failed suspend should be a rare event. > >> >> With the suspend block model we know the moment we're capable of > >> >> suspending and then can suspend at that moment. Continually trying to > >> >> suspend seems like it'd be inefficient power-wise (we're going to be > >> >> doing a lot more work as we try to suspend over and over, or we're > >> >> going to retry after a timeout and spend extra time not suspended). > >> >> > >> >> We can often spend minutes (possibly many) at a time preventing > >> >> suspend when the system is doing work that would be interrupted by a > >> >> full suspend. > >> > > >> > Maybe you a userspace suspend policy manager would do the trick if > >> > it knows when the screen is blanked and no audio has been played for > >> > five seconds etc? > >> > > >> > >> If user space has to initiate every suspend attempt, then you are > >> forcing it to poll whenever a driver needs to block suspend. > > > > Hmm I don't follow you. If the userspace policy daemon timer times > > out, the device suspends. If the device does not suspend because of > > a blocking driver, then the timers get reset and you try again based > > on some event such as when the screen blanks. > > > > This retry is what I call polling. You have to keep retrying until you > succeed. Also, using the screen blank timeout for this polling is not > a good idea. You do not want to toggle the screen off and on with with > every suspend attempt. The number of retries depends on the power management policy for your device. And that is often device and use specific. So having to retry suspend should be a rare event. The userspace should mostly know when it's OK to suspend. Regards, Tony -- 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: Tony Lindgren on 7 May 2010 12:20
* James Kosin <james.kosin.04(a)cnu.edu> [100506 19:38]: > On 5/5/2010 8:10 PM, Tony Lindgren wrote: > > * Brian Swetland <swetland(a)google.com> [100505 16:51]: > >> On Wed, May 5, 2010 at 4:47 PM, Tony Lindgren <tony(a)atomide.com> wrote: > >>> * Brian Swetland <swetland(a)google.com> [100505 14:34]: > >>>> On Wed, May 5, 2010 at 2:12 PM, Alan Stern <stern(a)rowland.harvard.edu> wrote: > <<-- snip -->> > >>>>> At no point does the user program have to communicate anything to the > >>>>> modem driver, and at no point does it have to do anything out of the > >>>>> ordinary except to enable and disable a suspend blocker. > >>>> > >>>> Exactly -- and you can use the same style of overlapping suspend > >>>> blockers with other drivers than input, if the input interface is not > >>>> suitable for the particular interaction. > >>> > >>> Would the suspend blockers still be needed somewhere in the example > >>> above? > >> > >> How often would we retry suspending? > > > > Well based on some timer, the same way the screen blanks? Or five > > seconds of no audio play? So if the suspend fails, then reset whatever > > userspace suspend policy timers. > > > > Tony, > Wouldn't this be handled by the idle task, or task manager? My thinking is that suspend should be only triggered from the userspace based on a device specic policy. Suspend breaks standard Linux behaviour as all the timers will stop running. You can already implement suspend-like idle states for various processors that are controlled by cpuidle. In those cases the device hits suspend or off modes in the kernel idle loop. In this case the system keeps running waking every few seconds or so when idle, and the timers behave the normal way. Of course there can be tens or even few hundred millisecond wake-up latencies in the case of hitting off and restoring the kernel during idle, so interrupt response time in those cases is longer. > When all tasks are suspended and not doing anything that should be the > first clue that a real suspend cycle could be attempted. Yeah, but I don't think there's a generic way of figuring out when it's OK to suspend. It depends on the device. It can also depend on how the user wants to configure things. Regards, Tony -- 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/ |