Torvalds Explains Scheduler Decision
Firedog writes "There's been a lot of recent debate over why Linus Torvalds chose the new CFS process scheduler written by Ingo Molnar over the SD process scheduler written by Con Kolivas, ranging from discussing the quality of the code to favoritism and outright conspiracy theories. KernelTrap is now reporting Linus Torvalds' official stance as to why he chose the code that he did. 'People who think SD was "perfect" were simply ignoring reality,' Linus is quoted as saying. He goes on to explain that he selected the Completely Fair Scheduler because it had a maintainer who has proven himself willing and able to address problems as they are discovered. In the end, the relevance to normal Linux users is twofold: one is the question as to whether or not the Linux development model is working, and the other is the question as to whether the recently released 2.6.23 kernel will deliver an improved desktop experience."
CFS = completely fair scheduler
SD = staircase deadline.
That probably didn't clarify anything :/
Do you even lift?
These aren't the 'roids you're looking for.
"If a scheduler makes games better but hurts general server performance..."
IIRC that is the reason Con together with another person, whose name I can't
can't be bothered to look up, wanted to merge plugsched to which they got a
reply along the lines of "too much choice will split contributors" or some such
And then Ingo turns around on himself, and claims something along the lines of
"Oh okay, you should work on plugsched, may be it'll get merged"
I think the apparent rudeness stems from something deeper than a mere incomplete mastery of english.
Linus is (as I am) a Finn by birth. No matter how long he has been abroad, he still follows Finnish habits and speech patterns at least to a degree. And they differ significantly from the west european tradition. For example, small talk is considered unnecessary or even rude in some situations. Getting to the point is a virtue in any conversation. To someone not familiar with this pattern, it will sound unfriendly! It's a two-way street: to me many english speakers sound terriby smarmy and guarded.
Of course, Linus is apparently also rather clever. The downside of cleverness is for many having little tolerance for fools, real or percieved.
An AFC (Anonymous Finnish Coward)
A few months before Ingo wrote the O(1) scheduler, he flamed anyone who dared to suggest that an O(n) scheduler is a bad idea. He was *very* aggressive about it, going on and on about why O(n) is best and how O(1) would be worthless. Using Linus's words (about Con), Ingo "ended up arguing against people who reported problems [scheduler linearity], rather than trying to work with them". It therefore seems a bit strange that Linus uses this statement to describe Con, arguing this is why he favors Ingo...
Importantly, Ingo was dead wrong back then (indeed, this is why months after, Ingo came up with the O(1), announcing it as if it was his idea and as if nothing ever happened, not *ever* saying something like "I was wrong, sorry for the flames").
In contrast, Con was right in refusing to pollute the design of SD with Ingo's unfairness discipline. (This is what Linus referred to when he made the "arguing against" statement.) And what do you know? A few years after, Ingo comes up with a "Completely Fair Scheduler"...
I'm in scheduling research for many years. I followed the long Linux scheduling saga, which actually started way before Con was in business. Please believe when I tell you: Linus comments about Con are ludicrous, and petty. This is not Linus's finest hour.
Note however that this does not mean that Linus made the wrong decision: Even though SD is somewhat better than CFS, Ingo is orders of magnitude a better programmer than Con, orders of magnitude more knowledgeable, he gets paid to do the work, has gotten along with Linus for years, and will eventually make CFS as good as SD and even better. This is the real reason for Linus's decision. (Or at least, it should be.)
But the stuff Linus said about Con... well, that's just Linus being small.
Here is what Linus said in lkml
lkml full quote of Linus:
> People who think SD was "perfect" were simply ignoring reality. Sadly,
> that seemed to include Con too, which was one of the main reasons that I
> never ended entertaining the notion of merging SD for very long at all:
> Con ended up arguing against people who reported problems, rather than
> trying to work with them.
(from Linus's post to lkml)
The other misrepresentation is in this quote
> As a long-term maintainer, trust me, I know what matters. And a person who
> can actually be bothered to follow up on problem reports is a *hell* of a
> lot more important than one who just argues with reporters.
Because Kolivas was quite good with feedback--arguably better than Ingo or Linus (for example with Linus vs. SCSI-emulation cdrecord)--and recently had the single instance to which Linus refers. Ironically, Kolivas rejected a request to have code renice X processes for the same reason Linus rejected a request to keep SCSI emulation as de-facto: the design and code is cleaner and more correct. In fact, while Con would argue about small design issues and change his views, this renicing instance (some people called out as trolling because of the insistence and seeming insincerity) is the only time I've seen Con (and I have followed his work since he started) flatly and repeatedly reject a request.
There is merit in Linus's argument that a comparison of CFS and SD showed no "significant difference" in performance.
My personal take is that several years of minor spats between Ingo and Con made a better -ck patchset and -mm patchset, but never brought -ck closer to mainline. It came down to the good-old-boy system where Linus knew and trusted Ingo better than Con, and if there was a major disagreement, Ingo's side would be favored. But, honestly, Linus could also be considering that Ingo's resume has always been a programmer's resume (even if Ingo was one of the youngest maintainers at his start) while Con is a self-taught programmer (just to improve kernel responsiveness nonetheless!) with a primary passion as a physician. If Con decides not to continue with the -ck patchset, I am sure he will refocus the extra dedication and time to new patients.