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: James Bottomley on 6 Jun 2010 10:40 On Sun, 2010-06-06 at 12:05 +0100, Alan Cox wrote: > On Sun, 6 Jun 2010 12:46:01 +0200 > Florian Mickler <florian(a)mickler.org> wrote: > > > On Sun, 6 Jun 2010 12:00:47 +0200 > > Vitaly Wool <vitalywool(a)gmail.com> wrote: > > > > > Even worse, the suspend wakelock will keep the > > > whole kernel active, as opposed to powering off unused devices > > > separately as it's done in runtime PM. > > > > That is not true. While the kernel is not suspended it does > > runtime pm. > > On several of our platforms runtime PM already includes suspend so a > suspend wakelock does interfere with existing power managemet at that > level (not to mention the maintenance mess it causes). > > This is one of the reasons you want QoS information, it provides > parameters by which the power management code can make a decision. > Suspend blocksers simply don't have sufficient variety to manage the > direction of power policy. > > If Android chooses to abuse the QoS information for crude suspend > blocking then that is fine, it doesn't interfere with doing the job > 'properly' on other systems or its use for realtime work on other boxes. Right ... and I think we can make use of this as an incremental way forwards. This QoS re-expression needs doing for the suspend from idle + cgroup approach, and it can be made to work with the current suspend blockers patch. I've already posted most of the necessary improvements to pm_qos, all of which end up looking like the right thing to do independent of android. There's really only one remaining thing, and that's adding statistics. Once stats are added, I think I can transform the 8 android patches into a set of 7 pm_qos transformations and one patch that adds the opportunistic suspend infrastructure. The 7 pm_qos patches should be reasonably uncontroversial, but what they would allow us to do is to unblock about 75% of the driver divergences from Qualcomm and others. The 1 opportunistic suspend one will be confined to one or two files, so is easy to maintain ... we can then argue over who should maintain it in the interim, us or Google. >From this basis, we can then proceed to look at implementing the cgroups + suspend from idle approach, and we can do this regardless of whether the opportunistic suspend patch is applied or not. There are three reasons why the whole debate is going in circles 1. Lots of people are taking a holistic approach (i.e. must solve everything) ... this means that previously unarticulated issues keep cropping up that are unrelated to the current patch set ... but which set off another cascade of emails. 2. There currently is no cgroups + suspend from idle approach implemented anywhere. That means we have to argue theoreticals rather than actuals (theoreticals are easy to shoot down with other theoretical arguments ... leading to another email cascade). If we implemented the thing, these arguments would compare one factual basis to another. 3. We've lost sight of one of the original goals, which was to bring the android tree close enough to the kernel so that the android downstream driver and board producers don't have to choose between the android kernel and vanilla kernel. I think the proposal above gets us to within 75% of the way to 3, moves us towards a factual basis for 2 and eliminates some of the grounds for argument of 1 ... now can we please get on with it? James -- 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: Matt Helsley on 6 Jun 2010 10:50 On Sun, Jun 06, 2010 at 12:36:21PM +0200, Thomas Gleixner wrote: > On Sat, 5 Jun 2010, Arve Hj�nnev�g wrote: <snip> > > events like input event go though a single thread in our system > > process, while other events like network packets (which are also > > wakeup events) goes directly to the app. If you want to wake up cgroup-frozen tasks for these fds perhaps your framework can fcnt(fd, F_SETOWN, <p[g]id>) to send SIGIO to a userspace-suspend-blocker thread/process/process group. When IO comes in, the suspend blocker is signalled which then unfreezes the cgroup of the frozen untrusted task. SIGIO works on pipes, fifos, sockets, ttys, and ptys -- many of which are precisely the kinds of things that would connect [trusted and untrusted] apps. Notably absent (last I checked): inotify fds, signalfd, timerfd, eventfd, filesystem fds and likely more. Incidentally, this is just to show that it's not impossible to implement "wakeups" for cgroup-frozen tasks in userspace. Cheers, -Matt Helsley -- 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: Vitaly Wool on 6 Jun 2010 11:30 2010/6/6 Matthew Garrett <mjg59(a)srcf.ucam.org>: > On Sun, Jun 06, 2010 at 12:00:47PM +0200, Vitaly Wool wrote: > >> Sure, but my point was, some non-trivial (still kind of natural for a >> smartphone) activities with the device will prevent it from suspending >> for quite some time. Even worse, the suspend wakelock will keep the >> whole kernel active, as opposed to powering off unused devices >> separately as it's done in runtime PM. Yep, I know about the "early >> suspend" type of thing; yet it's excess, not mainlined and lacks >> granularity. > > Holding a suspend blocker is entirely orthogonal to runtime pm. The > "whole kernel" will not be "active" - it can continue to hit the same > low power state in the idle loop, and any runtime pm implementation in > the drivers will continue to be active. Yeah, that might also be the case, But then again, what's the use of suspend blockers in this situation? ~Vitaly -- 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 6 Jun 2010 11:40 On Sun, Jun 06, 2010 at 05:26:09PM +0200, Vitaly Wool wrote: > 2010/6/6 Matthew Garrett <mjg59(a)srcf.ucam.org>: > > Holding a suspend blocker is entirely orthogonal to runtime pm. The > > "whole kernel" will not be "active" - it can continue to hit the same > > low power state in the idle loop, and any runtime pm implementation in > > the drivers will continue to be active. > > Yeah, that might also be the case, But then again, what's the use of > suspend blockers in this situation? 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. -- 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: Thomas Gleixner on 6 Jun 2010 11:50
On Sun, 6 Jun 2010, James Bottomley wrote: > > 3. We've lost sight of one of the original goals, which was to > bring the android tree close enough to the kernel so that the > android downstream driver and board producers don't have to > choose between the android kernel and vanilla kernel. There are two ways to do that w/o creating a dependcy on anything. 1) merge the drivers w/o the suspend_blockers. It's not rocket science to have a patch which brings them back for android. 2) merge the drivers with empty stub implementations for annotation. android just has to patch in the real one. While I'd prefer #1, I' not in the way of #2. Both ways can get the drivers into the kernel and it could/should have been done right from the beginning, but now we face a situation where drivers are held hostage. Then we can sit down more relaxed and fix the stuff in a way which makes both sides happy. If we manage to replace them, we can deprecate the stub implementation and remove it after a grace period. If we rename them it's not an issue either. We can rename them right away to a qos interface, but that does not really make a difference. What we really want to avoid is implementing an user space contract in a frenzy which binds us forever. It's not the suspend_blockers which are the causing the nightmare, it's solely the drivers itself especially when there are different implementations in both trees. And frankly, the drivers in android are not in a shape which makes them flood in within 2 weeks. That's serious work to get them brushed up and polished. So that gives us quite a period of time to solve the suspend problem. Thanks, tglx -- 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/ |
