[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: Alan Stern on 6 May 2010 14:50 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. 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. Alan Stern -- 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: Matthew Garrett on 6 May 2010 14:50 On Thu, May 06, 2010 at 11:33:35AM -0700, Tony Lindgren wrote: > * Matthew Garrett <mjg(a)redhat.com> [100506 10:39]: > > On Thu, May 06, 2010 at 10:38:08AM -0700, Tony Lindgren wrote: > > > > > If your userspace keeps polling and has runaway timers, then you > > > could suspend it's parent process to idle the system? > > > > If your userspace is suspended, how does it process the events that > > generated a system wakeup? If we had a good answer to that then suspend > > blockers would be much less necessary. > > 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. And the untrusted userspace code that's waiting for a network packet? Adding a few seconds of latency isn't an option here. -- Matthew Garrett | mjg59(a)srcf.ucam.org -- 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: Daniel Walker on 6 May 2010 15:20 On Thu, 2010-05-06 at 11:36 -0700, Tony Lindgren wrote: > * Daniel Walker <dwalker(a)fifo99.com> [100506 10:30]: > > On Thu, 2010-05-06 at 10:14 -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. > > > > If the idle thread was doing the suspending then the inactivity timer by > > it's self could block suspend. As long as the idle thread was setup to > > check for timers. I'm sure that _isn't_ the point your trying to make. > > It just makes gobs more sense to me that the idle thread does the > > suspending .. Your idle, so depending on how long your idle then you > > suspend. > > The alternative logic I'm suggesting is get the GUI into idle mode as > soon as possible, then limp along with off-while-idle or > retention-while-idle until some timer expires, then suspend the whole > device. Could you elaborate on "off-while-idle" and "retention-while-idle" ? I'm not sure I follow what you mean. Daniel -- 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 20:20 2010/5/6 Tony Lindgren <tony(a)atomide.com>: > * Arve Hj�nnev�g <arve(a)android.com> [100505 21:11]: >> On Wed, May 5, 2010 at 5:05 PM, Tony Lindgren <tony(a)atomide.com> 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: >> >> >> >> >> >> >> >> Oh, like tell the modem that user mode has handled the ring event and >> >> >> >> its ok to un-block? >> >> >> > >> >> >> > No, that's not how it works. �It would go like this: >> >> >> > >> >> >> > � � � �The modem IRQ handler queues its event to the input subsystem. >> >> >> > � � � �As it does so the input subsystem enables a suspend blocker, >> >> >> > � � � �causing the system to stay awake after the IRQ is done. >> >> > >> >> > How about instead the modem driver fails to suspend until it's done? >> >> > >> >> > Each driver could have a suspend_policy sysfs entry with options such >> >> > as [ forced | safe ]. The default would be forced. Forced would >> >> > be the current behaviour, while safe would refuse suspend until the >> >> > driver is done processing. >> >> > >> >> >> > � � � �The user program enables its own suspend blocker before reading >> >> >> > � � � �the input queue. �When the queue is empty, the input subsystem >> >> >> > � � � �releases its suspend blocker. >> >> > >> >> > And also the input layer could refuse to suspend until it's done. >> >> > >> >> >> > � � � �When the user program finishes processing the event, it >> >> >> > � � � �releases its suspend blocker. �Now the system can go back to >> >> >> > � � � �sleep. >> >> > >> >> > And here the user space just tries to suspend again when it's done? >> >> > It's not like you're trying to suspend all the time, so it should be >> >> > OK to retry a few times. >> >> >> >> We actually are trying to suspend all the time -- that's our basic >> >> model -- suspend whenever we can when something doesn't prevent it. >> > >> > Maybe that state could be kept in some userspace suspend policy manager? >> > >> >> >> > 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. >> > >> >> If we fail to suspend, don't we have to resume all the drivers that >> >> suspended before the one that failed? �(Maybe I'm mistaken here) >> > >> > Sure, but I guess that should be a rare event that only happens when >> > you try to suspend and something interrupts the suspend. >> > >> >> 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. >> >> 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. -- 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 6 May 2010 22:10
* Matthew Garrett <mjg(a)redhat.com> [100506 11:39]: > On Thu, May 06, 2010 at 11:33:35AM -0700, Tony Lindgren wrote: > > * Matthew Garrett <mjg(a)redhat.com> [100506 10:39]: > > > On Thu, May 06, 2010 at 10:38:08AM -0700, Tony Lindgren wrote: > > > > > > > If your userspace keeps polling and has runaway timers, then you > > > > could suspend it's parent process to idle the system? > > > > > > If your userspace is suspended, how does it process the events that > > > generated a system wakeup? If we had a good answer to that then suspend > > > blockers would be much less necessary. > > > > 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. > > And the untrusted userspace code that's waiting for a network packet? > Adding a few seconds of latency isn't an option here. Hmm well hitting retention and wake you can basically do between jiffies. Hitting off mode in idle has way longer latencies, but still in few hundred milliseconds or so, not seconds. And cpuidle pretty much takes care of hitting the desired C state for you. This setup is totally working on Nokia N900 for example, it's hitting off modes in idle and running all the time, it never suspends. 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/ |