[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: Tony Lindgren on 7 May 2010 14:10 * Matthew Garrett <mjg(a)redhat.com> [100507 10:46]: > On Fri, May 07, 2010 at 10:35:49AM -0700, Tony Lindgren wrote: > > * Matthew Garrett <mjg(a)redhat.com> [100507 10:08]: > > > The situation is this. You've frozen most of your userspace because you > > > don't trust the applications. One of those applications has an open > > > network socket, and policy indicates that receiving a network packet > > > should generate a wakeup, allow the userspace application to handle the > > > packet and then return to sleep. What mechanism do you use to do that? > > > > I think the ideal way of doing this would be to have the system running > > and hitting some deeper idle states using cpuidle. Then fix the apps > > so timers don't wake up the system too often. Then everything would > > just run in a normal way. > > Effective power management in the face of real-world applications is a > reasonable usecase. Sure there's no easy solution to misbehaving apps. > > For the misbehaving stopped apps, maybe they could be woken > > to deal with the incoming network data with sysfs_notify? > > How would that work? Have the kernel send a sysfs_notify on every netwrk > packet and have a monitor app listen for it and unfreeze the rest of > userspace if it's frozen? That sounds expensive. Yeah maybe there are better ways of dealing with this. Maybe deferred timers would help some so all the apps could be allowed to run until some power management policy decides to suspend the whole device. 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: Tony Lindgren on 7 May 2010 14:20 * Daniel Walker <dwalker(a)fifo99.com> [100507 10:56]: > On Fri, 2010-05-07 at 18:51 +0100, Matthew Garrett wrote: > > On Fri, May 07, 2010 at 10:40:43AM -0700, Daniel Walker wrote: > > > On Fri, 2010-05-07 at 18:36 +0100, Matthew Garrett wrote: > > > > If your wakeup latencies are sufficiently low and you have fine-grained > > > > enough control over your hardware then suspend in idle is a reasonable > > > > thing to do - but if you have a userspace app that's spinning then > > > > that doesn't solve the issue. > > > > > > If there's a userspace app spinning then you don't go idle (or that's my > > > assumption anyway). You mean like repeatedly blocking and unblocking > > > right? > > > > Right, that's the problem. idle-based suspend works fine if your > > applications let the system go idle, but if your applications are > > anything other than absolutely perfect in this respect then you consume > > significant power even if the device is sitting unused in someone's > > pocket. > > True .. I'd wonder how an OMAP based devices deal with that issue, since > they would have that exact problem. According to what Tony is telling > us. Actually a bogus userspace can do a lot more than just consume power > you could hang the system too. There's nothing being done on omaps specifically, up to the device user space to deal with that. From the kernel point of view the omaps just run, and if idle enough, the device starts hitting the retention and off modes in idle. But the system keeps on running all the time, no need to suspend really. I don't think there's a generic solution to the misbehaving apps. I know a lot of work has been done over past five years or so to minimize the timer usage in various apps. But if I installed some app that keeps the system busy, it would drain the battery. I guess some apps could be just stopped when the screen blanks unless somehow certified for the timer usage or something similar.. 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 7 May 2010 14:30 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. -- 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 7 May 2010 14:50 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? -- 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 14:50
* 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? 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/ |