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

    * Bill Huey <billh@gnuppy.monkey.org> wrote:

    > Here's the problem, *a lot* of folks can do scheduler development in
    > and outside community, so what's with exclusive-only attitude towards
    > the scheduler ?

    You came to us as an ex-BSD developer (which has a completely different
    contribution culture) and early on i tried to explain to you (and we met
    in person at OLS2004) that the Linux way of getting code upstream is not
    that of social-engineering or talking the code upstream, but that of
    _coding_ your stuff upstream: working with others and getting good code
    accepted. I'm not sure you ever realized that point.

    To counter your myth of "upstream development exclusivity", here are
    some git-provided hard numbers. Since 2.6.22 was released 3 weeks ago,
    over half a million lines of code were added/modified/removed in the
    upstream -git kernel:

    5965 files changed, 332689 insertions(+), 269500 deletions(-)

    that massive amount of work was done by over 750 contributors. Out of
    those 750 contributors, more than 160 are _first time contributors_.
    Think about it, there's _lots_ of fresh blood, about 650 new kernel
    contributors a year. The kernel/sched.c file itself, with 274 commits
    and 88 unique contributors over the past ~2 years alone is one of the
    most actively and most diversely developed core kernel subsystems in the
    kernel.

    Regarding PlugSched, i'd suggest you to read the detailed explanation
    that has been offered in this and in related discussions over the past
    few years on lkml. (see: http://lkml.org/lkml/2007/4/15/124 and
    http://lkml.org/lkml/2007/4/15/64 and many other postings)

    To recap: we dont have a pluggable TCP/IP core either. Nor do we have a
    pluggable MM. Pluggable I/O schedulers are not an unconditional success
    either - Nick (I/O scheduler author) recently stated that and suggested
    the CPU scheduler to not be pluggable.

    Whether something becomes pluggable or not depends on many
    _technological_ factors but you appear to be dead-set on spinning _any_
    technical decision against pluggability into a conjured-up non-sequitor
    non-technical "so this means you have an exclusive-only attitude"
    position.

    Why do you do that? Why cannot you accept the plain fact that:

    _in a kernel, some things should not be pluggable_

    Simple as that. I am still in favor of PlugSched as a nice external
    patch because it keeps people interested in schedulers and keeps the
    competitive pressure up even higher (and other reasons), but there are
    _stronger factors than that_ against its inclusion into mainline. (see
    those many mails about those factors)

    Besides the technological advantages, the competitive pressure can be
    _even higher_ if the 'competition' is not in-tree but out-of-tree - and
    the end result is an ultimately better scheduler. Had we not rejected
    PlugSched 4 years ago CFS could easily never have happened. We'd have
    2-3 mediocre schedulers, instead of one good scheduler and _users_ would
    resist the removal of any of those schedulers, so no clear winner could
    ever gain enough momentum and Linux would forever be stuck with a stupid
    and inferior "you have to tweak the scheduler selection manually to your
    workload to get the max out of the system" handicap.

    But ... i can also understand it that you as a _person_ are unhappy:

    You were quite unhappy and bitter about me not including your lockstat
    patch in -rt, while all that happened was that for months i (and others)
    told you that the lockstat idea is nice and sound and tried to point it
    out to you how much simpler and more elegant it would be to use the
    lockdep infrastructure for the same purpose and tried to encourage you
    to pick that route. Peter Zijlstra implemented that approach meanwhile,
    and he used around a magnitude less code than your patch did. That code
    is upstream now. _You_ could have been the one who did that, and it was
    you who prevented yourself from having done that major contribution to
    Linux lock instrumentation.

    Perhaps partly influenced by your negative lockstat experience, you were
    also the first one who brought up the (pretty bogus) "elitist" "old
    guard" argument [ http://lkml.org/lkml/2007/4/14/115 ] as a reply to my
    initial CFS announcement, and shortly after your mail Con wrote his
    infamous outburst against CFS [ http://lkml.org/lkml/2007/4/14/199 ], to
    which you came up with another bogus "the main failure I see here is
    that Con wasn't included in this design or privately in review process"
    reply [ http://lkml.org/lkml/2007/4/15/4 ] that only fanned the flames.

    I believe by doing so you poured the oil of your own bitterness on his
    fire, thinly masked as neutral constructive criticism.

    So in my opinion you are far from being an unbiased observer in this
    matter, you keep repeating your old arguments without apparently
    listening to the replies and thus i doubt anything i say could really
    make you 'happy' :-/

    Really, i'd love it if you started contributing to Linux in a major way,
    instead of doing what seems to amount to stirring up personal
    controversy, and i believe the only inhibitor to such positive kernel
    contributions is _yourself_. If you spent half of the energy you are
    spending on writing these emails on producing actual code you could have
    become a maintainer of some nice Linux subsystem easily. (as many other
    people have become that who came to Linux much later than you) That door
    is still not closed of course, and i believe it all only depends on you,
    not on any upstream maintainer.

    Ingo
    -
    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-31 16:07    [W:0.031 / U:89.360 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site