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

Lennert Buytenhek buytenh at wantstofly.org
Fri Mar 2 08:38:57 EST 2012


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!




More information about the Devel mailing list