[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 12:30 * James Kosin <james.kosin.04(a)cnu.edu> [100506 20:14]: > On 5/6/2010 11:10 PM, Arve Hjønnevåg wrote: > >>>> > >>> One if the benefit we get from using suspend is that an unprivileged > >>> app that does not have access to suspend blockers cannot prevent > >>> suspend. You lose this advantage if you trigger suspend only from the > >>> idle task. This assumes that you're using cached values for echo mem > /sys/power/state and the system keeps on running. IMHO if you want to keep the system running, then you should just use cpuidle and implement good idle modes. Then when someting in the userspace knows you've been idle long enough, you can suspend. > >> If the process (privileged or unprivileged) doesn't want to suspend, why > >> not just provide an interface to allow suspend to be turned off at the > >> user level. This could block the suspend cycle in itself, and you > >> shouldn't need fine grained off/on cycles. If an application really > >> needs the system not to suspend then they (the user) should know the > >> consequences and power requirements for such a task. > >> > >> I didn't say it had to be only from the idle task; but, that is the most > >> logical place. If the other threads are not idle then they really > >> require work and will most likely already have a bock on the suspend anyway. > >> > >> > > I think you missed my point. Unprivileged processes should not be > > allowed to prevent suspend. You could just freeze the GUI process based on some policy if you worry about misbehaving timers in various apps. This way the cpuidle modes will allow you to run some userspace policy daemon. And then that can suspend if needed based on how it's configured. > Ah, you want a way for the system to suspend (and enforce the suspend) > when only unprivileged processes are the only thing running.... > > That would mean a lot of work defining the unprivileged (or privileged) > processes, and properly suspending (or enforcing) when needed. Yuck. > Sorry I commented then, this is really getting deep into what I love to > do at work. Hmm, yeah sounds a bit messy. 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 13:20 On Thu, May 06, 2010 at 07:05:41PM -0700, Tony Lindgren wrote: > * Matthew Garrett <mjg(a)redhat.com> [100506 11:39]: > > And the untrusted userspace code that's waiting for a network packet? > > Adding a few seconds of latency isn't an option here. > > Hmm well hitting retention and wake you can basically do between > jiffies. Hitting off mode in idle has way longer latencies, > but still in few hundred milliseconds or so, not seconds. 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? -- 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 13:30 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. 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 13:40 * Matthew Garrett <mjg(a)redhat.com> [100507 10:08]: > On Thu, May 06, 2010 at 07:05:41PM -0700, Tony Lindgren wrote: > > * Matthew Garrett <mjg(a)redhat.com> [100506 11:39]: > > > And the untrusted userspace code that's waiting for a network packet? > > > Adding a few seconds of latency isn't an option here. > > > > Hmm well hitting retention and wake you can basically do between > > jiffies. Hitting off mode in idle has way longer latencies, > > but still in few hundred milliseconds or so, not seconds. > > 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. For the misbehaving stopped apps, maybe they could be woken to deal with the incoming network data with sysfs_notify? 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 13:40
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. -- 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/ |