During the recent debates about the Completely Fair Scheduler, Ingo Molnar explained why he rewrote the scheduler, "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." Regarding the recent debate he added, "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', and my reply to Con's mail still addresses a good number of points raised in this thread i think." Ingo also described his development style:
"I don't 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."
From: Ingo Molnar [email blocked] Subject: Re: [ck] Re: Linus 2.6.23-rc1 Date: Sun, 29 Jul 2007 22:24:22 +0200 * Satyam Sharma [email blocked] 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
CFS "a lot smoother as the load increased"
Preliminary 2.6.23-rc1 numbers posted to the linux-kernel list suggest that CFS appears to have worked out well on the desktop, even for "gaming smoothness", which SD supporters claimed was SD's strongest feature:
(Later in the thread the SD results improved slightly with a patch applied that turned off the sys_sched_yield() system call, but CFS still performed better and the unstable fps problem of SD was still there)
Maybe Linus was right about his decision? How many of the fanboys who attacked Linus compared the design and code of SD to that of CFS, as Linus likely did? Does CFS's clean design translate into a more reliable implementation?
CFS a lot better
CFS has proved a lot better. I tried some experiments with dummy data and changed the variants. It worked smooth through out.
The issue was not the decision
The issue was not the decision. It was the manner in which it was taken, the way in which it was handled, which was pretty amateur for somebody as experienced as Linus Torvalds.
I mean, Con argued for years about the poor performance of the Linux scheduler and got flamed in return. He put a lot of effort into SD and he gets a "thanks" in an email and a code comment. He has barely even been publicly acknowledged as been right about the failings of kernel scheduling. Kernel hackers, with their high-performance PCs afforded them by high wages and affluet employers, have long denied the problems that existed - how Linux really has been poor at handling desktop load until CFS has been adopted then fixed.
I'm glad CFS is the right implementation. But the kernel team could have been a lot more humble in their decision taking.
Actually lately Ingo has handled himself exceptionally well - taking a lot of flak and being the middle of a lot of flaming without responding to it negatively. Some of his contemporaries have behaved in a less-than-stellar way. (The main example being Linus' email lambasting Kolivas which was completely out of order and reignited this whole thing.)
Tactless
As tactless as Lignus is in his email communication I am surprised the kernel has never forked. Perhaps the success of the kernel team is more due to the quality of the second tier leadership, despite Molnar's maliciousness.
I mean, Con argued for
Can you provide any evidence that he got flamed in return? He flamed contributors and got into unnecessary fights, sometimes even with testers who gave feedback, instead of fixing regressions. He rarely got criticism on his own list, perhaps he expected the same treatment on the much rougher kernel list?
I agree that the current
I agree that the current scheduler outright sucks for any kind of interactive workloads. But I truely cannot see how this translates into amateurish handling on part of the kernel developers. Linus has for a while stated that "if you disagree with us, prove us wrong, show us the code" -- that's what Con did, and he very clearly deserves kudos for it.
At that point, Linus *was* impressed (http://article.gmane.org/gmane.linux.kernel/500764), until the reported regression which triggered all of this drama. And in my opinion, Ingo's new scheduler *is* an acknowledgment that Con was right about the scheduler needing improvement. (Imitation is the sincerest form of flattery, they say)
Whether Ingo's competitive scheduler was warranted or not is a political question; sadly it means that Con didn't get as much credit as he perhaps deserves. But the reports on LKML clearly seem to indicate that CFS is the superior choice in practice; Con wasn't going to include the sleeper-fairness "hack" in his scheduler, and I think all users should be thankful that we now have an even better-performing scheduler from Ingo.
At least that is my impression of the whole deal.
CFS a lot better
CFS is a lot better in performance. Experiments with varying loads and data ran smoothly with CFS.
" Ingo Molnar explained why
"
Ingo Molnar explained why he rewrote the scheduler, "CFS started out as a slap-my-name on an existing thing, to clean up the after-effects of a good patch Con Kolivas sent me namely my name disappearing from that file maintainership.
Had anyone told me at that time that I'd end up getting away with it I'd have slipstreamed my few-hours-old hack into 23-rc even faster and I'd have pointed to the large number of pending opinions the finger
"
Fixed that for ya ;)
Nice trolling Mr. Ballmer -
Nice trolling Mr. Ballmer - running out of arguments? Any chair throwing today? :0)
SD patch size:
CFS patch size:
The code is radically different too, have a good hard look here:
Even Con Kolivas confirmed that the two are different to the very core, even in their interpretation of "fair":
Ingo wrote: "(granted, CFS
Ingo wrote:
"(granted, CFS does a whole lot more than that, its patch-impact size is 3 times larger than SD. CFS is not a single patch but a series of 50 patches, which also modularize kernel scheduling policy implementation (note, it does not modularize the scheduler itself a'la PlugSched), offer "group scheduling" (nifty thing for containers/virtualization and large systems, written by Srivatsa Vaddagiri of IBM), offer precise CPU usage accounting to /proc (used by CPU/task monitoring tools), and much more. We decided to turn Linux scheduling upside down, which gave me the easy excuse opportunity to extend the scheduler's design a bit more ;-)"
http://linux.slashdot.org/comments.pl?sid=248317&cid=19822051
So despite the patch being larger - the design might still be simpler.