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: Rafael J. Wysocki on 26 May 2010 18:50 On Thursday 27 May 2010, Alan Stern wrote: > On Wed, 26 May 2010, Rafael J. Wysocki wrote: > > > > The reason is simple: When a user process initiates an opportunistic > > > suspend, you make it wait in an interruptible sleep until all the > > > kernel suspend blockers are released. No polling. If another user > > > thread decides in the meantime that it needs to block the suspend, it > > > sends a signal to the power manager process. > > > > > > In fact, other threads should signal the power manager process whenever > > > they want to block or unblock suspends. That way the power manager > > > process can spend all its time sleeping, without doing any polling. > > > > I still see an issue here. Namely, if the power manager is in user space and > > it's signaled to suspend, it has to ask the kernel to do that, presumably by > > writing something to a sysfs file. Then, if the kernel blocks the suspend, the > > power manager waits until the block is released. Now, it should go back and > > check if user space still doesn't block suspend and if so, wait until the block > > is released and start over. With all suspend blockers in the kernel this > > looping behavior is avoidable. > > I must be missing something. In Arve's patch 1/8, if the system is in > opportunistic suspend, and a wakeup event occurs but no suspend > blockers get enabled by the handler, what causes the system to go back > into suspend after the event is handled? Isn't that a loop of some > sort? Well, yes it is. Rafael -- 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 19:10 On Wed, May 26, 2010 at 3:12 PM, Alan Stern <stern(a)rowland.harvard.edu> wrote: > On Wed, 26 May 2010, Rafael J. Wysocki wrote: > >> > The reason is simple: When a user process initiates an opportunistic >> > suspend, you make it wait in an interruptible sleep until all the >> > kernel suspend blockers are released. �No polling. �If another user >> > thread decides in the meantime that it needs to block the suspend, it >> > sends a signal to the power manager process. >> > >> > In fact, other threads should signal the power manager process whenever >> > they want to block or unblock suspends. �That way the power manager >> > process can spend all its time sleeping, without doing any polling. >> >> I still see an issue here. �Namely, if the power manager is in user space and >> it's signaled to suspend, it has to ask the kernel to do that, presumably by >> writing something to a sysfs file. �Then, if the kernel blocks the suspend, the >> power manager waits until the block is released. �Now, it should go back and >> check if user space still doesn't block suspend and if so, wait until the block >> is released and start over. �With all suspend blockers in the kernel this >> looping behavior is avoidable. > > I must be missing something. �In Arve's patch 1/8, if the system is in > opportunistic suspend, and a wakeup event occurs but no suspend > blockers get enabled by the handler, what causes the system to go back > into suspend after the event is handled? �Isn't that a loop of some > sort? > Yes it is a loop. I think what you are missing is that it only loops repeatedly if the driver that aborts suspend does not use a suspend blocker. > And even if it isn't, so what? �What's wrong with looping behavior? It is a significant power drain. > Especially a loop that's as short as this one and spends almost all of > its time sleeping. �Think how much harder it would be to write programs > if you weren't allowed to use any loops. �:-) > > Alan Stern > > -- 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: Alan Stern on 26 May 2010 20:50 On Wed, 26 May 2010, Arve Hj�nnev�g wrote: > > I must be missing something. �In Arve's patch 1/8, if the system is in > > opportunistic suspend, and a wakeup event occurs but no suspend > > blockers get enabled by the handler, what causes the system to go back > > into suspend after the event is handled? �Isn't that a loop of some > > sort? > > > > Yes it is a loop. I think what you are missing is that it only loops > repeatedly if the driver that aborts suspend does not use a suspend > blocker. You mean "the driver that handles the wakeup event". I was asking what happened if suspend succeeded and then a wakeup occurred. But yes, if a suspend blocker is used then its release causes another suspend attempt, with no looping. > > And even if it isn't, so what? �What's wrong with looping behavior? > > It is a significant power drain. Not in the situation I was discussing. 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: Arve Hjønnevåg on 26 May 2010 21:00 2010/5/26 Alan Stern <stern(a)rowland.harvard.edu>: > On Wed, 26 May 2010, Arve Hj�nnev�g wrote: > >> > I must be missing something. �In Arve's patch 1/8, if the system is in >> > opportunistic suspend, and a wakeup event occurs but no suspend >> > blockers get enabled by the handler, what causes the system to go back >> > into suspend after the event is handled? �Isn't that a loop of some >> > sort? >> > >> >> Yes it is a loop. I think what you are missing is that it only loops >> repeatedly if the driver that aborts suspend does not use a suspend >> blocker. > > You mean "the driver that handles the wakeup event". �I was asking what > happened if suspend succeeded and then a wakeup occurred. �But yes, if > a suspend blocker is used then its release causes another suspend > attempt, with no looping. > >> > And even if it isn't, so what? �What's wrong with looping behavior? >> >> It is a significant power drain. > > Not in the situation I was discussing. > If you meant it spend most of the time suspended, then I agree. It only wastes power when a driver blocks suspend by returning an error from its suspend hook and we are forced to loop doing no useful work. -- 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: Neil Brown on 27 May 2010 03:30
On Wed, 26 May 2010 14:20:51 +0100 Matthew Garrett <mjg59(a)srcf.ucam.org> wrote: > On Wed, May 26, 2010 at 02:57:45PM +0200, Peter Zijlstra wrote: > > > I fail to see why. In both cases the woken userspace will contact a > > central governing task, either the kernel or the userspace suspend > > manager, and inform it there is work to be done, and please don't > > suspend now. > > Thinking about this, you're right - we don't have to wait, but that does > result in another problem. Imagine we get two wakeup events > approximately simultaneously. In the kernel-level universe the kernel > knows when both have been handled. In the user-level universe, we may > have one task schedule, bump the count, handle the event, drop the count > and then we attempt a suspend again because the second event handler > hasn't had an opportunity to run yet. We'll then attempt a suspend and > immediately bounce back up. That's kind of wasteful, although it'd be > somewhat mitigated by checking that right at the top of suspend entry > and returning -EAGAIN or similar. > (I'm coming a little late to this party, so excuse me if I say something that has already been covered however...) The above triggers a sequence of thoughts which (When they settled down) look a bit like this. At the hardware level, there is a thing that we could call a "suspend blocker". It is an interrupt (presumably level-triggered) that causes the processor to come out of suspend, or not to go into it. Maybe it makes sense to export a similar thing from the kernel to user-space. When any event happens that would wake the device (and drivers need to know about these already), it would present something to user-space to say that the event happened. When user-space processes the event, it clears the event indicator. When there are no more current event indicators, userspace is allowed to request a suspend. Obviously this could fail as an event could happen at any moment, but the same is true when the kernel asks the device to suspend, an interrupt might happen immediately to stop it. But in either case an event will be reported. So when userspace requests a suspend and it fails, it will see events reported and so will wait for them to be handled. I imagine a sysfs directory with files that appear when events are pending. We could have some separate mechanism for user-space processes to request that the suspend-daemon not suspend. Then it suspends whenever there are no pending requests from user-space or from the kernel. The advantage of this model of suspend-blockers is that it is a close analogue for something that already exists in hardware so it isn't really creating new concepts, just giving the Linux virtual-machine features that have proved themselves in physical machines. The cost is that any wake-up event needs to not only be handled, but also explicitly acknowledged by clearing the relevant suspend-blocker (i.e. removing the file from sysfs, or whatever interface was ultimately chosen). I'm hoping that isn't a big cost. NeilBrown -- 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/ |