suspend blockers & Android integration
in [Kernel]
|
Prev: How do I ignore the changes made by CVS keyword substitution efficiently?
Next: [PATCH 1/2] x86: make save_stack_address() !CONFIG_FRAME_POINTER friendly
From: Florian Mickler on 7 Jun 2010 08:20 On Sun, 6 Jun 2010 04:14:09 -0700 (PDT) david(a)lang.hm wrote: > On Sun, 6 Jun 2010, Florian Mickler wrote: > > > On Sun, 6 Jun 2010 12:19:08 +0200 > > Vitaly Wool <vitalywool(a)gmail.com> wrote: > > > >> 2010/6/6 <david(a)lang.hm>: > >> > >>> as an example (taken from this thread). > >>> > >>> system A needs to wake up to get a battery reading, store it and go back to > >>> sleep, It does so every 10 seconds. But when it does so it only runs the one > >>> process and then goes back to sleep. > >>> > >>> system B has the same need, but wakes up every 10 minutes. but when it does > >>> so it fully wakes up and this allows the mail app to power up the radio, > >>> connect to the Internet and start checking for new mail before oppurtunistic > >>> sleep shuts things down (causing the mail check to fail) > >>> > >>> System A will last considerably longer on a battery than System B. > >> > >> Exactly, thanks for pointing out the specific example :) > >> > >> ~Vitaly > > > > This does not affect suspend_blockers nor does suspend_blockers > > interfere with that. > > > > Suspend_blockers allow the system to suspend ("mem">/sys/power/state > > suspend), when the userspace decides that the device is not in use. > > > > So implementing suspend_blockers support does not impact any > > optimizations done to either system A nor system B. > > Actually, it does. > > system A is what's being proposed by kernel developers, where the > untrusted stuff is in a different cgroup and what puts the system to sleep > is 'normal' power management. It doesn't sleep as long, but when it wakes > up the untrusted stuff is still frozen, so it doesn't stay awake long, or > do very much. > > System B is suspend blockers where you are either awake or asleep, and > when you wake up you wake up fully, but oppertunistic sleep can interrupt > untrusted processes at any time. The system sleeps longer (as fewer things > can wake it), but when it wakes up it's fully awake. > > David Lang You say, that coming back from suspend takes the system to full power (and everything runs) before it begins the descend into runtime-low-power? But are you referring to the fact that coming back from suspend starts in the zero-idle-state (i.e. "consumes extra power") or that all processes run when it is not suspended? Because the latter would of course (theretically) profit from the framework-controlled-cgroup-freeze/thaw (with and without opportunistic suspend) while the former should be a problem that both opportunistic suspend as well as suspend-from-idle have. Or not? So, here is the question I'm asking myself: If System A were to be complemented by suspend_blockers, wouldn't it still be better? With System A you could try to do a really sophisticated power-management scheme and so on... but as soon as you allow 3rd-Party Apps, how do you manage their cross-dependencies? I.e. you can not automatically detect when App1 needs App2 to function. You need to allow all 3rd-Party apps to run as a group. So you can perhaps partition your software stack into "untrusted applications" and different groups of software with audited dependencies. If one group interacts with another group (as will be the case at least with the "untrusted applications" group) you have to have them both running at the same time. This really gets pretty complex. Do you really think something like this is better than a simple suspend? (I.e. suspend blockers or having just one group) Suppose you implement suspend blockers with a cgroup freeze... how do you implement the freeze/thaw control? Cheers, Flo p.s.: do you see an possibility for any kind of "priority inheritance" in the cgroup scheme? I don't. -- 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: Florian Mickler on 7 Jun 2010 09:10 On Sun, 6 Jun 2010 19:21:49 +0200 Vitaly Wool <vitalywool(a)gmail.com> wrote: > 2010/6/6 Matthew Garrett <mjg59(a)srcf.ucam.org>: > > > Suspend blocks prevent system suspend, not any per-device suspend. > > Can you suspend a device which is holding a wake lock? > > ~Vitaly If you look at the suspend blocker patchset, you'll see that the only patches adding calls to "suspend_is_blocked()" are PM: Opportunistic suspend support and PM: Abort task freezing if there is an active suspend blocker . Both are in generic suspend code and don't affect runtime pm. Cheers, Flo -- 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: Peter Zijlstra on 7 Jun 2010 09:30 On Sun, 2010-06-06 at 12:58 -0700, Brian Swetland wrote: > Somebody will have to broker a deal with the frameworks/apps folks to > get rid of the binder. They like it a lot. Of course if somebody > built a drop-in replacement for the userspace side that didn't require > a kernel driver, had the same performance characteristics, solved the > same problems, etc, they could probably make an argument for it (or > just provide it as a drop-in replacement for people who want a more > "pure" linux underneath Android, even if we didn't pick it up). So what's up with this Binder stuff, from what I can see its just yet-another-CORBA. Why does it need a kernel part at all, can't you simply run with a user-space ORB instead? I really don't get why people keep re-inventing CORBA, there's some really nice (free) ORBs out there, like: http://www.cs.wustl.edu/~schmidt/TAO.html -- 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: Florian Mickler on 7 Jun 2010 12:00 On Sun, 6 Jun 2010 20:01:56 -0400 (EDT) Alan Stern <stern(a)rowland.harvard.edu> wrote: > And since Android can reach essentially the same low-power > state from idle as from suspend, it appears that they really don't need > any kernel changes at all. Well, perhaps a hint to the scheduler to fall through as fast as possible into deepest idle? > > Alan Stern > Cheers, Flo -- 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: David Brownell on 7 Jun 2010 14:50
--- On Mon, 6/7/10, Peter Zijlstra <peterz(a)infradead.org> wrote: > So what's up with this Binder stuff, from what I can see > its just > yet-another-CORBA. Why does it need a kernel part at all, > can't you > simply run with a user-space ORB instead? > > I really don't get why people keep re-inventing CORBA, That made me laugh. Do you realize that one of the earliest objections to CORBA was "why do people keep re-inventing RPC" ... :) (Simple answer: the existing stuff didn't solve enough of the right problems ... and it was easier (in a political sense) to come up with something new than to try fixing DCE or ONC (or whatever). Similar answers may still apply ... last I looked at CORBA, it didn't standardize desktop integration (or cell-phone equivalents), and the pure user-space versions suffered slowdowns when looking up object bindings. > there's some really nice (free) ORBs out there, -- 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/ |