idea: set a niceness value under which a process won't awaken suspended CPU

Jon Nettleton jon.nettleton at
Fri Mar 2 05:19:43 EST 2012

On Mar 2, 2012 11:06 AM, "Lennert Buytenhek" <buytenh at> 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?

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the Devel mailing list