On Monday, August 02, 2010, Paul E. McKenney wrote: > On Mon, Aug 02, 2010 at 03:52:20PM +0200, Rafael J. Wysocki wrote: > > On Monday, August 02, 2010, Paul E. McKenney wrote: > > > On Sun, Aug 01, 2010 at 03:47:08PM -0700, Arjan van de Ven wrote: > > > > On Sun, 1 Aug 2010 12:12:28 -0700 > > > > "Paul E. McKenney" <paulmck@xxxxxxxxxxxxxxxxxx> wrote: > > ... > > > > Another one: freezing whole cgroups..... we have that today. it > > > > actually works quite well.... of course the hard part is the decision > > > > what to put in which cgroup, and at what frequency and duration you let > > > > cgroups run. > > > > > > Indeed, the Android guys seemed to be quite excited by cgroup freezing > > > until they thought about the application-classification problem. > > > Seems like it should be easy for some types of applications, but I do > > > admit that apps can have non-trivial and non-obvious dependencies. > > > > This isn't more difficult than deciding which applications will be allowed to > > use wakelocks (in the wakelocks world). It actually seems to be pretty much > > equivalent to me. :-) > > If I understand correctly, the problem they were concerned about was > instead "given that a certain set of apps are permitted to use wakelocks, > which of the other apps can safely be frozen when the display blanks > itself." I _think_ the problem should be reformulated as "which of the other apps can be safely frozen without causing the wakelocks-using ones to have problems" instead (the particular scenario is that one of the wakelocks-using apps may need one of the other apps to process something and therefore the other app cannot be frozen; however, that may be resolved by thawing all of the other apps in such situations IMO). > > > > on the suspend blockers for drivers; the linux device runtime PM is > > > > effectively doing the same things; it allows drivers to suspend/resume > > > > individually (with a very nice API/programming model I should say) based > > > > on usage. And it works on a tree level, so that it's relatively easy > > > > to do things like "I want to go to <this magic deep idle state>, but > > > > only if <this set of devices is suspended already>". This is obviously > > > > an important functionality for all low power devices, ARM or x86. > > > > Suspend blockers had this functionality as part of what it did (they do > > > > more obviously) but I'd wager that the current Linux infrastructure is > > > > outright nicer. > > > > > > This is what Rafael has been working on? > > > > If you mean the runtime PM framework, then yes, I've been working on it. > > > > > Of course, the Android guys also want to pay attention to which apps > > > are running as well as to the state of devices on the system. > > > > In fact the runtime PM framework is also important to Android, because it > > can be used in there, for example, to implement the "early suspend" thing > > I referred to in one of my previous messages in this thread. > > Now we just need to convince the Android guys of that. ;-) I believe there's no need for that, as we were talking about that a few months ago. Thanks, Rafael _______________________________________________ linux-pm mailing list linux-pm@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/linux-pm
