lkml.org 
[lkml]   [2006]   [Apr]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [patch][rfc] quell interactive feeding frenzy
From
Date
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/

\
 
 \ /
  Last update: 2006-04-07 16:16    [W:0.057 / U:0.108 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site