On Monday 12 March 2007 20:38, Mike Galbraith wrote:
quoted text
> On Mon, 2007-03-12 at 20:22 +1100, Con Kolivas wrote:
> > On Monday 12 March 2007 19:55, Mike Galbraith wrote:
> > > On Mon, 2007-03-12 at 19:29 +1100, Con Kolivas wrote:
> > > > I'll save you the trouble. I just checked myself and indeed the load
> > > > is only 1. What this means is that although there are 2 tasks
> > > > running, only one is running at any time making a total load of 1.
> > > > So, if we add two other tasks that add 2 more to the load the total
> > > > load is 3. However if we weight the other two tasks at nice 5, they
> > > > only add .75 each to the load making a weighted total of 2.5. This
> > > > means that X+Gforce together should get a total of 1/2.5 or 40% of
> > > > the overall cpu. That sounds like exactly what you're describing is
> > > > happening.
> > >
> > > Hmm.  So... anything that's client/server is going to suffer horribly
> > > unless niced tasks are niced all the way down to 19?
> >
> > Fortunately most client server models dont usually have mutually
> > exclusive cpu use like this X case. There are many things about X that
> > are still a little (/me tries to think of a relatively neutral term)...
> > wanting. :(
>
> But the reality of X is what we have to deal with.

And unix.

quoted text
> This scheduler seems to close the corner cases of the interactivity
> estimator, but this "any background load is palpable" thing is decidedly
> detrimental to interactive feel.

Now I think you're getting carried away because of your expectations from the 
previous scheduler and its woefully unfair treatment towards interactive 
tasks. Look at how you're loading up your poor P4 even with HT. You throw 2 
cpu hogs only gently niced at it on top of your interactive tasks. If you're 
happy to nice them +5, why not more? And you know as well as anyone that the 
2nd logical core only gives you ~25% more cpu power overall so you're asking 
too much of it. Let's not even talk about how lovely this will (not) be once 
SMT nice gets killed off come 2.6.21 and nice does less if "buyer beware" you 
chose to enable HT in your own words.

quoted text
> When I looked into keeping interactive tasks responsive, I came to the
> conclusion that I just couldn't get there from here across the full
> spectrum of cpu usage without a scheduler hint.  Interactive feel is
> absolutely dependent upon unfairness in many cases, and targeting that
> unfairness gets it right where heuristics sometimes can't.

See above. Your expectations of what you should be able to do are simply 
skewed. Find what cpu balance you loved in the old one (and I believe it 
wasn't that much more cpu in favour of X if I recall correctly) and simply 
change the nice setting on your lame encoder - since you're already setting 
one anyway.

We simply cannot continue arguing that we should dish out unfairness in any 
manner any more. It will always come back and bite us where we don't want it. 
We are getting good interactive response with a fair scheduler yet you seem 
intent on overloading it to find fault with it.

quoted text
> 	-Mike

-- 
-ck
-
unsubscribe notice
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/