On Mon, 2007-03-12 at 21:27 +1100, Con Kolivas wrote:
> On Monday 12 March 2007 20:38, Mike Galbraith wrote:
> >
> 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.
The test scenario was one any desktop user might do with every
expectation responsiveness of the interactive application remain intact.
I understand the concepts here Con, and I'm not knocking your scheduler.
I find it to be a step forward on the one hand, but a step backward on
the other.
Tossing in the SMT nice comment was utter bullshit. All kernels tested
were missing SMT nice.
> > 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.
Unless you target accurately.
> We are getting good interactive response with a fair scheduler yet you seem
> intent on overloading it to find fault with it.
I'm not trying to find fault, I'm TESTING AND REPORTING. Was.
bye,
-Mike
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
