Op Tuesday 06 March 2007, schreef Willy Tarreau:
quoted text
> In a way, I think they are right. Let me explain. Pluggable schedulers are
> useful when you want to switch away from the default one. This is very
> useful during development of a new scheduler, as well as when you're not
> satisfied with the default scheduler. Having this feature will incitate
> many people to develop their own scheduler for their very specific
> workload, and nothing generic. It's a bit what happened after all : you,
> Peter, Nick, and Mike have worked a lot trying to provide alternative
> solutions.

Did that happen for I/O? There are a few schedulers, eg some for servers,=20
other more for desktop or throughput. But not 10 or something...

quoted text
> But when you think about it, there are other OSes which have only one
> scheduler and which behave very well with tens of thousands of tasks and
> scale very well with lots of CPUs (eg: solaris). So there is a real
> challenge here to try to provide something at least as good and universal
> because we know that it can exist. And this is what you finally did : work
> on a scheduler which ought to be good with any workload.

I can imagine a desktop can work optimally with another scheduler than a ti=
ny=20
embedded OS in a phone or an 8-core system serving a website, or a=20
distributed 512 core system doing heavy scientific calculations?!?

Optimizing for all at the same time involves some compromises, and thus lim=
its=20
performance on certain scenario's, right?

quoted text
> Then, when we have a generic, good enough scheduler for most situations, I
> think that it could be good to get the plugsched for very specific usages.
> People working in HPC may prefer to allocate ressource differently for
> instance. There may also be people refusing to mix tasks from different
> users on two different siblings of one CPU for security reasons, etc... A=
ll
quoted text
> those would justify a plugable scheduler. But it should not be an excuse =
to
quoted text
> provide a set of bad schedulers and no good one.

CFQ does pretty well at most workloads, that's why it's default, right? But=
=20
there is choice, which is a good thing. And the current mainline CPU=20
scheduler isn't bad at all, so having 'no good one' won't happen anyway.

quoted text
> The CPU scheduler is often compared to the I/O schedulers while in fact
> this is a completely different story. The I/O schedulers are needed becau=
se
quoted text
> the hardware and filesystems may lead to very different behaviours, and t=
he
quoted text
> workload may vary a lot (eg: news server, ftp server, cache, desktop, real
> time streaming, ...). But at least, the default I/O scheduler was good
> enough for most usages, and alternative ones are here to provide optimal
> solutions to specific needs.

Ok, for I/O, the diff could be pretty big. But still, there are workloads=20
which could be improved by a certain scheduler, right?

And wouldn't it make sense then to have a choice in the default kernel at=20
boottime? If that wouldn't hurt performance, it would be an improvement for=
=20
desktop distributions like (K)ubuntu who can set staircase by default, and=
=20
server distro's offering RSDL...

At least having a desktop/interactivity optimized scheduler like staircase =
and=20
a fair, throughput-optimized scheduler like RSDL sounds sane. RSDL does=20
better at the msql testcase, staircase is better on the desktop... We're no=
t=20
talking about huge amounts of code, or 10 schedulers, and the diff of a few=
=20
percent and better scaling on many cpu's and processes versus better=20
interactivity on the desktop sounds like it's worth it.

quoted text
> Regards,
> Willy