On Fri, 4 Jun 2010 01:23:02 +0200 Ingo Molnar <mingo@xxxxxxx> wrote: > Btw., i'd like to summarize the scheduler based suspend scheme proposed by > Thomas Gleixner, Peter Zijlstra and myself. I found no good summary of it in > the big thread, and there are also new elements of the proposal: Hi I would like to summarise the alternate proposal that I an others have suggested in a variety of different forms. It starts from the premise that 1/ Android developers actually like the "big hammer" aspect of suspend. Initiating suspend powers down some devices, puts others in low power states, freezes all processes and generally puts the device to sleep with a well defined and easily controlled (at the whole-of-system level) set of events that will wake from suspend. This is a big part of the Android approach to power-saving and I'm guessing they are not keen to depart from it. 2/ The main problem with using suspend as-is is that it is racy. The purpose of suspend is to put the device to sleep until a wake-event occurs. When that wake-event occurs at much the same time that suspend is requested races can occur. We want a wake-event to not only wake the device, to be keep the device awake while the wake-event is being handled, and to cancel any suspend that was initiated before the wake event completed. We need to understand "wake event" in an holistic sense. If a key press is expected to brighten the screen and make a glyph appear, and if that key press is considered to be a wake-event, then the glyph appearing must also be a part of the wake event. For such a holistic wake-event to fully block/cancel a suspend there much be some mechanism for hand-over of wake-events from kernel-space to user-space. Given those premises, google's suspend-blocker approach was to allow a kernel thread to initiate suspend whenever nothing was stopping it, and to allow both drivers and user processes to block that suspend while handling a wake event (or anything else that needed to keep the device awake). In this case the hand-over is fairly straight forward as the kernel thread as full knowledge and can easily wait for all sorts of things. The alternate proposal is simply to have user-space initiate a suspend (as is already possible), user-space processes can then trivially block that suspend through any of a number of IPC approaches, and kernel space drivers can block/abort suspend by explicitly requesting a block. The variety of alternate proposals comes from a variety of ways to modify the semantics of "ask for a suspend" in such a way that userspace can discover when there are kernel-space blocks, and can wait for them to be released without spinning. A sample modification (which I think is different to all the ones mentioned so far, and hopefully pulls out the best of them all) is to allow userspace to write e.g. "mem_safe" rather than "mem" to /sys/power/state. The 'safe' implies it is safe from races. When this is written, the process sleeps in an interruptible state until all in-kernel suspend blocks have been dropped. If any such suspend blocks were found, or if a signal is received, the request aborts. Only if there were no suspend blocks and no pending signals does the suspend progress. wake-events in the kernel then need to be tracked all the way to user-space, and the in-kernel lock is only dropped when the event is consumed by user-space. User-space must take some sort of lock to ensure no new suspend is requested before consuming any wake-events from the kernel. I believe this is very close to what android has today, only with a much smaller change to the user-space interface, which I believe to be the thing that has been found most objectionable. I does still require a degree of event-tracking within the kernel which might still be objectionable - I'm not so sure about different people's positions on that. Thanks, NeilBrown -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
