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: Arve Hjønnevåg on 4 Jun 2010 20:20 2010/6/4 Peter Zijlstra <peterz(a)infradead.org>: > On Fri, 2010-06-04 at 01:56 -0700, Arve Hj�nnev�g wrote: >> On Fri, Jun 4, 2010 at 1:34 AM, Ingo Molnar <mingo(a)elte.hu> wrote: >> > >> > * Arve Hj?nnev?g <arve(a)android.com> wrote: >> > >> >> > [...] >> >> > >> >> > Why do you need to track input wakeups? It's rather fragile and rather >> >> > unnecessary [...] >> >> >> >> Because we have keys that should always turn the screen on, but the problem >> >> is not specific to input events. If we enabled a wakeup event it usually >> >> means we need this event to always work, not just when the system is fully >> >> awake or fully suspended. >> > >> > Hm, i cannot follow that generic claim. Could you please point out the problem >> > to me via a specific example? Which task does what, what undesirable thing >> > happens where, etc. >> > >> >> We have many wakeup events, and some of them are invisible to the >> user. For instance on the Nexus One wake up every 10 minutes monitor >> the battery health. > >> If the user presses a key right after this work >> has finished and we did not block suspend until userspace could >> process this key event, we risk suspending before we could turn the >> screen on, which to the user looks like the key did not work. > >> Another >> example, the user pressed the power key which turns the screen off and >> allows suspend. We initiate suspend and a phone call comes in. If we >> don't block suspend until we processed the incoming phone call >> notification, the phone may never ring (some devices will send a new >> message every few seconds for this, so on those devices it would just >> delay the ringing). > > Right, so in the proposed scheme all these tasks would be executed by > trusted processes, and trusted processes will never get frozen and so > will never be delayed in processing these events. > There are many proposes schemes. I assume you mean freezing only untrusted processes and nothing else. > Only untrusted code will be frozen. And trusted processes are reliable > for thawing the untrusted processes and delivering events to it. > I have two problems with this. I don't want to funnel all events trough trusted processes, and I also want to freeze trusted processes. > Trusted processes are assumed to be sane and idle when there is nothing > for them to do, allowing the machine to go into deep idle states. > Neither the kernel nor our trusted user-space code currently meets this criteria. -- Arve Hj�nnev�g -- 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: Arve Hjønnevåg on 4 Jun 2010 20:40 On Fri, Jun 4, 2010 at 5:05 PM, Thomas Gleixner <tglx(a)linutronix.de> wrote: > On Sat, 5 Jun 2010, Rafael J. Wysocki wrote: >> I kind of agree here, so I'd like to focus a bit on that. >> >> Here's my idea in the very general terms: >> >> (1) Use the cgroup freezer to "suspend" the "untrusted" apps (ie. the ones >> � � that don't use suspend blockers aka wakelocks in the Android world) at the >> � � point Android would normally start opportunistic suspend. > > There is an additional benefit to this approach: > > � � In the current android world a background task (e.g. download > � � initiated before the screensaver kicked in) prevents the suspend, > � � but that also means that the crapplications can still suck power > � � completely unconfined. > Yes this can happen. It is usually only a big problem when you combine an (trusted) application that has a bug that blocks suspend forever with an application that wakes up too often for us to enter low power idle modes. > � � With the cgroup freezer you can "suspend" them right away and > � � just keep the trusted background task(s) alive which allows us to > � � go into deeper idle states instead of letting the crapplications > � � run unconfined until the download finished and the suspend > � � blocker goes away. > Yes this would be better, but I want it in addition to suspend, not instead of it. It is also unclear if our user-space code could easily make use of it since our trusted code calls into untrusted code. >> (2) Allow the cpuidle framework to put CPUs into low-power states after the >> � � "trusted" apps (ie. the ones that use suspend blockers in the Android >> � � world) have gone idle. >> As far as I know this is what we already have on hardware that supports it. >> (3) Teach the cpuidle framework to schedule runtime suspend of I/O devices >> � � before idling the last CPU (*). >> I don't think we need this for android phones. We already put I/O devices in low power modes when they are not in use. >> (4) Design a mechanism to resume the I/O devices suspended in (3) so that >> � � they are not powered up unnecessarily (that's going to be difficult as far >> � � as I can see). >> >> This way, in principle, we should be able to save (at least almost) as much >> energy as the opportunistic suspend currently used by Android, provided that >> things will be capable of staying idle for extended periods of time. The main reason we use suspend is that the system does not stay idle for extened periods of time. If this gets fixed, and our if user-space framework can deal with a subset of processes being frozen (this is a big if) this solution may work, but it does not help us today. >> >> (*) That may require per-device PM QoS requirements to be used, in which case >> � � devices may even be suspended earlier if the PM QoS requirements of all >> � � of their users are met. >> >> I wonder what people think. �Is this realistic and if so, would it be difficult >> to implement? > > I think it's realistic and not overly complicated to implement. > The kernel support can be easily implemented on most arm hardware, I don't know if it can work on most existing x86 hardware. It does not give us the same power savings as suspend with existing software, but it can handle bad apps better (assuming you don't combine opportunistic suspend and cgroup freezing). The biggest hurdle is how to handle dependencies between processes that gets frozen and processes that don't get frozen. -- Arve Hj�nnev�g -- 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 4 Jun 2010 21:20 On Fri, Jun 04, 2010 at 05:39:17PM -0700, Arve Hj�nnev�g wrote: > On Fri, Jun 4, 2010 at 5:05 PM, Thomas Gleixner <tglx(a)linutronix.de> wrote: > > On Sat, 5 Jun 2010, Rafael J. Wysocki wrote: <snip> > > > � � With the cgroup freezer you can "suspend" them right away and > > � � just keep the trusted background task(s) alive which allows us to > > � � go into deeper idle states instead of letting the crapplications > > � � run unconfined until the download finished and the suspend > > � � blocker goes away. > > > > Yes this would be better, but I want it in addition to suspend, not > instead of it. It is also unclear if our user-space code could easily > make use of it since our trusted code calls into untrusted code. > Perhaps I'm misunderstanding, but suspend and the cgroup freezer interoperate well today -- you don't have to choose one or the other. If you've discovered otherwise I'd consider it a bug and would like to hear more about it. <snip> > it can handle bad apps better (assuming you don't combine > opportunistic suspend and cgroup freezing). I don't see why that would be a problem. The cgroup freezer works independently of the suspend freezer -- even with suspend blockers. So my hunch is this is really the same as the next problem you refer to: > The biggest hurdle is how > to handle dependencies between processes that gets frozen and > processes that don't get frozen. I'm not sure it covers everything you want, but it should be possible to identify some of those so long as you know which process you're communicating with. A trusted app can look up the freezer cgroup of a target app in /proc, then look at the cgroup's freezer.state file. If it's FREEZING or FROZEN then you've very likely got a "bad" dependency. For example, say a trusted app plans on doing a blocking read() to fetch the output of an untrusted app via a pipe. Assuming we know the untrusted app's pid we could then check the dependency and determine that we're likely to block because the untrusted app's freezer cgroup is FREEZING or FROZEN. (certain to block if we see FROZEN) That said, it involves quite a few system calls compared to a simple read() from the pipe. So my guess is it would be a debugging tool at best -- not something you always have enabled. It may even be possible to make an lsof-like debugging tool to do that from outside both apps. 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: Arve Hjønnevåg on 5 Jun 2010 01:40 2010/6/4 Matt Helsley <matthltc(a)us.ibm.com>: > On Fri, Jun 04, 2010 at 05:39:17PM -0700, Arve Hj�nnev�g wrote: >> On Fri, Jun 4, 2010 at 5:05 PM, Thomas Gleixner <tglx(a)linutronix.de> wrote: >> > On Sat, 5 Jun 2010, Rafael J. Wysocki wrote: > > <snip> > >> >> > � � With the cgroup freezer you can "suspend" them right away and >> > � � just keep the trusted background task(s) alive which allows us to >> > � � go into deeper idle states instead of letting the crapplications >> > � � run unconfined until the download finished and the suspend >> > � � blocker goes away. >> > >> >> Yes this would be better, but I want it in addition to suspend, not >> instead of it. It is also unclear if our user-space code could easily >> make use of it since our trusted code calls into untrusted code. >> > > Perhaps I'm misunderstanding, but suspend and the cgroup freezer > interoperate well today -- you don't have to choose one or the other. > If you've discovered otherwise I'd consider it a bug and would like to > hear more about it. > I'm not aware of any bug with combining both, but we cannot use suspend at all without suspend blockers in the kernel (since wakeup events may be ignored) and I don't know how we can safely freeze cgroups without funneling all potential wakeup events through a process that never gets frozen. > <snip> > >> it can handle bad apps better (assuming you don't combine >> opportunistic suspend and cgroup freezing). > > I don't see why that would be a problem. The cgroup freezer works > independently of the suspend freezer -- even with suspend blockers. > So my hunch is this is really the same as the next problem you refer to: > >> The biggest hurdle is how >> to handle dependencies between processes that gets frozen and >> processes that don't get frozen. > > I'm not sure it covers everything you want, but it should be possible to > identify some of those so long as you know which process you're > communicating with. > > A trusted app can look up the freezer cgroup of a target app in /proc, then > look at the cgroup's freezer.state file. If it's FREEZING or FROZEN then > you've very likely got a "bad" dependency. > I don't think they are "bad" dependencies. Our framework has to communicate with apps. > For example, say a trusted app plans on doing a blocking read() to fetch > the output of an untrusted app via a pipe. Assuming we know the untrusted > app's pid we could then check the dependency and determine that we're likely > to block because the untrusted app's freezer cgroup is FREEZING or FROZEN. > (certain to block if we see FROZEN) > > That said, it involves quite a few system calls compared to a simple read() > from the pipe. So my guess is it would be a debugging tool at best -- not > something you always have enabled. > > It may even be possible to make an lsof-like debugging tool to do that from > outside both apps. > > Cheers, > � � � �-Matt Helsley > -- Arve Hj�nnev�g -- 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 5 Jun 2010 06:00
On Fri, 2010-06-04 at 17:10 -0700, Arve Hjønnevåg wrote: > > Trusted processes are assumed to be sane and idle when there is nothing > > for them to do, allowing the machine to go into deep idle states. > > > > Neither the kernel nor our trusted user-space code currently meets > this criteria. Then both need fixing. Really, that's the only sane approach. -- 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/ |