On Thu, May 27, 2010 at 05:23:54PM +1000, Neil Brown wrote: > On Wed, 26 May 2010 14:20:51 +0100 > Matthew Garrett <mjg59@xxxxxxxxxxxxx> 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. we did I proposed making the suspend enabling a oneshot type of thing and all sorts of weak arguments came spewing forth. I honestly couldn't tell if I was reading valid input or fanboy BS. --mgross > > 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 > _______________________________________________ > linux-pm mailing list > linux-pm@xxxxxxxxxxxxxxxxxxxxxxxxxx > https://lists.linux-foundation.org/mailman/listinfo/linux-pm _______________________________________________ linux-pm mailing list linux-pm@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/linux-pm
