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@tmr.com>
"We have more to fear from the bungling of the incompetent than from
the machinations of the wicked." - from Slashdot
-
