On 8/3/07, Ingo Molnar <[email protected]> wrote:
> snip...
Except that a working prototype of plugsched exists and functions
exactly as advertised. I understand that modules can be loaded and
unloaded, where as other aspects of the core kernel can't just
load/unload as the kernel is running, but the cpu scheduler could be
selected at boot via a command line, or as a kconfig option when
compiling like the io scheduler.
And while the io team may feel that it would be best to have one
scheduler that worked well under all circumstances, often this can't
simply be the case. Benchmarks over the years seem to suggest that
different schedulers work different for different situations. In that
regard, choice does seem to be nice.
CFS is apparently better in its simplicity, however others are
reporting that SD still provides benefits for 3D gaming. Perhaps
there are instances where even more schedulers like nicksched might be
the most appropriate solution.
-- T. J.
"In the beginning the Universe was created. This has made a lot of
people very angry and been widely regarded as a bad move."
--Douglas Adams
"Nihilism makes me smile."
--Christopher Quick
* T. J. Brumfield <[email protected]> wrote:
> On 8/3/07, Ingo Molnar <[email protected]> wrote:
> > snip...
>
> Except that a working prototype of plugsched exists and functions
> exactly as advertised. [...]
a prototype for dynamic syscalls exists too. A prototype for pluggable
network IPv4 stacks exists too. A working implementation existed for
STREAMS too. Existence of a patch still does not make any of them a good
idea for the core kernel.
[ If existence of a patch was the only criterium for upstream merging
then we'd have a much poorer quality Linux kernel today. Odds are that
in that case you would not even know what 'Linux' means, it would
still be an obscure, niche hacker's toy somewhere on the 'net ;-) ]
> [...] I understand that modules can be loaded and unloaded, where as
> other aspects of the core kernel can't just load/unload as the kernel
> is running, but the cpu scheduler could be selected at boot via a
> command line, or as a kconfig option when compiling like the io
> scheduler.
i replied to that in my previous mail:
But the kernel core, which does not depend as much on the physical
properties of the stuff it supports (it depends on the physics of the
machine of course, but those rules are mostly shared between all
machines of that architecture), and is fundamentally influenced by
the syscall API (which is not modular either) and by our OS design
decisions, has much less reason to be modularized.
But to put it in different words:
_certain core kernel code should not be pluggable_
and whether it should or should not be pluggable is an entirely
technical decision, up to the maintainers of that code.
> And while the io team may feel that it would be best to have one
> scheduler that worked well under all circumstances, often this can't
> simply be the case. [...]
you skipped the bit where i pointed it out how different CPU scheduling
is from IO scheduling. Plus now you are arguing against the opinion of
an IO maintainer too? :-)
Ingo
* T. J. Brumfield <[email protected]> wrote:
> CFS is apparently better in its simplicity, however others are
> reporting that SD still provides benefits for 3D gaming. [...]
even for 3D gaming the opposite of what you say seems to be the case:
http://people.redhat.com/mingo/misc/cfs-sd-ut2004-perf.jpg
http://people.redhat.com/mingo/misc/cfs-vs-sd-wine-quake.jpg
( more such measurements were done and reported, i stopped doing
graphs after the first two. )
but in any case, the main "target" of CFS was not even SD (although it
is certainly desirable to handle any load at least as well as SD) but
the _mainline_ scheduler. SD was the primary selection of a relatively
small subset of existing Linux users, and SD had known (and intentional)
tradeoffs over the mainline scheduler in certain areas. CFS tried to do
zero tradeoffs over the existing scheduler, to not introduce regressions
to the many users who found the existing scheduler just good enough.
That's been a success so far, at the moment there's no open CFS
"interactivity regression" relative to the 2.6.22 mainline scheduler.
Ingo
