* 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/
