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: Peter Zijlstra on 26 May 2010 09:00 On Wed, 2010-05-26 at 13:49 +0100, Matthew Garrett wrote: Lack of quoting makes it hard to see what your 'this' refers to. I'll assume its the userspace suspend manager. > While this approach could be made to work, it's ugly in other ways. > After wakeup, userspace has to pause for a while before it can trigger > another sleep in order to give all the apps an opportunity to check for > wakeup events and block suspend if they wish to. That's additional > runtime that doesn't exist in the kernel-mediated case. 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. Also, since we did get woken, there clearly is work to do and we should only try suspending again once someone did inform us of completing it. In both cases, once the event is fully handled, will there be communication of this fact and suspend can be attempted. I don't see a reason to 'wait' for anything -- except maybe speculate on the avgerage wakeup rate and decide not to suspend quite yet. -- 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 26 May 2010 09:00 While this approach could be made to work, it's ugly in other ways. After wakeup, userspace has to pause for a while before it can trigger another sleep in order to give all the apps an opportunity to check for wakeup events and block suspend if they wish to. That's additional runtime that doesn't exist in the kernel-mediated case. -- 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: Matthew Garrett on 26 May 2010 09:30 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. -- 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: Alan Stern on 26 May 2010 10:00 On Tue, 25 May 2010, Dmitry Torokhov wrote: > > How is that not polling? If the user is holding down a key, the keypad > > driver has to block suspend, and user space will try to suspend again > > and again and again... > > > > If your userpsace is that stupid - sure. However, you can: > > 1. Notify the suspend manager process that he rest of your userspace is > busy handling keystrokes so that it does not try to suspend while there > are events pending. > > 2. Wait a tiny bit after last application notified you that it finished > processing events. This is more complicated than necessary. Arve is wrong; my suggested design does not require polling. 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. > So basically the difference is that with in-kernel suspend blockers, > there is a tiny window where we haven't started the suspend yet but are > about to the driver has a chance to prevent entire system from starting > sleep. > > Without the blocker we may start suspending and will stop midcycle. We > may be even better off in the end since we could leave some devices > still powered down after aborting system-wide suspend. That's not so easy. The design of the PM core requires that when the system wakes up from suspend (or from an aborted suspend attempt), all devices should go to full-power-on. This is explained in section 6 of Documentation/power/runtime_pm.txt. The decision over whether to use kernel-space suspend blockers vs. aborting suspends when queues are non-empty comes down to a tradeoff: Suspend blockers involve a little more code (to create, destroy, enable, and disable them) plus a little extra runtime overhead each time an event occurs. (Some people may object to this extra overhead, although so far nobody in this discussion has done so.) Suspend blockers eliminate the extra overhead involved in starting suspends that are just going to be aborted. Suspend blockers offer extra debugging and accountability (the user can find out which subsystems are responsible for keeping the system awake). Which way you think the tradeoff should go is a subjective decision. I think that kernel suspend blockers are acceptable. 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: James Bottomley on 26 May 2010 12:20
On Wed, 2010-05-26 at 13:29 +0300, Pekka Enberg wrote: > Yup, I don't quite get Arve's argument either. C code can interact > with Java code (and vice versa) just fine in userspace. This is an incorrect statement. It's possible for java to call C via the JNI, even though there are quite a few gotchas that mean not just *any* C code can do it (been there, tripped over some of them, although they were all ultimately ironed out). It's very difficult for C to call directly into Java without being specially coded because it involves creating and managing a JVM (so in general, arbitrary C code can't do this). The usual way we do C -> Java is process to process via some intermediary like RPC or Corba or SOAP (or even JSON) ... which gets very messy for a mobile device. On Wed, 2010-05-26 at 12:21 +0200, Peter Zijlstra wrote: > So provide a C interface to it as well? The way Android is currently coded, all user space suspend blocks are handled in Java code at what's called the Frameworks layer (Frameworks is the Java API for apps) this is also how the suspend permissions are managed and presented to the user. The few C applications which block suspend just manipulate the device directly. > Surely you can have the java thing have a unix socket or something a C > app can talk to. That shouldn't be hard at all. > > Or make the suspend manager a C proglet and provide a JNI interface, > or whatever. It's a fairly large piece of code to try to rewrite in C, so I don't think that's feasible on a reasonable timescale. Android does have the concept of special sockets that can be used to communicate from less to more privileged processes (it has a very segmented runtime model), so these might be usable ... they have a drawback that they're essentially named pipes, so no multiplexing, but one per suspend influencing C process shouldn't be a huge burden. 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/ |