* Satyam Sharma <[email protected]> wrote:
> > > So whats wrong then?
> > >
> > > Ingo decides to do a better scheduler - to some extent inspired by
> > > Con's work. And after 48 hours he publish first version that
> > > _anyone_ can see and comment on. Whats wrong with that?
> > >
> > > Did you expect some lengthy discussion before the coding phase
> > > started or what?
> > >
> > > Just trying to understand what you are arguing about.
> >
> > If I tried to rewrite a kernel subsystem - should I ever happen to
> > dig that deep into kernel matters - while I actually know that
> > someone already spent countless hours on exactly rewriting the exact
> > same subsystem, I think I would have told that other developer about
> > it as soon as I started coding on it. And if it just was a
> >
> > "Hi Con,
> >
> > I reconsidered the scheduling ideas again you brought to the Linux
> > kernel world. Instead of using your scheduler tough I like to try to
> > write a new one with fairness in mind, cause I think this, this and
> > this can be improved upon.
> >
> > I would like to hear your ideas about that as soon as possible and
> > would like you to contribute your ideas and also code, where you see
> > hit. You can find the git / bazaar / whatever repository where I do
> > my developments at: someurl.
> >
> > Regards, Ingo"
>
> Sending out the code (and early enough, 48 hours /is/ early enough)
> *is* the normal (and good) way to do exactly the communication you
> described above, IMHO.
yeah. And note that the time from the "ok, this approach might work"
point to releasing CFS was even less than the original ~62 hours of CFS
development.
I dont typically write code because i'm particularly "convinced" about
an idea or because i "believe in" an idea, i mostly write code to
_check_ whether an idea is worth advancing or not. Writing code is my
form of "thinking", and releasing patches is my form of telling others
about my "thoughts". I might have guesses about how well something will
work out in practice (and i'd certainly be a fool to go out coding
blindly), but surprises happen almost always, both in positive and in
negative direction, and even with relatively simple patches.
CFS started out as an experiment to simplify the scheduler, to clean up
the after-effects of a better-desktop-scheduling patch Mike Galbraith
sent me. Had anyone told me at that time that i'd end up writing a new
scheduler i'd have laughed at the suggestion and i'd have pointed to the
large number of pending patches of mine in forms of the -rt tree, the
syslet/threadlet code and other stuff that needs fixing a lot more
urgent than the task scheduler.
During that cleanup work did i realize how a policy-modularized
scheduler would allow the bridging of the seemingly unreconcilable
friction between the O(1) data structures that things like RT scheduling
needs and the binary tree that "fair share scheduling" concepts dictate.
(most of the complexity in kernel code like the scheduler derives from
complexity in data structures, so you start writing code by thinking
about your data structures.)
And the time from the point where i thought "ok, this fair-share thing
behaves pretty well and it certainly looks simpler than the current
code" to the announcement on lkml was more on the order of hours than
days - much of the 62 hours were spent on ripping out the old code and
on getting the new design up and running.
There was simply no code in existence before CFS which has proven the
code simplicity/design virtues of 'fair scheduling' - SD was more of an
argument _against_ it than for it. I think maybe even Con might have
been surprised by that simplicity: in his first lkml reaction to CFS he
also wrote that he finds the CFS code "beautiful":
http://lkml.org/lkml/2007/4/14/199
and my reply to Con's mail:
http://lkml.org/lkml/2007/4/15/64
still addresses a good number of points raised in this thread i think.
Ingo
-
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]
