Torvalds Explains Scheduler Decision 411
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."
Linus as the benevolent dictator again (Score:5, Insightful)
seeming to care is a big deal (Score:5, Insightful)
Having had my fair share disagreements with customers over technical issues, it just isn't worth trying to "win." The damage to your working relationships is still there even if you are shown to be 100% right. Try and help them address their problems as much as you possibly can, while trying to compromise as little as possible of the design. It's called diplomacy, and it's the difference between being given huge amounts of responsibility, and wanting to quit. You don't even have to agree with them, you just have to make them think you care.
Finally, it is common for programmers to try to avoid a subset of the problems in an area because it gives them the ability to write something "correct." Certainly a very satisfying experience for a programmer. However, that is exactly why it can be a bad idea to let a programmer rewrite a messy module. Very soon you can find the users of that module asking why a laundry list of things don't work anymore and an idealist developer trying to argue that they shouldn't... And it is exactly those idealists that like to rewrite working code. Not that major rewrites are bad, just that they have to be approached by someone mature enough to both expect a list of things they overlooked, and be willing to work with customers to resolve them.
Linus wins by default (Score:2, Insightful)
Re:good for you (Score:3, Insightful)
Re:Linus, Games are important! (Score:3, Insightful)
Number one can't be done some times. You may want Linux on the desktop, but at this point it is big on the server. It is used for a LOT of important stuff. If a scheduler makes games better but hurts general server performance, they just can't put that in without people eithe forking or switching. Now if it improved games and other desktop usage quite a bit but had a tiny effect on servers, that could be tennable. But if the effect wasn'nt tiny, they just couldn't blindly merge it.
All that said Linus makes a good argument. If the guy wasn't addressing problems well and was just arguing "that's not my scheduler's fault" or "prove that's a big problem" etc instead of working with people, there is a very good reason not to merge the code. Ingo wrote his quick and has spent lots of time with people since he did that working with others to find and fix problem workloads. He just seems to have been much more responsible about maintaining his scheduler and it's good performace.
There are trade-offs in evertying, and it sounds like Linus made a perfectly valid one here.
RTFA and understand (Score:4, Insightful)
Re:Linus, Games are important! (Score:1, Insightful)
tfa shows "interesting" view into Linus's outlook (Score:5, Insightful)
Has Linux kernel development always been this
From TFA (actually form the quoted emails) after several mails where Linus has been bashing this Con Kolivas guy for not taking feedback and being argumentative, and then offers some statements about the virtues of a good maintainer some guy "Kasper Sandberg" asks him:
"Okay, i wasn't going to ask, but i'll do it anyway, did you even read the
threads about SD?"
to which Linus responds:
"I don't _ever_ go on specialty mailing lists. I don't read -mm, and I
don't read the -fs mailing lists. I don't think they are interesting.
And I tried to explain why: people who concentrate on one thing tend to
become this self-selecting group that never looks at anything else, and
then rejects outside input from people who hadn't become part of the 'mind
meld'.
That's what I think I saw - I saw the reactions from where external people
were talking and cc'ing me.
And yes, it's quite possible that I also got a very one-sided picture of
it. I'm not disputing that.
"
Re:Nerds (Score:5, Insightful)
For that matter, even when I don't understand what an article is talking about, I am still usually more than interested to read about it.
Linus admitted to favoritism (Score:5, Insightful)
He believes that Ingo is a more reliable maintainer, so he chose Ingo's few-day old hack instead of Con's very mature and well tested scheduler.
Personally, I think that the person who is at fault here is Ingo, because he has a "Not Invented Here / By Me" mentality, and instead of developing Con's scheduler further, he totally objected to Con's work for ages (which prevented it from getting into mainline), and then suddenly saw the light and wrote his own quick hack based on the same design.
Ingo may be a good developer and maintainer, but he sure as hell isn't a friendly co-developer.
Re:Linus wins by default (Score:5, Insightful)
If we look at the core linux developers every single one of them has been flamed into a crisp by Linus on the average every few years (and some of them flamed back in turn). Every single one of them has had something turned down in flames and an alternative merged as well (in some cases Linus admitting that he made the wrong choice later). And I cannot recall anyone of them behaving like such a hissy primadonna.
Similarly, I have flamed people in a crips at work, I have been flamed back and I still work with this people 8+ years later. In some cases we have even come again to the same company and the same team to work together. It is just software, it is just a job and any code you have ever written can and would be ripped out by the project leader one day to be replaced by something else. Accepting this as a given is a sign of maturity. If you cannot do that, you are not mature enough to maintain a critical part of a software project. You should go away and play with toys in the sandpit for a while until you grow up.
Sorry, the guy does not get a bit of my sympathy.
Somehow in all what the three have said.... (Score:3, Insightful)
Three is right, as its Con and an email exchange between Linus and another.
Whooo hooo..
That settles it.... everybody is accounted for..... right??
Its open source but with all the talk about having a maintainer of certain character as a part of the consideration of
Its not uncommon for pioneers to be forgotten as what comes next, takes over...
Or does this mean that when a maintainer dies, so does what they were maintaining?
The general message Con seemed to be expressing was more interesting as a general observation than of specific code.
The response from Linus suggest that although Linus does not frequent specific topic lists because of inherent bias, he has his bias none the less.
There is a general across the board bias, proprietary and open source, and it is one of exclusion of the end users.
And it comes across as arrogance motivated by money and/or ego.
To explain, programming is an act that includes creating functionality that is then accessible thru an easier to use interface such as a function call with arguements and expected return value. The general concept is common knowledge in coding regardless of what programming language you are using,
However, this concept is not typically provided to the end user, but instead kept away from the user and certainly not provided to the user, when some distortion of it is provided the user, in any sort of easy common consistent manner.
To clarify, users access programs typically via a command line or GUI. Neither of which are so conducive to allowing teh users to put things together for themselves. All the functionality if available to the user via the programs GUI or command line. But the same functionality is not available in an mode that allows user to call the functionality in the program and make use of the results outside of teh programs command line or GUI interface.
Con mentioned the Amiga. The Amiga had all three user interfaces. The command Line, The GUI and the missing user interface an every other system today, The IPC port interface, most commonly known as the AREXX port but did not need AREXX running in order to use the port for "user putting things together for themselves".
SO YOU DON'T LET USER PUT THINGS TOGETHER FOR THEMSELVES! WHY NOT?
Cause you can dumb down the user and get ideas from them and sell those ideas implemented, back to them.
But when you take away from the users, the ability to put things together for themselves, then that makes you a hypocrite when you then call them ignorant, armchair coders or any other demeaning term. As it is you who have created that self supported dependency of trying to justify your lack of inclusion of others.
Con outright stated how he got started.
Maybe You linus and a whole world of other coders, need to pull you head out of your asses and SERIOUSLY realize, THERE ARE OTHERS you are not considering.
Ultimately, if people want to optimize their system for their needs, they should be able to. But there is serious prevention of that across the board.
Re:Linus as the benevolent dictator again (Score:4, Insightful)
Re:Linus as the benevolent dictator again (Score:0, Insightful)
Re:seeming to care is a big deal (Score:5, Insightful)
It also seems that Linus was tricked into torpedoing Con by people who gave him a very warped account of Con's actions. Either Linus got played and turned into a political tool of some anti-ck people, or he's making it appear that way to seem like an innocent victim. Linus evidently screwed up big-time here... but that should be expected from time to time.
If Linux sucks on the desktop (Score:4, Insightful)
But pissing and moaning won't do you any good. At least Con did try to write stuff, but not being a professional software engineer hurt his efforts I'm assuming. The guy would probably make a good technical manager though. It is a shame he felt he had to quit, it would have been much better if he could have gotten a few other kernel hackers on with him to go on. I think he ended up with a lot of users backing him, but no coders
Not that I am a Linux person, but I always find it sad to see people who are really into something quitting for bad reasons (bad in the sense that the shouldn't have to, not that he did something unwise).
Re:Why not both? (Score:3, Insightful)
You talk about a program favoring one scheduler over another or using generic calls. There are tons of programs out there already, without this new scheduler in mind, and they are running better than with the old scheduler. After this scheduler becomes common-placed, I'm sure the then-new programs will have some examples of running better with the old scheduler.
Keep both schedulers in the kernel, but only allow the users or the distributions to build one into the running kernels. This way it's the best of both worlds.
Re:Linus, Games are important! (Score:5, Insightful)
The situation for Linux is even simpler, since hardly anyone actually uses the stock kernel. Most Linux users use a kernel supplied by a distribution, which is compiled with a specific set of options and typically a few hundred patches. If one scheduler is good for desktops, and one good for servers, then merge them both and let desktop-focussed distros pick one and server-focussed ones pick the other.
Re:Linus as the benevolent dictator again (Score:5, Insightful)
Re:Linus wins by default (Score:5, Insightful)
There is no taking of balls home, just a clash with the monster egos of the Linux kernel. Don't question Con's maturity because he's made a decision to change his life. This in itself makes you sound seventeen and with no experience of life. There may be two sides to this story, so I won't make a judgement yet, but Linus has hardly shown himself to be broad and balanced in the past, has he?
The uncontrollable ego and senseless flaming that is associated with programming is nothing to be proud of and a block to new blood and new personality types (like Con's) getting involved, leaving us with this self-perpetuating industry of arrogant computer scientists attracting nothing but other arrogant computer scientists who are unmoved in by, and ignorant of, what their users want. Fine if you live in a bubble, but doomed by natural selection.
Re:Nerds (Score:5, Insightful)
Re:I find him rather rude (Score:3, Insightful)
Having lurked on http://www.lkml.org/ [lkml.org] for several years, I find Linus to be rather rude.
I think you mistake brutal honesty for rudeness. The post referenced is a bit harsh, but it's honest and to the point about how he feels. Politeness can often get in the way of expressing a point. That's not to say politeness isn't a valueable skill at all, it certainly is for a salesman or customer service person. I can be for many jobs, but being to the point is often more valueable in science and technology.
I don't read lkml very often, but from what I've read I think Linus is just strong willed about the things he has strong feelings for. Politeness has the potential to spill over into letting "bad" code into the kernel. Politeness can also hide peoples true intentions, which for anyone that just wants to understand the value system used to judge an idea can be maddening.
Imagine a scenario where there's a pushy person who overwhelms a person with a polite instinct. The polite person might just eventually give in instead of stating harsh realities defending what they believe to be the best idea. The pushy person might never learn why the polite person won't just accept what they think is right. It's not the best option for an honest discussion.
Anyway, I think you need to look at the situation as a discussion about what the best code is, and who does the best job at producing that code. Falling in love with your code (or anything you produce really) is a bad idea. It seems the kernel maintainer of the SD scheduler did just that, and Linus is only pointing that out.
Re:Linus as the benevolent dictator again (Score:3, Insightful)
Con should have sucked it up and worked harder on his scheduler.
And what would have been his reward for that.
Re:Linus as the benevolent dictator again (Score:5, Insightful)
If you're so hell bent on bringing MS's flaws into the bright light of community awareness, then stand up, be a fucking man, and apply that same attitude to Linux, or one day you'll wake up and Linux will be just as big a bug ridden piece of shit thanks to you stripping away the very system of honest objective peer review that has kept both the codebase and community bug free.
Re:Why not both? (Score:3, Insightful)
Of course, I get the distinct impression that Linus' impression of Con is not nearly as favorable as others'. I wonder why that is...
* I mean, I know why he didn't, but...
I'll take Linus's mis-steps, if ther ahve been any (Score:3, Insightful)
Sounds to me either scheduler will do the job just fine.
The decision between two good alternatives is always a difficult decision - someone, no matter how good the ideas, will feel slighted.
All Hail the Benevolent dictator (Score:1, Insightful)
One only has to look at the reaction of a programmer who quits because his pet project didn't get into the mainline kernel. He obviously was not the best choice for a long term maintainer.
Arguements over which code was superior are irrelevant at this point. The decision was made and will be made again when next revisited, after extensive testing and reporting. Right now the independent reports recieved by Linus were that they were pretty much equal. That only left him with the decision of who would be the better maintainer. He is the guy who gets to choose and I think he chose wisely. No offense to Con. I wish him all the best and hope he reconsiders as he matures.
I play games under Linux and I appreciate Con's efforts, but I understand that it is not the OS only focus. He didn't, Ingo does.
All Hail the Benovolent Dictator Linus. May his pragmatic glory shine upon thee.
Linus's double standard: a historical perspective (Score:5, Insightful)
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.
Re:Linus's double standard: a historical perspecti (Score:5, Insightful)
In the end this just demonstrates that having egotistical bastards running the show isn't always going to yield the best results. Linus and Ingo do fantastic work, and they do sub-par work. But when someone points the sub-par stuff out, head for the hills! They will always have a legion of fans defending them, more than willing to dumb-down the real issue in favor of pretending their infallible leaders are never wrong.
Re:I find him rather rude (Score:4, Insightful)
Um, no. It's that their definition of polite is not the same as yours.
Shades of devfs vs. udev (Score:5, Insightful)
Then as now with CK, eventually Richard stopped doing linux kernel work altogether. I thought it was a sad loss of a talented kernel hacker, and I had been a devfs user, but I must say that in retrospect I do think udev is a better solution. It is simpler, has less impact on the rest of the kernel, but has proven itself to solve all the problems devfs tried to solve that actually mattered.
What's the moral of the story? That both sides are right... on the one hand, there's something sad here, because at least several times in linux history an outsider had to fight for innovation and in the end was pushed away even as his innovation was grudgingly adopted by reinventing it. On the other hand the actual results do seem to indicate that linux is NOT resistant to change, and maybe that the better, more maintainable solution tends to win out.
There's also another thing to keep in mind... it is a pattern in this history of technology that the first attempt to solve a problem is rarely the one that becomes dominant. Both Con Kolivas and Richard Gooch should be recognized for the innovators that they are... and if they were wise they should also not begrudge the fact that it wasn't their exact solution which eventually got adopted by the mainstream. I know this is difficult... they both put a
Finally, I would like to add that although the way I see all this, it has little if anything to do with Linus's personality, nevertheless I think Linus could have handled these cases better.
Re:Linus wins by default (Score:5, Insightful)
Re:Linus wins by default (Score:5, Insightful)
Con didnt take his ball and go home, he finished what he started, did a damn fine job and is now moving to something else in his life which is going to be hard for computer geeks to understand.
The man does not live and breath technology, its just a hobby. By profession he is a doctor; a specialist in anaesthesia.
I got to know him when he was working on a benchmarking tool called Contest and truly is a renaissance man. I appreciate Stallman's knowledge of french, spanish, and of literature but he is a computer geek first and foremost.
Con will probably take up some other intellectual challenge like he did coding and be good at it too. He doesnt NEED to do just this and many cannnot grasp that.
Life is really too short to deal with egos when you are talented and have full of interests.
Doctor Colivas will do just fine.
Ah, so Linux has not "failed on the desktop" (Score:2, Insightful)
In other words: nothing to see here, move along, the increase in desktop Linux adoption will continue its slow but steady pace.
Re:tfa shows "interesting" view into Linus's outlo (Score:4, Insightful)
Con Kolivas's reaction to "losing" was not to continue to maintain SD and try to get it in later, or to try to improve CFS, but to quit kernel-hacking entirely. Which means he is not of a temperament that can accept that large projects will have arbitrary decisions that go against him, which means he would be a bad choice for the maintainer of a major kernel system. His actions in retrospect justify Torvalds's judgment that he couldn't trust him as a maintainer. Kolivas proved Torvalds correct on the management question, even if Torvalds is wrong on the technical one.
Re:Linus as the benevolent dictator again (Score:2, Insightful)
And he was right to do so - if people don't want to support their code it's useless no matter how elegant it is.
Re:I find him rather rude (Score:5, Insightful)
I think you mistake politeness for submissiveness. For example:
You can be polite and respectful without being a pushover. This is also commonly referred to as "tact".
Re:Linus, Games are important! (Score:3, Insightful)
oooh I love the double standards... (Score:3, Insightful)
Ah ok a solution is better... We use that solution, right? Because after all is that not what Open Source is all about? (http://en.wikipedia.org/wiki/Meritocracy)
Meritocracy is a system of government or other organization based on demonstrated ability (merit) and talent rather than by wealth (plutocracy), family connections (nepotism), class privilege, cronyism, popularity (as in democracy) or other historical determinants of social position and political power.
>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.
Ok so demonstrated was a scheduler that was better, but chosen was somebody who is perceived as being more knowledgeable, and gets along with Linus and EVENTUALLY will make CFS as good or better... And until EVENTUALLY hits I should wait around and suffer the problems? And how is this different from say Microsoft who refuses to fix bugs?
Let's call this what it is! Corporatism at the open source level with Linus's nepotism!
Re:I find him rather rude (Score:3, Insightful)
* Constructive: I looked at your code. Here is what is good. And here are the reasons why I am apprehensive about it. The problem that I have is that if I included the code there would be some serious ramifications namely XYZ.
Here is what most people cannot do. They cannot be constructive because using the arguments they proposed in the constructive it would imply that they would have to change their opinion. Thus people resort to "This code sucks."
Having written code and looked at code it is hard to have to change your opinion. We all too often fall into a trap, "this is how I did it and thus this is how everyone will do it." I suspect Linus feel into this trap because Con annoyed him personally....
Re:Nerds (Score:3, Insightful)
Re:Linus wins by default (Score:3, Insightful)
Sorry for not being able to be more exact, I have stopped following LKM around Y2K and the last time I have had any brush up with lk-?? lists was when reporting the fundamental bind/connect/send vs bind/sendto cockup in ipv4/udp.c 3-4 years ago.
Which by the way reminds me that Linus has one more point here. Selfselecting lists on one special subject suck. Based on trying to report the aforementioned ipv4/udp.c bogousity to linux-net I would absolutely agree with him here. It all went
Re:Linus as the benevolent dictator again (Score:3, Insightful)
Then one day SD appears and Ingo suddently announced his version of a fair scheduler, and after so many years of hard work Con simply found out that it was impossible to get his work merged or acknowledged respectively. He was pretty much bypassed by the Linus - Ingo DirectMerge feature.