Messages in this thread | | | Date | Fri, 18 Jul 2003 13:38:10 -0700 (PDT) | From | Davide Libenzi <> | Subject | Re: [PATCH] O6int for interactivity |
| |
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
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |