Suspend block api (version 6)
in [Kernel]
|
Prev: mm: fix race between shift_arg_pages and rmap_walk
Next: [PATCH -next] power: fix block_io.c printk warning
From: Tony Lindgren on 11 May 2010 12:40 * Matthew Garrett <mjg(a)redhat.com> [100511 09:10]: > On Tue, May 11, 2010 at 09:12:28AM -0700, Tony Lindgren wrote: > > > To me it sounds like this should only be allowed to happen when you do: > > > > # echo 1 > /sys/power/suspend_while_idle > > > > As it kills the timers and leads to non-standard behaviour of the apps > > as they won't run :) > > > > And then the remaining question is how to make sure the use cases > > below can be handled in a clean way. > > That's handled by the /sys/power/policy opportunistic/forced switch. OK, so can the suspend blocker then become just: # Block suspend while idle, system stays running # echo default > /sys/power/policy and the when it's OK to suspend: # Allow suspend while idle, system suspends when it hits kernel idle loop # echo opportunistic > /sys/power/policy or do you still need something more to ensure the data gets into your app and be handled? The part I really don't like is the idea of patching all over the drivers and userspace for the wakelocks/suspendblocks. 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/
From: Matthew Garrett on 11 May 2010 12:50 On Tue, May 11, 2010 at 09:36:33AM -0700, Tony Lindgren wrote: > OK, so can the suspend blocker then become just: > > # Block suspend while idle, system stays running > # echo default > /sys/power/policy > > and the when it's OK to suspend: > > # Allow suspend while idle, system suspends when it hits kernel idle loop > # echo opportunistic > /sys/power/policy > > or do you still need something more to ensure the data gets into your > app and be handled? Yes. You still need suspend blocks. > The part I really don't like is the idea of patching all over the drivers > and userspace for the wakelocks/suspendblocks. I don't like the idea either, but given that nobody has actually provided any other ideas that would actually work then I don't think we've got a great deal of choice. -- 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: Tony Lindgren on 11 May 2010 13:00 * Matthew Garrett <mjg(a)redhat.com> [100511 09:41]: > On Tue, May 11, 2010 at 09:36:33AM -0700, Tony Lindgren wrote: > > OK, so can the suspend blocker then become just: > > > > # Block suspend while idle, system stays running > > # echo default > /sys/power/policy > > > > and the when it's OK to suspend: > > > > # Allow suspend while idle, system suspends when it hits kernel idle loop > > # echo opportunistic > /sys/power/policy > > > > or do you still need something more to ensure the data gets into your > > app and be handled? > > Yes. You still need suspend blocks. Maybe not if echo opportunistic > /sys/power/policy gets cleared by the kernel if the kernel idle loop can't make it. That means something has blocked the suspend attempt in a driver for example. The system keeps running, and the userspace can deal with the situation. > > The part I really don't like is the idea of patching all over the drivers > > and userspace for the wakelocks/suspendblocks. > > I don't like the idea either, but given that nobody has actually > provided any other ideas that would actually work then I don't think > we've got a great deal of choice. If the opportunistic kernel flag is one time attempt only, then you could take care of the wakelock/suspendblock handling in the userspace completely. And once the userspace wakelock/suspendblock is cleared, the userspace can again echo opportunistic > /sys/power/policy. 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/
From: Matthew Garrett on 11 May 2010 13:10 On Tue, May 11, 2010 at 09:58:21AM -0700, Tony Lindgren wrote: > * Matthew Garrett <mjg(a)redhat.com> [100511 09:41]: > > Yes. You still need suspend blocks. > > Maybe not if echo opportunistic > /sys/power/policy gets cleared by > the kernel if the kernel idle loop can't make it. That means something > has blocked the suspend attempt in a driver for example. The system > keeps running, and the userspace can deal with the situation. So an event arrives just as userspace does this write. How do you avoid the race? Plausible answers mostly appear to end up looking like suspend blockers. -- 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: Tony Lindgren on 11 May 2010 13:30
* Matthew Garrett <mjg(a)redhat.com> [100511 09:59]: > On Tue, May 11, 2010 at 09:58:21AM -0700, Tony Lindgren wrote: > > * Matthew Garrett <mjg(a)redhat.com> [100511 09:41]: > > > Yes. You still need suspend blocks. > > > > Maybe not if echo opportunistic > /sys/power/policy gets cleared by > > the kernel if the kernel idle loop can't make it. That means something > > has blocked the suspend attempt in a driver for example. The system > > keeps running, and the userspace can deal with the situation. > > So an event arrives just as userspace does this write. How do you avoid > the race? Plausible answers mostly appear to end up looking like suspend > blockers. Assuming you attempt suspend in a custom pm_idle function, any driver handling the event can fail the suspend attempt. And that would clear the opportunistic suspend flag. And the userspace would be still running and could handle the event. And when the userspace is done, it can again echo opportunistic > /sys/power/policy. For the failed suspend path in the kernel, currently the kernel would unwind back all the drivers because of the failed driver, but that path should be possible to optimize. 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/ |