Attempted summary of suspend-blockers LKML thread
in [Kernel]
|
Prev: [PATCH 6/7] usb: iowarrior: fix misuse of return value of copy_to_user()
Next: Get Back To Me Immediately....
From: Paul E. McKenney on 2 Aug 2010 16:40 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(a)linux.vnet.ibm.com> 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." > > > 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. ;-) Thanx, Paul -- 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: Rafael J. Wysocki on 2 Aug 2010 17:40 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(a)linux.vnet.ibm.com> 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 -- 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: Paul E. McKenney on 2 Aug 2010 18:30 On Mon, Aug 02, 2010 at 11:33:32PM +0200, Rafael J. Wysocki wrote: > 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(a)linux.vnet.ibm.com> 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). I agree that your statement is equivalent to mine. From what I can see, the current Android code resolves this by not freezing any app while a wakelock is held. Just out of curiosity, how are you detecting the situation in order to decide when to thaw the apps in the cgroup? > > > > > 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. Here is hoping... Thanx, Paul -- 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: Rafael J. Wysocki on 2 Aug 2010 18:50 On Tuesday, August 03, 2010, Paul E. McKenney wrote: > On Mon, Aug 02, 2010 at 11:33:32PM +0200, Rafael J. Wysocki wrote: > > 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(a)linux.vnet.ibm.com> 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). > > I agree that your statement is equivalent to mine. From what I can see, > the current Android code resolves this by not freezing any app while > a wakelock is held. > > Just out of curiosity, how are you detecting the situation in order to > decide when to thaw the apps in the cgroup? Well, in fact I would only be able to talk about that theoretically, as I'm currently not involved in any project using cgroups for power management. I have considered that, but I haven't tried to implement it. Thanks, 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: david on 2 Aug 2010 20:20
On Mon, 2 Aug 2010, Paul E. McKenney wrote: > On Sun, Aug 01, 2010 at 10:06:34PM -0700, david(a)lang.hm wrote: >> On Sun, 1 Aug 2010, Arjan van de Ven wrote: >> >>> I'm a little worried that this whole "I need to block suspend" is >>> temporary. Yes today there is silicon from ARM and Intel where suspend >>> is a heavy operation, yet at the same time it's not all THAT heavy >>> anymore.... at least on the Intel side it's good enough to use pretty >>> much all the time (when the screen is off for now, but that's a memory >>> controller issue more than anything else). I'm pretty sure the ARM guys >>> will not be far behind. >> >> remember that this 'block suspend' is really 'block overriding the >> fact that there are still runable processes and suspending anyway" >> >> having it labeled as 'suspend blocker' or even 'wakelock' makes it >> sound as if it blocks any attempt to suspend, and I'm not sure >> that's what's really intended. Itsounds like the normal syspend >> process would continue to work, just this 'ignore if these other >> apps are busy' mode of operation would not work. >> >> which makes me wonder, would it be possible to tell the normal idle >> detection mechanism to ignore specific processes when deciding if it >> should suspend or not? how about only considering processes in one >> cgroup when deciding to suspend and ignoring all others? > > Why not flesh this out and compare it to the draft requirements? > (I expect to be sending another version by end of day Pacific Time.) > > The biggest issue I see right off-hand is that a straightforward > implementation of your idea would require moving processes from one > cgroup to another when acquiring or releasing a suspend blocker, which > from what I understand would be way to heavyweight. On the other hand, > if acquiring and releasing a suspend blocker does not move the process > from one cgroup to another, then you need something very like the > suspend-blocker mechanism to handle those processes that are permitted > to acquire suspend blockers, and which are thus not a member of the > cgroup in question. > > That said, I did see some hint from the Android guys that it -might- > be possible to leverage cgroups in the way that you suggest might help > save power during times when suspend was blocked but (for example) the > screen was turned off. The idea would be to freeze the cgroup whenever > the screen blanked, even if suspend was blocked. The biggest issue > here is that any process that can hold a suspend blocker must never to > an unconditional wait on any process in this cgroup. Seems to me that > this should be possible in theory, but the devil would be in the details. > > If I am misunderstanding your proposal, please enlighten me! you are close, but I think what I'm proposing is actually simpler (assuming that the scheduler can be configured to generate the appropriate stats) my thought was not to move applications between cgroups as they aquire/release the suspend-block lock, bur rather to say that any application that you would trust to get the suspend-block lock should be in cgroup A while all other applications are in cgroup B when you are deciding if the system shoudl go to sleep because it is idle, ignore the activity of all applications in cgroup B if cgroup A applications are busy, the system is not idle and should not suspend. this requires that the applications in cgroup A actually go idle as opposed to simply releaseing the suspend-block lock, but it would mean that there are no application changes required for to move a system from the status "even if it's busy, go ahead ans suspend" to "this application is important, don't suspend if it's got work to do", it would just be classifying the application in one cgroup or the other. This assumes that an application that you would trust to hold the suspend-block lock is going to be well behaved (if it isn't, how can you trust it to not grab the lock inappropriatly?) David Lang -- 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/ |