Re: [PATCH] O6int for interactivity

[Davide Libenzi <davidel@xmailserver.org>]

On Fri, 18 Jul 2003, Mike Galbraith wrote:

> >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.

Remember that this is computer science, that is, for every problem there
"at least" one solution ;)



> 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.

Everything that will make the scheduler to say "ok, I gave enough time to
interactive tasks, now I'm really going to spin one from the masses" will
work. Having a clean solution would not be an option here.




- Davide