Re: Ten percent test

[Andreas Mohr <andi@rhlx01.fht-esslingen.de>]

Hi,

On Mon, Apr 09, 2007 at 02:14:49PM +0200, Rene Herman wrote:
> This turned into an interactivity thing, and while interactivity is in 
> fact better for a large majority of testers, that isn't what Kolivas' 
> scheduler is about. It's about predictability and leaving the dead-end 
> road of these endlesss tweaks, which then break previous tweaks, rinse, 
> repeat.
> 
> It's unfortunate that Kolivas is having health problems currently, but I 
> certainly do hope that his scheduler finds its way into _a_ -rc1. He 
> said it was done...

The whole recent discussion/flamefest/... here makes me think that we're
still heading towards actually introducing plugsched (most preferrably
by making mainline scheduler the builtin default and optionally building
a plugsched kernel which then allows selection).
There are fundamental behavioural differences between the various
CPU scheduler types developed; while some people want a very interactive
system with in most(!) cases good latency and exploit-less operation,
several others want a scheduler which provides very predictable latency,
low overhead and additionally as much interactivity as this strict
model can provide for. And then there are people who have very specific
SMP requirements which both characteristic scheduler types may have trouble
satisfying properly.

And I really don't see much difference whatsoever to the I/O scheduler
area: some people want predictable latency, while others want maximum
throughput or fastest operation for seek-less flash devices (noop).
Hardware varies similarly greatly has well:
Some people have huge disk arrays or NAS, others have a single flash disk.
Some people have a decaying UP machine, others have huge SMP farms.

IMHO both areas are too varied, thus runtime or compile-time selection
is justified for both areas, not simply for I/O schedulers only.
I don't think anybody would want to introduce new very similar scheduler types
just for the fun of it; development would center around improving the at
most 3 or 4 different scheduler implementations (as is the case with I/O
schedulers, BTW: there hasn't been an explosion of different variants
either!).

I think the whole discussion went on the wrong track when people somehow
had the notion of making RSDL (and its later variants) the main scheduler
for desktop machines, not just server operation. And this target of course
(and rightfully so) prompted people to ask for interactivity similar
to what the current scheduler achieves which RSDL cannot fully provide
within its strict design, however.

However having mainline remain the only scheduler doesn't seem to be such
an attractive option either, e.g. due to its non-predictability, when there
exist several alternatives with rather nice behaviour.

Thus I'd still tend towards making things runtime-selectable, scheduler goals
are just too varied to ever sufficiently achieve Best Results
In Every Area (tm).

Not to mention that making schedulers runtime-selectable would enable
uncovering various application timing bugs much faster (e.g. the RPM timing
issues that -ck managed to hit).

Oh, and get well very soon, Con, Linux needs you, a lot :)

Andreas Mohr