Messages in this thread | | | Subject | Re: [patch][rfc] quell interactive feeding frenzy | From | Mike Galbraith <> | Date | Fri, 07 Apr 2006 16:14:54 +0200 |
| |
On Fri, 2006-04-07 at 23:56 +1000, Con Kolivas wrote: > On Friday 07 April 2006 23:37, Mike Galbraith wrote: > > On Fri, 2006-04-07 at 22:56 +1000, Con Kolivas wrote: > > > This mechanism is designed to convert on-runqueue waiting time into > > > sleep. The basic reason is that when the system is loaded, every task is > > > fighting for cpu even if they only want say 1% cpu which means they never > > > sleep and are waiting on a runqueue instead of sleeping 99% of the time. > > > What you're doing is exactly biasing against what this mechanism is in > > > place for. You'll get the same effect by bypassing or removing it > > > entirely. Should we do that instead? > > > > Heck no. That mechanism is just as much about fairness as it is about > > intertactivity, and as such is just fine and dandy in my book... once > > it's toned down a bit^H^H^Htruckload. What I'm doing isn't biasing > > against the intent, I'm merely straightening the huge bend in favor of > > interactive tasks who get this added boost over and over again, and > > restricting the general effect to something practical. > > Have you actually tried without that mechanism?
Yes. We're better off with it than without.
> > Just look at what that mechanism does now with a 10 deep queue. Every > > dinky sleep can have an absolutely huge gob added to it, the exact worst > > case number depends on how many cpus you have and whatnot. Start a slew > > of tasks, and you are doomed to have every task that sleeps for the > > tiniest bit pegged at max interactive. > > I'm quite aware of the effect it has :)
Ok. Do we then agree that it makes 2.6 unusable for small servers, and that this constitutes a serious problem? :)
> > Maybe what I did isn't the best that can be done, but something has to > > be done about that. It is very b0rken under heavy load. > > Your compromise is as good as any.
Ok.
-Mike
- 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/
| |