[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: Tony Lindgren on 6 May 2010 22:30 * Alan Stern <stern(a)rowland.harvard.edu> [100506 11:42]: > On Thu, 6 May 2010, Tony Lindgren wrote: > > > Well if your hardware runs off-while-idle or even just > > retention-while-idle, then the basic shell works just fine waking up > > every few seconds or so. > > > > Then you could keep init/shell/suspend policy deamon running until > > it's time to suspend the whole device. To cut down runaway timers, > > you could already freeze the desktop/GUI/whatever earlier. > > This comes down mostly to efficiency. Although the suspend blocker > patch does the actual suspending in a workqueue thread, AFAIK there's > no reason it couldn't use a user thread instead. > > The important difference lies in what happens when a suspend fails > because a driver is busy. Without suspend blockers, the kernel has to > go through the whole procedure of freezing userspace and kernel threads > and then suspending a bunch of drivers before hitting the one that's > busy. Then all that work has to be undone. By contrast, with suspend > blockers the suspend attempt can fail right away with minimal overhead. But does that really matter if you're only few tens of times times per day or so? I don't understand why you would want to try to suspend except after some timeout of no user or network activity. > There's also a question of reliability. With suspends controlled by > userspace there is a possibility of races, which could lead the system > to suspend when it shouldn't. With control in the kernel, these races > can be eliminated. I agree the suspend needs to happen without races. But I think the logic for when to suspend should be done in the userspace as it can be device or user specific. 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: James Kosin on 6 May 2010 22:50 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. James -- 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 6 May 2010 23:00 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. -- 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: James Kosin on 6 May 2010 23:10 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. James -- 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 6 May 2010 23:20
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. -- 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/ |