lkml.org 
[lkml]   [2007]   [Jul]   [28]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [ck] Re: Linus 2.6.23-rc1


    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 majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

    \
     
     \ /
      Last update: 2007-07-29 00:21    [W:4.136 / U:0.012 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site