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: Rafael J. Wysocki on 5 Jun 2010 14:30 On Saturday 05 June 2010, Arve Hj�nnev�g wrote: > 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) The more I think of it, the more it appears to me that the problem of lost wakeup events can actually be solved without suspend blockers. I'll send a bunch of patches to address this issue, probably tomorrow. > and I don't know how we can safely freeze > cgroups without funneling all potential wakeup events through a > process that never gets frozen. If your untrusted apps get called by the trusted ones, they aren't really untrusted in the first place. From what you're saying it follows that you're not really willing to accept any solution different to your suspend blockers. Is that really the case? Rafael -- 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 5 Jun 2010 16:40 On Thu, 3 Jun 2010 19:16:55 -0700 (PDT) Linus Torvalds <torvalds(a)linux-foundation.org> wrote: > The thing is, unless there is some _really_ deep other reason to do > something like this, I still think it's total overdesign to push any > knowledge/choices like this into the scheduler. I'd rather keep things way > more independent, less tied to each other and to deep kernel subsystems. > > IOW, my personal opinion is that somethng like a suspend (blocker or not) > decision simply shouldn't be important enough to be tied into the > scheduler. Especially not if it could just be its own layer. > > That said, as far as I know, the Android people have mostly been looking > at the suspend angle from a single-core standpoint. And I'm not at all > convinced that they should hijack the existing "/sys/power/state" thing > which is what I think they do now. > > And those two things go together. The /sys/power/state thing is a global > suspend - which I don't think is appropriate for a opportunistic thing in > the first place, especially for multi-core. > This sounds right. If there is soo much need for a better solution, it will emerge. With merged suspend blockers or not. Just my 2 cents. > Linus 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: Arve Hjønnevåg on 5 Jun 2010 18:20 2010/6/5 Rafael J. Wysocki <rjw(a)sisk.pl>: > On Saturday 05 June 2010, Arve Hj�nnev�g wrote: >> 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) > > The more I think of it, the more it appears to me that the problem of > lost wakeup events can actually be solved without suspend blockers. > I'll send a bunch of patches to address this issue, probably tomorrow. > I know of two ways to prevent lost wakeup events. Reset a timeout every time you receive a wakeup event or prevents suspend until you know the event has been fully processed. Does your solution fall onto one of these two categories, or do you have a third way? >> and I don't know how we can safely freeze >> cgroups without funneling all potential wakeup events through a >> process that never gets frozen. > > If your untrusted apps get called by the trusted ones, they aren't really > untrusted in the first place. > That is not a correct statement. A trusted apps can call into an untrusted app, it just has to validate the response and handle not getting a response at all. There are also different levels of trust. I may have trusted an app to provide a contact pictures, but not trusted it to block suspend. When the phone rings the app will be called to provide the picture for the incoming call dialog, but if it is frozen at this point the more trusted app that handles the incoming phone call will not be able to get the picture. > From what you're saying it follows that you're not really willing to accept > any solution different to your suspend blockers. �Is that really the case? > I don't think that is a fair way to put it. We need to support our user-space framework and I have not seen an alternative solution that clearly will work (other than replacing suspend_blockers with pm_qos constraints that do the same thing). -- 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: Brian Swetland on 5 Jun 2010 18:30 On Sat, Jun 5, 2010 at 3:23 PM, Arjan van de Ven <arjan(a)infradead.org> wrote: >> >> We clearly have different standards for what we consider good. We >> measure time suspended in minutes or hours, not seconds, and waking up >> every second or two causes a noticeable decrease in battery life on >> the hardware we have today. > > I guess I'm spoiled working with (unreleased) hardware that knows how > to power gate ;-) I'm continually surprised by answers like this. We run on hardware that power gates very aggressively and draws in the neighborhood of 1-2mA at the battery when in the lowest state (3-5mA while the radio is connected to the network and paging). Waking up out of that lowest state and executing code every few seconds or (worse) several times a second) will raise your average power consumption. Being able to stay parked at the very bottom for minutes or hours at a time when nothing "interesting" is happening is very useful and can have a significant impact on overall battery life. 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: Arjan van de Ven on 5 Jun 2010 18:50
On Sat, 5 Jun 2010 15:26:36 -0700 Brian Swetland <swetland(a)google.com> wrote: > > I'm continually surprised by answers like this. We run on hardware > that power gates very aggressively and draws in the neighborhood of > 1-2mA at the battery when in the lowest state (3-5mA while the radio > is connected to the network and paging). Waking up out of that lowest > state and executing code every few seconds or (worse) several times a > second) will raise your average power consumption. Being able to stay > parked at the very bottom for minutes or hours at a time when nothing > "interesting" is happening is very useful and can have a significant > impact on overall battery life. It's relatively simple math. If you wake up for a burst of work, you burn power at the higher level P1 (versus the lower power level P2), for, lets say an average time T, with a relatively small T (few milliseconds at most). If you wake up X times per second (with X being a fractional number, so can be smaller than 1) the extra power consumption factor is X * T * P1 ------------------------------- X * T * P1 + (1.0 - X * T) * P2 if you draw a graph of this, for real values of P and T, there's a real point where you hit diminishing returns. if say T is 5 milliseconds (that's a high amount), and X is 1 wakeup/second, then there's already a 200:1 ratio in time an power. If X goes to once every 10 seconds (not unreasonable, especially since any real device will pull email and stuff in the backgroudn), you have 2000:1 time and power ratios... Unless your "on" power is insane high (and hopefully it's not, since you're not turning on the whole device obviously, you do selective power and clock gating)... that "divide by 200 or 2000" makes the whole problem go away.. in the "seconds" range for really low power devices. Not in "hours" range. On laptops (which have much more poor powermanagement) this point is around 40 milliseconds or so.. but on phone silicon that I've seen, both Intel and others, this is in the 1 to 5 seconds range. -- Arjan van de Ven Intel Open Source Technology Centre For development, discussion and tips for power savings, visit http://www.lesswatts.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/ |