On Mar 2, 2012 11:06 AM, "Lennert Buytenhek" <[email protected]> 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 [email protected] http://lists.laptop.org/listinfo/devel
