[PATCH 1/8] PM: Add suspend block api.
in [Kernel]
|
Prev: [PATCH 7/8] Input: Block suspend while event queue is not empty.
Next: [PATCH 3/8] PM: suspend_block: Abort task freezing if a suspend_blocker is active.
From: Daniel Walker on 7 May 2010 15:10 On Fri, 2010-05-07 at 19:46 +0100, Matthew Garrett wrote: > On Fri, May 07, 2010 at 11:43:33AM -0700, Tony Lindgren wrote: > > * Matthew Garrett <mjg(a)redhat.com> [100507 11:23]: > > > On Fri, May 07, 2010 at 11:01:52AM -0700, Tony Lindgren wrote: > > > > * Matthew Garrett <mjg(a)redhat.com> [100507 10:46]: > > > > > Effective power management in the face of real-world applications is a > > > > > reasonable usecase. > > > > > > > > Sure there's no easy solution to misbehaving apps. > > > > > > That's the point of the suspend blockers. > > > > To me it sounds like suspending the whole system to deal with > > some misbehaving apps is an overkill. Sounds like kill -STOP > > the misbehaving apps should do the trick? > > Freezer cgroups would work better, but it doesn't really change the > point - if that application has an open network socket, how do you know > to resume that application when a packet comes in? suspend blockers can get abused also .. I had my phone in my pocket and accidentally ran "Google Talk" or something. It must have kept the screen on or kept the phone from suspending, so the battery drained completely over the course of an hour or so. Daniel -- 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 7 May 2010 15:30 * Daniel Walker <dwalker(a)fifo99.com> [100507 12:01]: > On Fri, 2010-05-07 at 19:46 +0100, Matthew Garrett wrote: > > On Fri, May 07, 2010 at 11:43:33AM -0700, Tony Lindgren wrote: > > > * Matthew Garrett <mjg(a)redhat.com> [100507 11:23]: > > > > On Fri, May 07, 2010 at 11:01:52AM -0700, Tony Lindgren wrote: > > > > > * Matthew Garrett <mjg(a)redhat.com> [100507 10:46]: > > > > > > Effective power management in the face of real-world applications is a > > > > > > reasonable usecase. > > > > > > > > > > Sure there's no easy solution to misbehaving apps. > > > > > > > > That's the point of the suspend blockers. > > > > > > To me it sounds like suspending the whole system to deal with > > > some misbehaving apps is an overkill. Sounds like kill -STOP > > > the misbehaving apps should do the trick? > > > > Freezer cgroups would work better, but it doesn't really change the > > point - if that application has an open network socket, how do you know > > to resume that application when a packet comes in? No idea, but that still sounds a better situation to me than trying to deal with that for a suspended system! :) > suspend blockers can get abused also .. I had my phone in my pocket and > accidentally ran "Google Talk" or something. It must have kept the > screen on or kept the phone from suspending, so the battery drained > completely over the course of an hour or so. Yeah I guess there's nothing stopping that. 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 7 May 2010 15:40 On Fri, May 07, 2010 at 12:28:37PM -0700, Tony Lindgren wrote: > * Daniel Walker <dwalker(a)fifo99.com> [100507 12:01]: > > On Fri, 2010-05-07 at 19:46 +0100, Matthew Garrett wrote: > > > Freezer cgroups would work better, but it doesn't really change the > > > point - if that application has an open network socket, how do you know > > > to resume that application when a packet comes in? > > No idea, but that still sounds a better situation to me than > trying to deal with that for a suspended system! :) Suspend blocks deal with that problem. Nobody has yet demonstrated a workable alternative solution. -- 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 7 May 2010 16:00 * Matthew Garrett <mjg(a)redhat.com> [100507 12:29]: > On Fri, May 07, 2010 at 12:28:37PM -0700, Tony Lindgren wrote: > > * Daniel Walker <dwalker(a)fifo99.com> [100507 12:01]: > > > On Fri, 2010-05-07 at 19:46 +0100, Matthew Garrett wrote: > > > > Freezer cgroups would work better, but it doesn't really change the > > > > point - if that application has an open network socket, how do you know > > > > to resume that application when a packet comes in? > > > > No idea, but that still sounds a better situation to me than > > trying to deal with that for a suspended system! :) > > Suspend blocks deal with that problem. Nobody has yet demonstrated a > workable alternative solution. Well there are obviously two paths to take, I think both of them should work. The alternative to suspend blockers is: - Implement a decent kernel idle function for the hardware and use cpuidle to change the c states. The dyntick stuff should already work for most hardware. - Fix the core userspace apps to minimize timers. - Deal with broken apps whichever way you want in the userspace. - Optionally, do echo mem > /sys/power/state based on some product specific logic in the userspace. The advantage of this is that no kernel changes are needed, except for implementing the custom idle function for the hardware. And this kind of setup has been in use for about five years. And, you can keep the system running constantly if you have hardware that supports good idle modes, then you don't even need to suspend at all. The core problems I see with suspend blockers are following, please correct me if I'm wrong: - It is caching the value of echo mem > /sys/power/state and misusing it for runtime power management as the system still keeps running after trying to suspend. Instead, the kernel idle function and cpuidle should be used if the kernel keeps running. - They require patching all over the drivers and userspace. - Once the system is suspended, it does not run. And the apps don't behave in a standard way because the system does not wake to timer interrupts. I agree that we need to be able to echo mem > /sys/power/state in an atomic way. So if there are problems with that, those issues should be fixed. Cheers, 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 7 May 2010 16:30
On Fri, May 07, 2010 at 12:55:48PM -0700, Tony Lindgren wrote: > - Deal with broken apps whichever way you want in the userspace. If we could do this then there would be no real need for 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/ |