On Fri, 9 Mar 2007, Bill Davidsen wrote:
>
> But it IS okay for people to make special-case schedulers. Because it's MY
> machine,
Sure.
Go wild. It's what open-source is all about.
I'm not stopping you.
I'm just not merging code that makes the scheduler unreadable, even hard
to understand, and slows things down. I'm also not merging code that sets
some scheduler policy limits by having specific "pluggable scheduler
interfaces".
Different schedulers tend to need different data structures in some *very*
core data, like the per-cpu run-queues, in "struct task_struct", in
"struct thread_struct" etc etc. Those are some of *the* most low-level
structures in the kernel. And those are things that get set up to have as
little cache footprint a possible etc.
IO schedulers have basically none of those issues. Once you need to do IO,
you'll happibly use a few indirect pointers, it's not going to show up
anywhere. But in the scheduler, 10 cycles here and there will be a big
deal.
And hey, you can try to prove me wrong. Code talks. So far, nobody has
really ever come close.
So go and code it up, and show the end result. So far, nobody who actually
*does* CPU schedulers have really wanted to do it, because they all want
to muck around with their own private versions of the data structures.
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
