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: Alan Stern on 6 Jun 2010 20:10 On Sun, 6 Jun 2010, Matthew Garrett wrote: > The difference between idle-based suspend and opportunistic suspend is > that the former will continue to wake up for timers and will never be > entered if something is using CPU, whereas the latter will be entered > whenever no suspend blocks are held. The problem with opportunistic > suspend is that you might make the decision to suspend simultaneusly > with a wakeup event being received. Suspend blocks facilitate > synchronisation between the kernel and userspace to ensure that all such > events have been consumed and handld appropriately. Remember that suspend takes place in several phases, the first of which is to freeze tasks. The phases can be controlled individually by the process carrying out a suspend, and there's nothing to prevent you from stopping after the freezer phase. Devices won't get powered down, but Android uses aggressive runtime power management for its devices anyway. If you do this then the synchronization can be carried out entirely from userspace, with no need for kernel modifications such as suspend blockers. 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. Alan Stern -- 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: Christoph Hellwig on 7 Jun 2010 04:10 On Mon, Jun 07, 2010 at 12:26:55AM +0200, Thomas Gleixner wrote: > That takes a lot of the bullshit arguments about downstream users > being hurt out of the discussion. The above problems are way more > complex to resolve than the suspend blocker details. > > That's another prove why we can let the drivers flow in (in the worst > case w/o the suspend blocker stubs) and have no pressure to resolve > the suspend blocker problem yesterday. > > That said, after thinking more about it, I'm advocating the stubs > solution with a clear removal / decision date constraint > (e.g. 2.6.37), as it forces all involved parties to stay tuned and not > to forget about it. I'm curious about the outcome :) As long as we have that clear removal schedule I'm fine with in-kernel suspend blocker stubs. -- 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: Christoph Hellwig on 7 Jun 2010 04:10 On Sun, Jun 06, 2010 at 12:58:10PM -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). This wasn't really directed at you, but rather about people talking about running a mainline kernel on Android in this thread. As I said this is a lot more work then sorting out the drivers - with or without suspend blockers. > The group ID stuff works incredibly well for gating device access -- > we ensure that devices that need access from various processes end up > with perms like 0660 root audio (say for a raw audio interface), and > then we assure that processes which have the "may use audio hardware" > permission are executed with audio as an additional group. We ended > up using the same model to control socket, raw socket, and bt socket > access because at the time we could not find a reasonable way to grant > or exclude such permissions on a process by process basis. > Maintaining about 20-30 lines of diffs to make that work was not a bad > tradeoff (and we don't expect those patches to go upstream). If > there's a way to accomplish this without patching the kernel, we're > all ears. I'd have to take a look again on how this is implemented in details. If it's just overriding the capabilities it's really hard to do in the current model as the capabilities aren't fine grained enough currently, even with the existing per-file and per-process capabilities. If it's mostly overriding regular unix file permissions it's easily doable with ACLs, or in fact just with group ownership at the filesystem level, without kernel hacks. -- 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: Brian Swetland on 7 Jun 2010 04:20 On Mon, Jun 7, 2010 at 1:03 AM, Christoph Hellwig <hch(a)infradead.org> wrote: > On Sun, Jun 06, 2010 at 12:58:10PM -0700, Brian Swetland wrote: >> The group ID stuff works incredibly well for gating device access -- >> we ensure that devices that need access from various processes end up >> with perms like 0660 root audio (say for a raw audio interface), and >> then we assure that processes which have the "may use audio hardware" >> permission are executed with audio as an additional group. We ended >> up using the same model to control socket, raw socket, and bt socket >> access because at the time we could not find a reasonable way to grant >> or exclude such permissions on a process by process basis. >> Maintaining about 20-30 lines of diffs to make that work was not a bad >> tradeoff (and we don't expect those patches to go upstream). If >> there's a way to accomplish this without patching the kernel, we're >> all ears. > > I'd have to take a look again on how this is implemented in details. > If it's just overriding the capabilities it's really hard to do in > the current model as the capabilities aren't fine grained enough > currently, even with the existing per-file and per-process capabilities. > If it's mostly overriding regular unix file permissions it's easily > doable with ACLs, or in fact just with group ownership at the filesystem > level, without kernel hacks. For device nodes, we just use group ownership and it works fine with no kernel modifications. For the "can create socket", "can create bt socket", and "can create raw socket" permissions we ended up throwing together a patch tying those operations to being in the appropriate group. Obviously a hack, but it was the most straightforward solution we could find at the time. Brian -- 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: Felipe Contreras on 7 Jun 2010 06:30
2010/6/6 Matthew Garrett <mjg59(a)srcf.ucam.org>: > On Sun, Jun 06, 2010 at 07:21:49PM +0200, Vitaly Wool 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? > > Yes. Suspend blocks are orthogonal to runtime PM. In that sense yes, but as it has been stated before; if Android user-space concentrates on getting suspend blockers right, then the timers in user-space will not be aligned correctly, and runtime PM wouldn't work that great. Moreover, opportunistic suspend takes the device out of idle. So, as runtime PM gets better, there's a point where opportunistic suspend makes the situation worst. So they are _mostly_ orthogonal, but not completely, at least for the analysis of suspend blockers' usefulness. -- Felipe Contreras -- 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/ |