Re: idea: set a niceness value under which a process won't awaken suspended CPU
Although the idea sounds good, the mechanism of using nice is very 2007 :-) This should be accomplished by putting this type of process in a specific cgroup. We can then use the cgroup freezer to freeze all tasks in that group, and thaw it when we see fit. I used a similar mechanism to fix the problem where my wife would have all sorts of flash things running in different tabs of her web browser, when I was switched over to my user profile on the netbook. I added some hooks into policy kit to thaw the background users cgroup and unthaw the logged in user. Really I could have just limited the amount of processor resources they had access to, but why waste the battery? Other than that I think this could be a very good thing. I also think this would be a good way to control things that we only want to run when plugged in. No reason to run some of those cpu intensive cron jobs when running on battery. -Jon On Mar 2, 2012 9:44 AM, John Gilmore g...@toad.com wrote: Here's a power-saving idea that's been marinating since 2007 (in an obscure corner of my mail queue). When I reviewed it today I didn't see anything too wrong with it. John Message-Id: 200710240912.l9o9c1k2026...@new.toad.com To: gnu Subject: OLPC idea: set a niceness value under which a process won't awaken suspended CPU Date: Wed, 24 Oct 2007 02:12:01 -0700 From: John Gilmore g...@toad.com An easy lever for CPU consumption management (power mgmt) would be to define a set of user processes that won't be scheduled in a power-suspended system. They won't wake the CPU even if their timer goes off, their packet arrives, or their fairy godmother calls. But if something else wakes the CPU, and it's going to stay running a bit while some higher priority process is waiting for flash or packets or something, these processes can run in the background. My idea is to tie this to nice. So if you nice -20, it puts you into this range. Say everything below -15, which lets you set a few priorities among the low priority background stuff. So if you nice things all the way down, they run when the CPU is powered, in the cracks when there's nothing else to do, but they don't cause the CPU to wake up to service them if nothing else is going on. For example, code that polls and updates the battery status once a minute in HAL. Or a system activity monitor that shows CPU state graphs or how many MHz we're running. Or an RSS feed reader. Or the thing that clears out Mozilla's cache. Or the incremental backup daemon that copies the machine's state to the school server. (If that ran with scavenged electricity, cool! It can raise its priority once a day or so, to make sure that a backup gets done one way or another.) The GUI could have a way to throw a process into this state or out of it. E.g. push your mail reader there, polling every once in a while for email, opportunistically. John --- End of Forwarded Message ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: idea: set a niceness value under which a process won't awaken suspended CPU
One problem you can get into with this scheme is a kind of priority inversion. If the low priority process does: fd = open(/foo/bar, O_RDWR); flock(fd, LOCK_EX); and the high priority process then also does: fd = open(/foo/bar, O_RDWR); flock(fd, LOCK_EX); and the low priority process then does: sleep(1); flock(fd, LOCK_UN); and the system then goes into suspend, you'll not wake up again after that second expires, and you might not wake up again soon at all. The low priority process doesn't even have to sleep explicitly, if it takes a page fault you get basically the same thing. Nice levels don't seem the right method of controlling which tasks get to wake up the CPU and which don't, but note that a simple per-process will/won't wake up the CPU flag won't avoid the above scenario either. On Fri, Mar 02, 2012 at 12:38:40AM -0800, John Gilmore wrote: Here's a power-saving idea that's been marinating since 2007 (in an obscure corner of my mail queue). When I reviewed it today I didn't see anything too wrong with it. John Message-Id: 200710240912.l9o9c1k2026...@new.toad.com To: gnu Subject: OLPC idea: set a niceness value under which a process won't awaken suspended CPU Date: Wed, 24 Oct 2007 02:12:01 -0700 From: John Gilmore g...@toad.com An easy lever for CPU consumption management (power mgmt) would be to define a set of user processes that won't be scheduled in a power-suspended system. They won't wake the CPU even if their timer goes off, their packet arrives, or their fairy godmother calls. But if something else wakes the CPU, and it's going to stay running a bit while some higher priority process is waiting for flash or packets or something, these processes can run in the background. My idea is to tie this to nice. So if you nice -20, it puts you into this range. Say everything below -15, which lets you set a few priorities among the low priority background stuff. So if you nice things all the way down, they run when the CPU is powered, in the cracks when there's nothing else to do, but they don't cause the CPU to wake up to service them if nothing else is going on. For example, code that polls and updates the battery status once a minute in HAL. Or a system activity monitor that shows CPU state graphs or how many MHz we're running. Or an RSS feed reader. Or the thing that clears out Mozilla's cache. Or the incremental backup daemon that copies the machine's state to the school server. (If that ran with scavenged electricity, cool! It can raise its priority once a day or so, to make sure that a backup gets done one way or another.) The GUI could have a way to throw a process into this state or out of it. E.g. push your mail reader there, polling every once in a while for email, opportunistically. John --- End of Forwarded Message ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: idea: set a niceness value under which a process won't awaken suspended CPU
On Mar 2, 2012 10:37 AM, Lennert Buytenhek buyt...@wantstofly.org wrote: One problem you can get into with this scheme is a kind of priority inversion. If the low priority process does: fd = open(/foo/bar, O_RDWR); flock(fd, LOCK_EX); and the high priority process then also does: fd = open(/foo/bar, O_RDWR); flock(fd, LOCK_EX); and the low priority process then does: sleep(1); flock(fd, LOCK_UN); and the system then goes into suspend, you'll not wake up again after that second expires, and you might not wake up again soon at all. The low priority process doesn't even have to sleep explicitly, if it takes a page fault you get basically the same thing. I believe the cgroup method will catch this though. I would have to double check, but I think that the cgroup becomes partially frozen returning EBUSY until all the processes can properly be frozen. At that time I believe it is up to userspace to thaw, or refreeze the group, unless the blocking process ends in which case the entire cgroup is set to the frozen state. -Jon ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: idea: set a niceness value under which a process won't awaken suspended CPU
On Fri, Mar 02, 2012 at 01:50:16AM -0800, Jon Nettleton wrote: One problem you can get into with this scheme is a kind of priority inversion. If the low priority process does: fd = open(/foo/bar, O_RDWR); flock(fd, LOCK_EX); and the high priority process then also does: fd = open(/foo/bar, O_RDWR); flock(fd, LOCK_EX); and the low priority process then does: sleep(1); flock(fd, LOCK_UN); and the system then goes into suspend, you'll not wake up again after that second expires, and you might not wake up again soon at all. The low priority process doesn't even have to sleep explicitly, if it takes a page fault you get basically the same thing. I believe the cgroup method will catch this though. I would have to double check, but I think that the cgroup becomes partially frozen returning EBUSY until all the processes can properly be frozen. At that time I believe it is up to userspace to thaw, or refreeze the group, unless the blocking process ends in which case the entire cgroup is set to the frozen state. You can still suffer from priority inversion if you freeze a cgroup with a low priority process in it that holds a resource that another high priority process needs. You indeed can't suffer from priority inversion between processes in the same cgroup if you are going to freeze all of them, but then you don't care about CPU wakeups for the high priority process either. I guess that what I don't see yet is how you would use cgroups to implement the goals of John's scheme. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: idea: set a niceness value under which a process won't awaken suspended CPU
On Mar 2, 2012 11:06 AM, Lennert Buytenhek buyt...@wantstofly.org wrote: On Fri, Mar 02, 2012 at 01:50:16AM -0800, Jon Nettleton wrote: One problem you can get into with this scheme is a kind of priority inversion. If the low priority process does: fd = open(/foo/bar, O_RDWR); flock(fd, LOCK_EX); and the high priority process then also does: fd = open(/foo/bar, O_RDWR); flock(fd, LOCK_EX); and the low priority process then does: sleep(1); flock(fd, LOCK_UN); and the system then goes into suspend, you'll not wake up again after that second expires, and you might not wake up again soon at all. The low priority process doesn't even have to sleep explicitly, if it takes a page fault you get basically the same thing. I believe the cgroup method will catch this though. I would have to double check, but I think that the cgroup becomes partially frozen returning EBUSY until all the processes can properly be frozen. At that time I believe it is up to userspace to thaw, or refreeze the group, unless the blocking process ends in which case the entire cgroup is set to the frozen state. You can still suffer from priority inversion if you freeze a cgroup with a low priority process in it that holds a resource that another high priority process needs. You indeed can't suffer from priority inversion between processes in the same cgroup if you are going to freeze all of them, but then you don't care about CPU wakeups for the high priority process either. I guess that what I don't see yet is how you would use cgroups to implement the goals of John's scheme. The cgroup would be the method to organize the processes that you don't want running all the time, but only when a higher priority processes has already woken the cpu and is doing significant work. If we put all these background processes in a special cgroup, we can freeze their activity before suspend, or any other arbitrary time at that point. Then it would be up to a process scheduler, or a userspace daemon to decided when we would want to thaw this group because our system will already be up and doing work. We can also put a lower priority on that cgroup as to not steal cpu cycles from the process that caused the cpu/system to wakeup to do work. Am I misunderstanding the concept proposed? -Jon ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: idea: set a niceness value under which a process won't awaken suspended CPU
On Fri, Mar 02, 2012 at 02:19:43AM -0800, Jon Nettleton wrote: One problem you can get into with this scheme is a kind of priority inversion. If the low priority process does: fd = open(/foo/bar, O_RDWR); flock(fd, LOCK_EX); and the high priority process then also does: fd = open(/foo/bar, O_RDWR); flock(fd, LOCK_EX); and the low priority process then does: sleep(1); flock(fd, LOCK_UN); and the system then goes into suspend, you'll not wake up again after that second expires, and you might not wake up again soon at all. The low priority process doesn't even have to sleep explicitly, if it takes a page fault you get basically the same thing. I believe the cgroup method will catch this though. I would have to double check, but I think that the cgroup becomes partially frozen returning EBUSY until all the processes can properly be frozen. At that time I believe it is up to userspace to thaw, or refreeze the group, unless the blocking process ends in which case the entire cgroup is set to the frozen state. You can still suffer from priority inversion if you freeze a cgroup with a low priority process in it that holds a resource that another high priority process needs. You indeed can't suffer from priority inversion between processes in the same cgroup if you are going to freeze all of them, but then you don't care about CPU wakeups for the high priority process either. I guess that what I don't see yet is how you would use cgroups to implement the goals of John's scheme. The cgroup would be the method to organize the processes that you don't want running all the time, but only when a higher priority processes has already woken the cpu and is doing significant work. If we put all these background processes in a special cgroup, we can freeze their activity before suspend, or any other arbitrary time at that point. Then it would be up to a process scheduler, or a userspace daemon to decided when we would want to thaw this group because our system will already be up and doing work. We can also put a lower priority on that cgroup as to not steal cpu cycles from the process that caused the cpu/system to wakeup to do work. Am I misunderstanding the concept proposed? If you suspend the whole cgroup whenever the system suspends, and thaw it when the system resumes, then yes, that'll give more or less the same behavior as John's proposal[*]. It doesn't change the priority inversion scenario, though. [*] Not entirely the same, as he seems to be talking about reliable CPU wakeup filtering as well, which just isn't possible in all cases, e.g. when a packet arrives, the NIC won't know whether that packet is destined for a high or low priority process, so you can't make the CPU wakeup decision in the NIC, and the CPU won't be able to make the decision either, as it would have to wake up to inspect the packet to do that, which is what you were trying to avoid in the first place! ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
