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 5 Jun 2010 20:10 2010/6/5 Arjan van de Ven <arjan(a)infradead.org>: > On Sat, 5 Jun 2010 15:39:44 -0700 > Arve Hj�nnev�g <arve(a)android.com> wrote: > >> > >> > For example if the Adobe Flash player puts a timer every 10 >> > milliseconds (yes it does that), and you give it a 3.99 seconds >> > range, it will fire its timers every 4 seconds.... unless other >> > activity happens independently, at which point it'll align with >> > that instead. >> > >> >> If you do that what you are delivering is nowhere close to what the >> app asked for. > > yeah it feels a little bit suspended > >> You don't need range timers for this, you could just as >> well add 4 seconds to all normal timers. > > .. with the difference that with range timers, you naturally align with > other activity, so if there's system level activity, the AVERAGE service > the app gets is better by a LOT than just adding 4 seconds always. > > but you knew that.... just doesn't help your case. So you are saying it is safe to use range timers to radically change the requested timer interval because it does not actually get to the value that you changed it so. But you are also saying that this will allow the system to stay idle for that long. Something does not add up. -- 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 5 Jun 2010 20:40 On Sat, Jun 5, 2010 at 3:48 PM, Arjan van de Ven <arjan(a)infradead.org> wrote: > 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. > It is a 200:1 ratio in time not in 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 The absolute "on" power is not relevant to the ratio, the difference between on and off power is. This can easily be 100:1. > 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. > If you improve the low power state, compared to the "on" state wakeup gets worse, not better, but yes the phone hardware we have now does not need to stay idle for hours to get good battery life, the msm hardware at least needs to stay idle for more than a few seconds. > > 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 > -- 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: Thomas Gleixner on 5 Jun 2010 20:40 On Sat, 5 Jun 2010, Arve Hj�nnev�g wrote: > 2010/6/5 Thomas Gleixner <tglx(a)linutronix.de>: > > On Sat, 5 Jun 2010, Arve Hj�nnev�g wrote: > >> 2010/6/5 Thomas Gleixner <tglx(a)linutronix.de>: > >> > B1;2005;0cOn Fri, 4 Jun 2010, Arve Hj�nnev�g wrote: > >> Cross app calls do not go through a central process. > > > > It's not about a central process, it goes through your framework, > > which should be able to deal with it. If not, it's a design failure > > which needs to be fixed at the place where the failure happened. > > > >> >> > >> >> How can it be fixed? The user presses the back button, the framework > >> >> determines that app A is in the foreground and send the key to app A, > >> >> app A decides that it it does not have anything internal to go back to > >> >> and tells the framework to switch back to the previous app. If the > >> >> user presses the back key again, the framework does not know which app > >> >> this key should go to until app A has finished processing the first > >> >> key press. > >> > > >> > Errm, what has this to do with frozen apps? If your system is > >> > handling input events then there are no frozen apps and even if they > >> > are frozen your framework can unfreeze them _before_ talking to them. > >> > > >> > So which unfixable problem are you describing with the above example ? > >> > > >> > >> You are claiming that trusted code should not have any dependencies on > >> untrusted code. I gave you a visible example of such a dependency and > >> want you to tell me how you can avoid this dependency. Since you are > >> claiming that our user-space framework is fundamentally broken if it > >> has to wait for untrusted code, I don't think it is unreasonable for > >> you to answer this. Or do you think it is valid to communicate with > >> untrusted code when the screen is on but not when it is off. > > > > It does not matter whether the screen is off or not. If you need to > > call into that untrusted app from your trusted app and you know about > > the might be frozen state then you can deal with it. > > > > So taking your example: > > > > Event happens and gets delivered to the framework > > > > � � �framework selects A because it is in the foreground > > > > � � �if (A is frozen) > > � � � � unfreeze(A) > > > > � � �deliver_event_to(A) > > > > It's that simple. > > > > That is too simple. You also have to prevent A from being frozen while > it is processing the event or the result would be the same as if it > was frozen beforehand. The framework decides when to freeze the app in the first place (as your framework does now when it decides to suspend) So it knows whether the app is frozen or not. So it knows damend well whether it processed the event or not. Thanks, tglx
From: Arve Hjønnevåg on 5 Jun 2010 21:10 2010/6/5 Rafael J. Wysocki <rjw(a)sisk.pl>: > On Sunday 06 June 2010, Arve Hj�nnev�g wrote: >> 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? > > Basically, it involves two mechanisms, detection of wakeup events occuring > right before suspend is started This sounds like the timeout approach which I thought you did not like. > and aborting suspend if wakeup events occur > in the middle of it. > Aborting suspend is easy, but when do you allow suspend again? >> >> 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. > > It will be able to do that if it causes the frozen part of user space to be > thawed. > > I think you have this problem already, though, because you use full system > suspend and all of your apps are frozen by it. �So, to handle the situation you > describe above, you need to carry out full system resume that will thaw the > tasks for you. �I don't see any fundamental difference betwee the two cases. > Yes, we can keep all our user space suspend blockers and thaw the frozen cgroup when any suspend blocker is held, but this would eliminate any power advantage that freezing a cgroup has over using suspend to freeze all processes. Without annotating the drivers to block the cgroup freezing in the same places as we now block suspend, it also prevents processes in the cgroup that we freeze from directly consuming wakup events. >> > 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). > > Then think again of the approach I proposed and explain to me why it won't > work, because I haven't seen any convincing argument on that yet. > If you are referring to the approach that we don't use suspend but freeze a cgroup instead, this only solves the problem of bad apps. It does not help pause timers in trusted user space code and in the kernel, so it does not lower our average power consumption. And, it does not solve the problem for systems that enters lower power states from suspend than it can from idle. The last point my not be relevant to android anymore, but desktop systems already have auto suspend and it would be preferable to have a race free kernel api for this. -- 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 5 Jun 2010 21:50
2010/6/5 Thomas Gleixner <tglx(a)linutronix.de>: > On Sat, 5 Jun 2010, Arve Hj�nnev�g wrote: >> 2010/6/5 Thomas Gleixner <tglx(a)linutronix.de>: >> > On Sat, 5 Jun 2010, Arve Hj�nnev�g wrote: >> >> 2010/6/5 Thomas Gleixner <tglx(a)linutronix.de>: >> >> > B1;2005;0cOn Fri, 4 Jun 2010, Arve Hj�nnev�g wrote: >> >> Cross app calls do not go through a central process. >> > >> > It's not about a central process, it goes through your framework, >> > which should be able to deal with it. If not, it's a design failure >> > which needs to be fixed at the place where the failure happened. >> > >> >> >> >> >> >> How can it be fixed? The user presses the back button, the framework >> >> >> determines that app A is in the foreground and send the key to app A, >> >> >> app A decides that it it does not have anything internal to go back to >> >> >> and tells the framework to switch back to the previous app. If the >> >> >> user presses the back key again, the framework does not know which app >> >> >> this key should go to until app A has finished processing the first >> >> >> key press. >> >> > >> >> > Errm, what has this to do with frozen apps? If your system is >> >> > handling input events then there are no frozen apps and even if they >> >> > are frozen your framework can unfreeze them _before_ talking to them. >> >> > >> >> > So which unfixable problem are you describing with the above example ? >> >> > >> >> >> >> You are claiming that trusted code should not have any dependencies on >> >> untrusted code. I gave you a visible example of such a dependency and >> >> want you to tell me how you can avoid this dependency. Since you are >> >> claiming that our user-space framework is fundamentally broken if it >> >> has to wait for untrusted code, I don't think it is unreasonable for >> >> you to answer this. Or do you think it is valid to communicate with >> >> untrusted code when the screen is on but not when it is off. >> > >> > It does not matter whether the screen is off or not. If you need to >> > call into that untrusted app from your trusted app and you know about >> > the might be frozen state then you can deal with it. >> > >> > So taking your example: >> > >> > Event happens and gets delivered to the framework >> > >> > � � �framework selects A because it is in the foreground >> > >> > � � �if (A is frozen) >> > � � � � unfreeze(A) >> > >> > � � �deliver_event_to(A) >> > >> > It's that simple. >> > >> >> That is too simple. You also have to prevent A from being frozen while >> it is processing the event or the result would be the same as if it >> was frozen beforehand. > > The framework decides when to freeze the app in the first place (as > your framework does now when it decides to suspend) > > � � So it knows whether the app is frozen or not. > > � � So it knows damend well whether it processed the event or not. > Our user-space code is not single-threaded. So just because an app was not frozen when you checked does not mean it will remain unfrozen. We can use the same user-space wakelock api we have now to prevent freezing apps instead of preventing suspend, but we loose any advantage we get from freezing just a subset of processes this way. -- 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/ |