[PATCH 0/8] Suspend block api (version 8)
in [Kernel]
|
Prev: [ANN] Linux Security Summit 2010 - Announcement and CFP
Next: [PATCH 4/8] PM: suspend_block: Add debugfs file
From: Alan Stern on 28 May 2010 10:10 On Fri, 28 May 2010, Alan Cox wrote: > > Since I think we've now rejected the feature, do we have a clear picture about > > what the Android people should do _instead_ and yet keep the battery life they > > want? Because I don't think telling "let them do what they want, who cares" > > is right. > > Today "idle" means "no task running" > > If you are prepared to rephrase that as "no task that matters is running" > what would need to answer ? > > - How do we define who matters: QoS ? Here are the deficiencies in the current PM-QOS implementation which would need to be solved for Android's purposes: The system includes parameters for latency and throughput. It does not include a parameter to describe whether timers are enabled. The presumption is that timers are always enabled. For example, the low-power state used by Android would be described as one in which the CPU does not run and timers are disabled, with some appropriate latencies and zero throughput. On some platforms even some interrupt sources are disabled (those not marked as wakeup-enabled). There's no way to indicate minimum system operating requirements. For example, we may know that work needs to be done without knowing specifically which processes are going to carry out that work. In such cases we would like to require that the CPU continues to run at a certain minimum speed so long as _any_ threads are runnable, even if those threads don't have any QOS requirements of their own. Similarly, the requirement that timers be enabled is a system-wide sort of thing, not necessarily applying to a particular thread (and in fact, not all timers are associated with a thread anyway). There's no way to boost the minimum system operating requirements upon the arrival of an event. For example, when an input event enters the queue, it should be possible to prevent the system from entering its lowest power state until the event can be consumed by userspace. Simply boosting the QOS requirements of the threads waiting on the input queue isn't good enough, because there may not be any such threads when the event occurs (they may be busy doing something else). The matter of _which_ events should boost the system operating requirements is debatable. In the Android proposal it is a fixed set: those events which enable a suspend blocker. In theory it could instead be determined by requests from userspace, although I don't know how such requests would be expressed. Until these weaknesses are rectified, Android cannot use the PM-QOS system or idle-time power management to satisfy its needs. That's why they have to resort to forced suspends. Can the PM-QOS framework be enhanced to include these considerations? I don't see why not (but on the other hand, I know nothing about its internal workings). 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: Igor Stoppa on 28 May 2010 10:20 ext tytso(a)mit.edu wrote: > Linus will disagree with you there. Linus *has* merged code on the > basis that it is shipping in distributions, regardless of the fact > that some developers objected to it. Sometimes "perfect" should not > be the enemy of "good enough" shipping code. > "good enough" is very subjective, in this case > If everyone agrees we're making progress, and we can let this 100+ > mail thread keep going. I have seen very good proposals for saner solutions. Is that progress? igor -- 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: Alan Cox on 28 May 2010 10:20 > > That's very good. But if it is done in a conceptually flawed way, some > > better solution should be considered for upstream merge. > > How is it flawed? Serious question. - It means changing drivers and quite a few apps - It doesn't solve the problem of rogue apps if they end up owning locks - It puts the deep knowledge of the platform in the applications - It gives the apps control of the action taken not policy indication - It doesn't resolve the problem of synchronization of take/releases stopping any suspend - The kernel parts are not generically useful, merely effective for solving a specific problem right now - even things like VM migration to/from phones seems to break it - It inverts the whole logic the kernel is following and trend it is following that suspend is simply a very deep idle (with implementations merged) If it was a localised turd I wouldn't worry. There are plenty df deep unmentionables hidden away enirely in platform specific code that deal with everything from stoned hardware engineers to crazed software stack implementations. Here is a question back the other way perhaps - If the existing kerne was almostl entirely read only, or you had to pay a large fee per line of code changed outside your own driver how would you implement the wakelock/suspend blocker API ? Because if you take the path that 'we want wakelockers' that is essentially the question you have to answer. How do you merge it so that nobody outside of your driver and maybe a spot of arch code knows about it. You are permitted a couple of sneaky substitions of core function bits in headers. Right now bits are going to leak out over the kernel which is the cause of friction. At the point it's invisible to everyone else they cease to be stakeholders so you don't have keep them happy. You've only got a couple in your patches but its painfully obvious from Matthew and your comments you'll end up needing a ton more and these will get everywhere as Android grows hardware platforms and CPU support as phones become more featureful and PC like. The moment a phone grows a USB base station with hub for example the entire USB stack becomes burdened with them. Matthew has already indicated networking needs them. Good luck with Dave Miller on that. I'm asking questions to look for generalised approaches, or even better doing it without new kernel stuff in the first place, but it's not the only way. Alan -- 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 28 May 2010 10:30 On Fri, May 28, 2010 at 05:14:31PM +0300, Igor Stoppa wrote: > I have seen very good proposals for saner solutions. > > Is that progress? The proposals so far involve either redefining the problem space or being inherently racey. It may be that we can redefine the problem space in such a way that everyone's happy, but it's not possible to do so by fiat. -- 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: Brian Swetland on 28 May 2010 10:30
On Fri, May 28, 2010 at 7:21 AM, Matthew Garrett <mjg59(a)srcf.ucam.org> wrote: > On Fri, May 28, 2010 at 05:14:31PM +0300, Igor Stoppa wrote: > >> I have seen very good proposals for saner solutions. >> >> Is that progress? > > The proposals so far involve either redefining the problem space or > being inherently racey. It may be that we can redefine the problem space > in such a way that everyone's happy, but it's not possible to do so by > fiat. I think the suggestion that has the closet fit with what we're trying to accomplish is Ingo's (or perhaps Ingo's explanation of Alan's): http://lkml.org/lkml/2010/5/28/106 where it's implemented as a constraint of some sort. Arve points out that qos constraint objects could work (but not if specifically tied to apps): http://lkml.org/lkml/2010/5/28/120 though he suggests that "latency" constraints don't represent this as well as "state" constraints. Though if you look at it that way, then suspend_blockers become qos constraint objects, but their implementation and usage remain pretty much the same as we have now, which does not address Alan's concern regarding code turning up in drivers, etc. I'm not sure how you can solve this problem (avoiding races around entering/exiting the suspend or suspend-like state) without having a means for drivers to prevent entry to that state. I need to think more about the cgroups approach, but I'm pretty sure it still suffers from wakeup race situations, and due to the complexity of userspace (at least ours), I suspect it would risk livelock/deadlock/priority-inversion style issues due to interaction between different processes in different groups. 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/ |