Re: [ck] Re: Linus 2.6.23-rc1

[Ingo Molnar <mingo@elte.hu>]

* Satyam Sharma <satyam@infradead.org> 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 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/