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: Florian Mickler on 2 Aug 2010 03:30 On Mon, 2 Aug 2010 00:02:04 -0700 (PDT) david(a)lang.hm wrote: > On Mon, 2 Aug 2010, Florian Mickler wrote: > > > On Mon, 2 Aug 2010 08:40:03 +0200 > > Florian Mickler <florian(a)mickler.org> wrote: > > > >> On Sun, 1 Aug 2010 23:06:08 -0700 (PDT) > >> david(a)lang.hm wrote: > >> > >>> On Mon, 2 Aug 2010, Florian Mickler wrote: > >>> > >>>> On Sun, 1 Aug 2010 22:06:34 -0700 (PDT) > >>>> 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? > >>>>> > >>>>> David Lang > >>>> > >>>> We then get again to the "runnable tasks" problem that was > >>>> discussed earlier... the system get's "deadlock-prone" if a subset of > >>>> tasks is not run. > >>>> Interprocess dependencies are not so easy to get right in general. > >>> > >>> I'm not suggesting that you don't run the 'untrusted' tasks, just that you > >>> don't consider them when deciding if the system can suspend or not. if the > >>> system is awake, everything runs, if the system is idle (except for the > >>> activity of the 'untrusted' tasks) you suspend normally. > >>> > >>> David Lang > >> > >> Ah, yes. Sorry. It's pretty early in the morning over here, I don't > >> seem to have my eyes fully opened yet... A "ignore-these-processes" > >> cgroup could probably work... It would have the advantage of not having > >> to maintain a special purpose API.... > >> > >> > >> Cheers, > >> Flo > >> > > > > Thinking about it.. I don't know much about cgroups, but I think a > > process can only be in one cgroup at a time. So you'd need to provide > > > > a) a way to race free migrate them to the "suspend block" cgroup (or > > dropping them out of the "ignore" cgroup) > > why does it need to be race free? being in transition is going to be > logically the same as being in the other group. > > it's not like applications will be moving back and forth between the two > groups is it? I expect that this would be a one-time thing at startup. hmm... i envisioned a mechanism where applications would be able to switch the groups freely depending on what context the device is in. I didn't even thought about a static grouping. But maybe that is possible also and maybe even sufficient... Anyway... right. This is probably not a show-stopper. > > b) you can't use cgroup for other purposes anymore. I.e. if you want to > > have 2 groups that each only have half of the memory available, how > > would you then integrate the cgroup-ignore-for-idle-approach with this? > > two answers to this > > 1. does this matter? do you really need to combine this 'suspend, even if > there are processes trying to run' with other cgroup limitations? > > 2. who says that this must be limited to one cgroup? a cgroup can have > several different flags/limits set on it, so why can't one of them be this > 'ignore for suspend' flag? > > these seem like simple issues, what I don't know is if it's possible for > the process that controlls suspend to follow such a flag without major > surgury on it's innards (if it can, this seems like a easy win, but I can > imagine internal designs where the software just knows that _something_ is > trying to run and would have a very hard time figuring out what) > > David Lang Well, i fear it becomes some sort of parallel-tree structure... If you want a cgroups-partitioning for one kind of attribute you now need 2 containers for every possible stamping of that attribute... one being flagged with 'ignore-for-suspend-decision' and one without that flag. Do you see what I'm getting at, or do I need more coffee and it is irelevant to this concept? 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: david on 2 Aug 2010 05:10 On Mon, 2 Aug 2010, Florian Mickler wrote: > On Mon, 2 Aug 2010 00:02:04 -0700 (PDT) > david(a)lang.hm wrote: > >> On Mon, 2 Aug 2010, Florian Mickler wrote: >> >>> On Mon, 2 Aug 2010 08:40:03 +0200 >>> Florian Mickler <florian(a)mickler.org> wrote: >>> >>>> On Sun, 1 Aug 2010 23:06:08 -0700 (PDT) >>>> david(a)lang.hm wrote: >>>> >>>>> On Mon, 2 Aug 2010, Florian Mickler wrote: >>>>> >>>>>> On Sun, 1 Aug 2010 22:06:34 -0700 (PDT) >>>>>> 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? >>>>>>> >>>>>>> David Lang >>>>>> >>>>>> We then get again to the "runnable tasks" problem that was >>>>>> discussed earlier... the system get's "deadlock-prone" if a subset of >>>>>> tasks is not run. >>>>>> Interprocess dependencies are not so easy to get right in general. >>>>> >>>>> I'm not suggesting that you don't run the 'untrusted' tasks, just that you >>>>> don't consider them when deciding if the system can suspend or not. if the >>>>> system is awake, everything runs, if the system is idle (except for the >>>>> activity of the 'untrusted' tasks) you suspend normally. >>>>> >>> b) you can't use cgroup for other purposes anymore. I.e. if you want to >>> have 2 groups that each only have half of the memory available, how >>> would you then integrate the cgroup-ignore-for-idle-approach with this? >> >> two answers to this >> >> 1. does this matter? do you really need to combine this 'suspend, even if >> there are processes trying to run' with other cgroup limitations? >> >> 2. who says that this must be limited to one cgroup? a cgroup can have >> several different flags/limits set on it, so why can't one of them be this >> 'ignore for suspend' flag? >> >> these seem like simple issues, what I don't know is if it's possible for >> the process that controlls suspend to follow such a flag without major >> surgury on it's innards (if it can, this seems like a easy win, but I can >> imagine internal designs where the software just knows that _something_ is >> trying to run and would have a very hard time figuring out what) >> >> David Lang > > Well, i fear it becomes some sort of parallel-tree structure... > If you want a cgroups-partitioning for one kind of attribute you now > need 2 containers for every possible stamping of that attribute... one > being flagged with 'ignore-for-suspend-decision' and one without that > flag. > Do you see what I'm getting at, or do I need more coffee and it is > irelevant to this concept? yes, it could mean a doubleing in the number of cgroups that you need on a system. and if there are other features like this you can end up in a geometric explosion in the number of cgroups. in practice I question if there is likely to be a need for this sort of thing on a system that's complex enough to use cgroups for other purposes. in particular, in this case the 'ignore for syspend' flag is not going to be set for programs that are trusted to be well behaved. Such programs are unlikely to be placed under other restraints (because they _are_ trusted to be well behaved) 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/
From: Ted Ts'o on 2 Aug 2010 08:20 On Sun, Aug 01, 2010 at 06:30:44PM -0500, James Bottomley wrote: > On Sun, 2010-08-01 at 16:40 -0400, Ted Ts'o wrote: > > This brings me back to a major problem I have with the pm_qos approach > > to power management. It assumes that applications know best, and that > > they should be free to tell pm_qos subsystem whether they need 0ms > > latency for wireless. > > Um, so this behaviour is isomorphic to the suspend block case for the > applications. I think everyone agrees that suspend block isn't optimal, > but we were prepared to use it as a starting point given the lack of > enthusiasm in android for the more innovative approaches that have been > proposed. Um, yes, that was deliberate. For some people I think people have gotten hypersensitive about suspend blockers, to the point that I think sometimes minds get closed automatically to say that suspend blockers or their requirements are evil/not really a requirement, so I decided to use another example other than scheduler control in the hopes of pointing out (a) there is a more general problem, and (b) application knows best is not enough, and (c) Arjan's claim that we don't need to do anything because all applications should be written to be "power optimized" and it shouldn't matter whether they are connected to the AC mains or not is a vast oversimplification. > That's why you present the user with choices and report on the outcomes. > At the end of the day the choice becomes binary: if the mobile optimised > browser burns you battery on the power meter, users will either > uninstall and move on to the next browser or deny the current browser > the ability to block suspend. Or they may decide to drop the device which has much worse battery lifetime in favor of the hardware that seems to do a much better job of controlling power overall... which is why if the Nokia folks want to claim that suspend blockers are no good, it's probably not going to change what ships with Android, and may be better power management strategy win. :-) > Right, but this comes back to the axes of control. They have to be > presented to the user in a simple but meaningful manner. In the general case, at least for today, I think it's useful if applications are told, "you are on AC mains", "you are on cell phone battery", "you are on a laptop battery". And from a user's perspective, I suspect if you are wanting something simple but meaningful, it's probably a single linear scale ranging between "performance optimized" and "power optimized", with maybe 1-3 points in between. Advanced users will want a much finer level of control, though --- I can imagine having a number of different sliders that control the tradeoff between power vs. performance on a number of different scales: networking, GPS performance, scheduler control, schreen brightness, etc. Android phones have a very simplified version of this widget, which allows you to toggle GPS on/off, bluetooth on/off, etc. And the GPS toggle is a good example of what I'm talking about. If you disable the GPS, then even if the application wants to use GPS, tough luck; it will have to settle for the less precise cell tower triangulation method. Again, it's the _user_ who gets the final say, not the application --- and that's as it should be. - Ted -- 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: Ted Ts'o on 2 Aug 2010 08:30 On Sun, Aug 01, 2010 at 09:05:48PM -0700, 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.... Part of the problem here may also be a naming problem. There are multiple reasons why you might want to block suspend, and it goes far beyond what the CPU can do. Let's give another example, from the laptop world. If you close the the MacBook, it "suspends". That is, all processes stop, and the CPU enters a sleep state. Sounds just like Linux's suspend-to-ram, right? Except for the fact that if you insert a USB cable connected to a iPod/iPad/iPhone, the CPU wakes up, and iTunes will do a sync, and then the machine goes back to sleep. And if the Mail application is in the middle of manipulating the IMAP mailbox, it will be allowed to finish what it is doing, and then the system goes to sleep. So in the case of both the MacBook, where the user has closed the laptop, and in the case of Cell Phone, where the user has pushed the button saying he/she's done working with the application, the _normal_ thing to do force all processes to go to sleep, and then let the CPU go to sleep. But, you may have applications that are specially privileged so they can ignore the user command to suspend the machine. Maybe it's an iTunes-like situation, where in response to some hardware interrupt, it's allowed to wake up, do its thing, and then go back to sleep, allowing the hardware to go back to sleep. Maybe it's a mail application that wants to wakeup every 15 minutes, suck down any new mail, and then go back to sleep. The suspend blocker is a way to achieve this --- and this has nothing to do with chip technology, but with a specific use case. - Ted -- 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 10:00
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. :-) > > 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. 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/ |