Re: [PATCH] O6int for interactivity

[Mike Galbraith <efault@gmx.de>]

At 12:31 PM 7/18/2003 -0700, Davide Libenzi wrote:
>On Fri, 18 Jul 2003 Valdis.Kletnieks@vt.edu wrote:
>
> > On Fri, 18 Jul 2003 10:05:05 PDT, Davide Libenzi said:
> > > On Fri, 18 Jul 2003, Davide Libenzi wrote:
> > >
> > > > control them. It is right to apply uncontrolled unfairness to userspace
> > > > tasks though.
> > >
> > > s/It is right/It is not right/
> >
> > OK.. but is it right to apply *controlled* unfairness to userspace?
>
>I'm sorry to say that guys, but I'm afraid it's what we have to do. We did
>not think about it when this scheduler was dropped inside 2.5 sadly. The
>interactivity concept is based on the fact that a particular class of
>tasks characterized by certain sleep->burn patterns are never expired and
>eventually, only oscillate between two (pretty high) priorities. Without
>applying a global CPU throttle for interactive tasks, you can create a
>small set of processes (like irman does) that hit the coded sleep->burn
>pattern and that make everything is running with priority lower than the
>lower of the two of the oscillation range, to almost completely starve.
>Controlled unfairness would mean throttling the CPU time we reserve to
>interactive tasks so that we always reserve a minimum time to non
>interactive processes.

I'd like to find a way to prevent that instead.  There's got to be a way.

It's easy to prevent irman type things from starving others permanently (i 
call this active starvation, or wakeup starvation), and this does something 
fairly similar to what you're talking about.  Just crawl down the queue 
heads looking for the oldest task periodically instead of always taking the 
highest queue.  You can do that very fast, and it does prevent active 
starvation.

         -Mike