On Sat, 28 Jul 2007, Bill Huey wrote:
>
> My argument is that schedule development is open ended. Although having
> a central scheduler to hack is a a good thing, it shouldn't lock out or
> supress development from other groups that might be trying to solve the
> problem in unique ways.
I don't think anything was suppressed here.
You seem to say that more modular code would have helped make for a nicer
way to do schedulers, but if so, where were those patches to do that?
Con's patches didn't do that either. They just replaced the code.
In fact, Ingo's patches _do_ add some modularity, and might make it easier
to replace the scheduler. So it would seem that you would argue for CFS,
not against it?
> I think that's kind of a bogus assumption from the very get go. Scheduling
> in Linux is one of the most unevolved systems in the kernel that still
> could go through a large transformation and get big gains like what
> we've had over the last few months. This evident with both schedulers,
> both do well and it's a good thing overall the CFS is going in.
>
> Now, the way it happened is completely screwed up in so many ways that I
> don't see how folks can miss it. This is not just Ingo versus Con, this
> is the current Linux community and how it makes decision from the top down
> and the current cultural attitude towards developers doing things that
> are:
I don't think so.
I think you're barking up the totally wrong tree here.
I think that what happened was very simple: somebody showed that we did
badly and had benchmarks to show for it, and that in turn resulted in a
huge spurt of coding from the people involved.
The fact that you think this is "broken" is interesting. I can point to a
very real example of where this also happened, and where I bet you don't
think the process was "broken".
Do you remember the mindcraft study?
Exact same thing. Somebody came in, and showed that Linux did really badly
on some benchmark, and that an alternate approach was much better.
What happened? A huge spurt of development in a pretty short timeframe,
that totally _obliterated_ the mindcraft results.
It could have happened independently, but the fact is, it didn't. These
kinds of events where somebody shows (with real numbers and code) that
things can be done better really *are* a good way to do development, and
it's how development generally ends up happening. It's hugely
motivational, both because competition is motivational in itself, but also
because somebody shows that things can be done so much better opens
peoples eyes to it.
And if you think the scheduler situation is different, why? Was it just
because the mindcraft study compared against Windows NT, not another
version of Linux patches?
The thing is, development is slow and gradual, but at the same time, it
happens in spurts (btw, if you have ever studied evolution, you'll find
the exact same thing: evolution is slow and gradual, but it also happens
in sudden "spurts" where you have relatively much bigger changes happening
because you get into a feedback loop).
Another comparison to evolution: most of the competitive pressure actually
comes from the _same_ species, not from outside. It's not so much rabbits
competing against foxes (although that happens too), quite a lot of it is
rabbits competing against other rabbits!
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/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
