[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 13:50 On Fri, 2010-05-07 at 18:36 +0100, Matthew Garrett wrote: > On Fri, May 07, 2010 at 10:20:37AM -0700, Daniel Walker wrote: > > > MSM doesn't have those power states unfortunately .. Your kind of > > suggesting what I was suggesting in that we should suspend in idle. Your > > hardware can do it easier tho since your have power states that are > > equal to suspend. > > 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? 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 14:00 * Daniel Walker <dwalker(a)fifo99.com> [100507 10:15]: > On Thu, 2010-05-06 at 19:00 -0700, Tony Lindgren wrote: > > > Oh some SoC devices like omap hit retention or off modes in the idle loop. > > That brings down the idle consumption of a running system to minimal > > levels. It's basically the same as suspending the device in every idle loop. > > > > The system wakes up every few seconds or so, but that already provides > > battery life of over ten days or so on an idle system. Of course the > > wakeup latencies are in milliseconds then. > > MSM doesn't have those power states unfortunately .. Your kind of > suggesting what I was suggesting in that we should suspend in idle. Your > hardware can do it easier tho since your have power states that are > equal to suspend. You might be able to implement suspend-while-idle with cpuidle and a custom idle function on MSM. That is if MSM supports waking to a timer event and some device interrupts. However, if it only wakes to pressing some power button, then you will get missed timers and the system won't behave in a normal way. Maybe you could still kill -STOP the misbehaving apps, then keep the idle system running until some timer expires, then when no activity, echo mem > /sys/power/state? 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:00 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. -- 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:00 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. > 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. -- 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: Daniel Walker on 7 May 2010 14:10
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. 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/ |