Re: [patch][rfc] quell interactive feeding frenzy

[Mike Galbraith <efault@gmx.de>]

On Mon, 2006-04-10 at 11:12 +0200, bert hubert wrote:
> On Sun, Apr 09, 2006 at 08:07:41PM +0200, Mike Galbraith wrote:
> > Rare?  What exactly is rare about a number of tasks serving data?  I
> > don't care if it's a P4 serving gigabit.  If you have to divide your
> > server into pieces (you do, and you know it) you're screwed. 
> 
> You've not detailed your load. I assume it consists of lots of small files
> being transferred over 10 apache processes? I also assume you max out your
> system using apachebench?

It's just retrieving the directory, so it's all cached.  Yes, it's ab.  

If it had to hit disk constantly, I'd probably be able to login, because
the stock scheduler blocks IO bound tasks from achieving max priority.

> In general, Linux systems are not maxed out as they will disappoint that way
> (like any system running with id=0). 
> 
> So yes, what you do is a 'rare load' as anybody trying to do this will
> disappoint his users.

Ok, it's rare... if you buy your hardware 10 sizes too large ;-)

The load just doesn't matter though, this apache load is by the
scheduler's own standard a cpu hog.  If you eliminate the man made
sleep, those httpds drop right down where they belong.

> And any tweak you make to the scheduler this way is bound to affect another
> load.

It's not a tweak, it's a bug fix, and course it will affect other loads.
As things stand, that code is contributing to interactivity, and
fairness, but is also contributing heavily to grotesque _unfairness_ to
the point of starvation in the extreme.

You may not like the testcase, but it remains a bug exposing testcase.

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