[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4629244E.60408@tmr.com>
Date: Fri, 20 Apr 2007 16:36:30 -0400
From: Bill Davidsen <davidsen@....com>
To: Mike Galbraith <efault@....de>
CC: Nick Piggin <npiggin@...e.de>,
Peter Williams <pwil3058@...pond.net.au>,
Con Kolivas <kernel@...ivas.org>, Ingo Molnar <mingo@...e.hu>,
ck list <ck@....kolivas.org>,
Bill Huey <billh@...ppy.monkey.org>,
linux-kernel@...r.kernel.org,
Linus Torvalds <torvalds@...ux-foundation.org>,
Andrew Morton <akpm@...ux-foundation.org>,
Arjan van de Ven <arjan@...radead.org>,
Thomas Gleixner <tglx@...utronix.de>
Subject: Re: [Announce] [patch] Modular Scheduler Core and Completely Fair
Scheduler [CFS]
Mike Galbraith wrote:
> On Tue, 2007-04-17 at 05:40 +0200, Nick Piggin wrote:
>> On Tue, Apr 17, 2007 at 04:29:01AM +0200, Mike Galbraith wrote:
>
>>> Yup, and progress _is_ happening now, quite rapidly.
>> Progress as in progress on Ingo's scheduler. I still don't know how we'd
>> decide when to replace the mainline scheduler or with what.
>>
>> I don't think we can say Ingo's is better than the alternatives, can we?
>
> No, that would require massive performance testing of all alternatives.
>
>> If there is some kind of bakeoff, then I'd like one of Con's designs to
>> be involved, and mine, and Peter's...
>
> The trouble with a bakeoff is that it's pretty darn hard to get people
> to test in the first place, and then comes weighting the subjective and
> hard performance numbers. If they're close in numbers, do you go with
> the one which starts the least flamewars or what?
>
Here we disagree... I picked a scheduler not by running benchmarks, but
by running loads which piss me off with the mainline scheduler. And then
I ran the other schedulers for a while to find the things, normal things
I do, which resulted in bad behavior. And when I found one which had (so
far) no such cases I called it my winner, but I haven't tested it under
server load, so I can't begin to say it's "the best."
What we need is for lots of people to run every scheduler in real life,
and do "worst case analysis" by finding the cases which cause bad
behavior. And if there were a way to easily choose another scheduler,
call it plugable, modular, or Russian Roulette, people who found a worst
case would report it (aka bitch about it) and try another. But the
average user is better able to boot with an option like "sched=cfs" (or
sc, or nick, or ...) than to patch and build a kernel. So if we don't
get easily switched schedulers people will not test nearly as well.
The best scheduler isn't the one 2% faster than the rest, it's the one
with the fewest jackpot cases where it sucks. And if the mainline had
multiple schedulers this testing would get done, authors would get more
reports and have a better chance of fixing corner cases.
Note that we really need multiple schedulers to make people happy,
because fairness is not the most desirable behavior on all machines, and
adding knobs probably isn't the answer. I want a server to degrade
gently, I want my desktop to show my movie and echo my typing, and if
that's hard on compiles or the file transfer, so be it. Con doesn't want
to compromise his goals, I agree but want to have an option if I don't
share them.
--
Bill Davidsen <davidsen@....com>
"We have more to fear from the bungling of the incompetent than from
the machinations of the wicked." - from Slashdot
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists