Forgot your password?
typodupeerror
Linux Software

Torvalds Explains Scheduler Decision 411

Posted by kdawson
from the it's-the-guy-not-the-code dept.
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."
This discussion has been archived. No new comments can be posted.

Torvalds Explains Scheduler Decision

Comments Filter:
  • by Anonymous Coward on Saturday July 28, 2007 @03:46PM (#20025457)
    As it seems many others don't agree to his opinions of Con, http://lkml.org/lkml/2007/7/27/426 [lkml.org]
    • by Bin Naden (910327) on Saturday July 28, 2007 @05:01PM (#20026107)
      As Linus explained, he has tough decisions to make and the fact that CFS beat out SD this time, doesn't mean it will remain that way in future releases. Con should have sucked it up and worked harder on his scheduler.
      • Re: (Score:3, Insightful)

        by Frankie70 (803801)

        Con should have sucked it up and worked harder on his scheduler.

        And what would have been his reward for that.
      • Re: (Score:3, Insightful)

        by microbee (682094)
        Con HAS sucked it up for many years - he has maintained his scheduler work out of mainline tree for a very long time. The fact is that to merge any work that touches Ingo's code, you need Ingo's bless, and Ingo simply wasn't interested or convinced that his scheduler was worse by design, and as such he refused to replace his code with Con's and always wanted to "improve the existing code".

        Then one day SD appears and Ingo suddently announced his version of a fair scheduler, and after so many years of hard wo
  • by MoOsEb0y (2177) on Saturday July 28, 2007 @03:49PM (#20025487)
    What do CFS and SD stand for in this case? The summary and linked articles do not describe this.
  • by acidrain (35064) on Saturday July 28, 2007 @03:51PM (#20025491)

    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.

    • by Anonymous Coward on Saturday July 28, 2007 @05:32PM (#20026377)
      From the discussion it seems that Con Kolivas tried very hard to do what you're describing and ultimately had to tell off a single guy who kept harassing him after receiving much, much reasonable treatment and accomodation. Businesses do this all the time.

      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.
    • by acidrain (35064) on Saturday July 28, 2007 @05:32PM (#20026379)

      Whether Con was aware of it, when he tried to integrate into mainline Ingo was his main customer. Specifically the person he was trying to deliver work to. And Con committed the cardinal sin of telling a customer that the customer was wrong about what he wanted. Even if Ingo were too coked up to operate a keyboard reliably and had it all wrong, trying that never seems to work.

      Did Con gain anything by refusing to re-introduce the hack to get X working the way it had previously under load? Even if he'd just put in a #define that allowed it, and then spent the next year arguing to take it out, there wouldn't have been this breakdown.

  • The only important points to me are:

    1) Games are basic to linux desktops, we need linux games, so if Con scheduler was best on games, please, incorporate those changes.

    2) EGO's are a pain in the ass, it seems that Con has been refused by Linus , because he didn't take the whole history into acount, too bad, that kind of things happend in any not trivial project management. Don't let EGO's rule the ball, that's the most basic point a manager (Linus) has to respect to keep people on the project.

    • Re: (Score:3, Insightful)

      by MBCook (132727)

      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

      • by irwiss (1122399) on Saturday July 28, 2007 @04:20PM (#20025747)
        "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" [kerneltrap.org] 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" [kerneltrap.org]
        • by Rakishi (759894)

          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

          Well too much choice leads to bad things. Essentially each will be optimized for a subset of users despite the fact that they aren't in reality disjoint subsets of users. People run tons of things on their systems that don't fall into a single category, sometimes it's for testing and sometimes it's for actual use. Add in all the people who pick the wrong one and you have trouble. Remember that there are likely TONS of areas where such choices can be added in.

      • by TheRaven64 (641858) on Saturday July 28, 2007 @05:48PM (#20026523) Journal
        There's nothing wrong with having multiple schedulers in the tree. FreeBSD has two. 4BSD is stable, provides excellent throughput and is ideal for server workloads. ULE is newer, less tested (only been in use for about three years), and much better for latency-sensitive workloads, such as desktops. Both are actively developed. Users can pick the one they want as a compile-time option (4BSD is the default, since it has a decade more testing, and FreeBSD users tend to prefer 'stable' to 'shiny').

        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: (Score:3, Interesting)

      by miffo.swe (547642)
      1. Games run just perfectly on Linux with often better speed than in Windows. Every single game i has played in Linux has worked perfectly and smoothly. What Linux needs for gaming is more normal users who buys games. If there is a market someone will fill it quickly. I will also strongly refute that games are essential to desktops. There are infact people who use their computer to actually do something useful. 2. This decision has nothing to do with egos. This guy just happens to believe that its essentia
  • The guy walked away. It's like quitting the Internet. Obviously if your reaction is to take your ball and go home (and I know, the ball is everybody's in this situation, but go with it) then you aren't mature enough to handle the responsibility Linus requires.
    • by arivanov (12034) on Saturday July 28, 2007 @04:46PM (#20025991) Homepage
      Well...

      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.
      • by Anonymous Coward on Saturday July 28, 2007 @11:08PM (#20028767)
        I love it when web denizens who know only how to code 'html' love to bring in their views of someones motives.

        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.
    • by Anonymous Coward on Saturday July 28, 2007 @06:18PM (#20026739)
      This is a nonsense idea of a way of life. Life's too short to carry on with a task that is thankless, has lost its enjoyment, and has taken a toll on your health and relationships. Have you even read Con's side?

      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.
  • "desktop experience" (Score:3, Interesting)

    by drDugan (219551) on Saturday July 28, 2007 @04:05PM (#20025633) Homepage
    which kernel scheduler is pretty low on the list of factors affecting what the Linux desktop experience is all about...

    frankly, really high quality experiences take organizational planning and leveraging the expereince of huge groups in way that the "bazzaar" model of software developemnt in open source does not do well. Would someone please just build a mutual benefit corporation for open source users and maintainers? Let's start paying for project managers and the other experienced professionals required to make a "desktop experience" and you will see Linux take over.

  • The official kernel site [kernel.org] says 2.6.23 is only on release candidate 1.
  • by bogaboga (793279) on Saturday July 28, 2007 @04:10PM (#20025663)
    Having lurked on http://www.lkml.org/ [lkml.org] for several years, I find Linus to be rather rude. May be it's because English is not his first language...so words are not well chosen. I must say though, that I excuse him because he produces, [or helps produce] a very useful product on the world today. That is the Linux kernel.
    • by Anonymous Coward on Saturday July 28, 2007 @04:32PM (#20025855)
      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)
      • by drerwk (695572) on Saturday July 28, 2007 @06:10PM (#20026687) Homepage
        I had the pleasure of visiting Helsinki for work for 6 weeks in deep winter. The Finns are terrific. My favorite mannerism is when you get bumped on the sidewalk which is of course very icy, in the morning walk to work crowd, and fall on your behind. The polite response is a half laugh/cough "Ho!". No help up, no sorry, just "Ho!". At first, when it was me, I thought it was personal and rude. But I saw some poor lady get exactly the same treatment. Everyone was treated the same.

        During the same trip I saw the Gulf of Finnland freeze. First salt water body I've seen freeze. And the Finns were thrilled because now the drive to Tallinn was a mere 80 mi round trip, and the booze in Tallinn is tax free.

        Ooksie isso olute kiitose...pardon my phonetic spelling
        • by Anonymous Coward on Saturday July 28, 2007 @06:56PM (#20026999)

          No help up, no sorry, just "Ho!".
          That's "oho!", not "ho!". It's a bit like "ohh!" or something, i think.

          And I don't know if it's only here in Finland, but generally whenever we fall we just try to get up as fast as possible, proceed with whatever we were doing acting like nothing happened, and hope that nobody noticed this embarrassing situation. So somebody helping us up and repeatedly saying how sorry he/she is would just make it worse ;)

          -- Another Anonymous Finnish Coward
        • by jibun (61650) on Sunday July 29, 2007 @02:09AM (#20029725) Homepage
          Just to clarify, what you heard as "ho!" was probably the word "oho" which basically means the same as "oops" in English. For some Finnish people, especially for the younger urbanites, this word has replaced the Finnish equivalent for sorry, "anteeks(i)" [UN-tayk-s(ee)], presumably because they are too "busy" to ponder whether the incident was their fault or not. It's like pleading "no contest" :) This behavior is a product of Finland's accelerated post-WW2 urbanization which relinquished the grip of Finland's traditionally quite strict ethics on how you addressed your superiors and peers. You see, the rural societies were quite hierarchical but in the industrialized communities, where sons and daughters of farmers moved to work in factories, the young people declared themselves free of formal speech patterns -- for instance insisting on egalitarian thees and not yous (see http://en.wikipedia.org/wiki/T-V_distinction [wikipedia.org]).

          Unfortunately the current generation, the kids of these baby boomers (the 20 and 30-somethings of today) don't have the same sense of community that their parents had when they grew up, so they have gone over the top and partially lost their moral compass wrt. what is polite enough to be acceptable. There are signs of a counter-phenomenon emerging as a result of the very good economic growth in Finland's telecommunications sector (read: Nokia) which has increased the number of well-off people considerably and made middle class values somewhat fashionable again. Whether this will make people less rude on icy boardwalks, remains to be seen.

          Yksi kuiva siideri, kiitos. Pankille, kiitos.
      • by Johnno74 (252399) on Saturday July 28, 2007 @06:18PM (#20026735)
        I second that. I've worked with Finnish guys, and thats just the way they are. Its not that they are rude, its just that they don't care so much about being polite.

        This might trample on a few toes but it sure gets the job done.
      • by NaugaHunter (639364) on Saturday July 28, 2007 @10:59PM (#20028693)
        For example, small talk is considered unnecessary or even rude in some situations. Getting to the point is a virtue in any conversation.

        All these years I thought I was a social misfit, but apparently I'm just Finnish.

        Boy will my parents be surprised.
      • by Blakey Rat (99501) on Sunday July 29, 2007 @01:49AM (#20029631)
        Great, now instead of geeks pretending (or "self-diagnosing") Asperger's Syndrome to gain "geek cred", they'll learn Finnish. Just what we need, a bunch of Finnish-speaking introverts.
    • by Just Some Guy (3352) <kirk+slashdot@strauser.com> on Saturday July 28, 2007 @05:07PM (#20026175) Homepage Journal

      I must say though, that I excuse him because he produces, [or helps produce] a very useful product on the world today. That is the Linux kernel.

      You're going to love this Theo guy, then.

      I keed, I keed.

    • Re: (Score:3, Insightful)

      by Vellmont (569020)

      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'
      • by Just Some Guy (3352) <kirk+slashdot@strauser.com> on Sunday July 29, 2007 @03:26AM (#20030085) Homepage Journal

        I think you mistake brutal honesty for rudeness. [...] Imagine a scenario where there's a pushy person who overwhelms a person with a polite instinct.

        I think you mistake politeness for submissiveness. For example:

        • Rude: This code sucks.
        • Blunt: I don't like this code.
        • Submissive: Well, I could see why you like it, but I'm not sure...
        • Polite: That's an interesting idea, but doesn't quite fit with the approach we're taking. Thank you for your input, though.

        You can be polite and respectful without being a pushover. This is also commonly referred to as "tact".

        • Re: (Score:3, Interesting)

          by epine (68316)
          • Polite: That's an interesting idea, but doesn't quite fit with the approach we're taking. Thank you for your input, though.

          What you have depicted as polite I would portray as the inscrutible kiss-off of death. Thank you for your input, though.

          When I read Con's resignation screed, he put forward views of determinism I strongly disagree with. Con seems to have missed the news bulletin that adversarial solutions in game theory usually entail mixed strategies (i.e. non-deterministic responses).

          It's usually a

        • Re: (Score:3, Insightful)

          by SerpentMage (13390)
          I would add:

          * 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
  • by realdodgeman (1113225) on Saturday July 28, 2007 @04:13PM (#20025687) Homepage
    I find Linus' comments very interesting, and very honest. He has good arguments, and to me it seems like he did the right thing. He is even open to change scheduler if someone can prove that SD does a better job than CFS, and get someone reliable to maintain it.
    • by Anonymous Coward on Saturday July 28, 2007 @04:35PM (#20025877)
      Whatever way you want to paint it, that's exactly what he did.

      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: (Score:3, Interesting)

      by arth1 (260657)
      As long as it's not anything like the CFQ IO elevator, which has turned out to slow down and increase critical latencies on every system I've tested it on, compared with deadline and anticipatory schedulers. This seems to be especially true for hard working (i.e. underpowered) systems, where the need for a good IO scheduler is higher.
      I know, IO and job scheduling are two different things, but I still hope the "completely fair" naming part is coincidental, and not a promise of similarity.
  • by Anonymous Coward on Saturday July 28, 2007 @04:28PM (#20025811)
    It's an interesting set of emails. In addition to admitting that he actually didn't have any problem with the SD code, Linus points out that he made a gut call that Con is difficult to deal with without even looking into it because, apparently on near religious grounds, he doesn't believe in reading "specialized" mailing lists. What i find of concern is that he'd express such strong opinions about people basically without having even spent an hour or two browsing some list archives. Further, he seems perfectly aware that he may have heard just one side of the story, and yet he STILL doesn't feel he needs to look into it further or to soften his view? WTF ?

    Has Linux kernel development always been this ... arbitrary ?

    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.
    "

    • by SEE (7681) on Sunday July 29, 2007 @02:31AM (#20029853) Homepage
      Somebody directing a large effort does not have the ability to fully investigate every subsidiary dispute fairly without the effort grinding to a halt. Shorthand criteria are a necessity, as are rules of thumb as to what sources to bother investigating. This will inevitably lead to a number of less-than-optimum technical decisions along the way, but the results will be markedly superior to those where the manager stops everything to thoroughly investigate every aspect of every decision.

      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.
      • by 12357bd (686909) on Sunday July 29, 2007 @04:11AM (#20030241)

        I fully agree with the first part of your post, but I don't buy this 'Con's reaction justify Linus judgment' argument:

        1) It seems clear on the mailing lists that Con was really a good maintainer (only one 'problem' reported).

        2) Con's reaction seems quite understandable, after a very long time working on a project you see it not only refused by the maintainers (perfecty ok on that), but suddenly 'copied/inspired/wahtereryouwant' by that very same maintainer (not quite right).

        EGO leads to sectarism, that's all. The problem is that it seems that Con's scheduler was very good at gamming, and it's a shame that Linux dimissed a good piece of code on a specially sensible area for personal motives.

  • by Anonymous Coward on Saturday July 28, 2007 @04:30PM (#20025827)
    You can be pretty damn right that the desktop experience is improved with Ingo Molnar's scheduler! If you have done any serious audio work on any platform you know that Linux kernel + Ingo Molnar's IO scheduler = the best platform for serious audio work. This combination has the lowest latencies. Linux kernel+Ingo Molnar's IO scheduler+Ardour [ardour.org] offers currently lowest latencies and the best of all - it's completely free! It is pretty amazing - really. Every true professional audio engineer will agree with me.
    • by Chainsaw (2302)
      Except for the TRUE professional audio engineers. You know - the ones who have spent absurd amounts of money on Pro Tools gear.
    • Re: (Score:3, Interesting)

      by Blakey Rat (99501)
      But would it have been equally improved using Con's CFS? You aren't telling both sides of the story. (Which is fine, if you've only tried the one scheduler. But this topic is about the decision to use Ingo's rather than Con's.)
  • (Disclaimer - I have never met Linus or heard him speak on anything )

    After reading over the article, I came away with the impression that Linus appears to be an angry person. I have also noticed this in past topics where emails from Linus have been mentioned. So I am asking the question as to why he appears this way. Is it because I always see such references at particular time like now with hot button issues? Or perhaps because English is not his native tongue? Or is it because he really does have
  • Why not both? (Score:5, Interesting)

    by rm999 (775449) on Saturday July 28, 2007 @04:37PM (#20025901)
    Why can't there be a flag that determines what scheduler is used at runtime, with both schedulers built into the kernel? I thought the whole point of Linux is that it is customizable and modular - I know this doesn't necessarily apply to the kernel, but why not?

    I know very little about operating systems, schedulers, and maintaining large projects, so please excuse any ignorance in my post ;)
    • Re:Why not both? (Score:5, Informative)

      by MBCook (132727) <foobarsoft@foobarsoft.com> on Saturday July 28, 2007 @05:10PM (#20026207) Homepage

      Linux doesn't support that, as far as I know. There are variables you can tune though. More on this later.

      Something like that is very risky. Where as a filesystem can be used or not, and the code is only hit when accessing it, the scheduler is used constantly. If the scheduler could be switched at runtime, that means that either you have to have some kind of if statement on every scheduler entry point, or hide it all behind a pointer and a structure. Either one isn't as efficient as just having it hard wired in. You also have the complexities of being able to hand stuff off from one scheduler to another. Also, debugging get much harder (you have problem with slowness X, now which of the 3 schedulers are you using? Which version? What are the variables set to?).

      As for selectable at compile time, that means you have a have a well designed interface that lets you swap things out. That means it either has to be generic, or would favor one scheduler to the detriment of others. Sometimes this tradeoff is acceptable, sometimes it isn't.

      Now my understanding on this is that Linux doesn't support plugging in full schedulers. There were patches for that a few years go. Linus and others (Ingo especially, I think) said no, and the patches never made it in. Recently a system was developed that would allow a part of the scheduler to be plugged in. This way it could be better tuned for different workloads, without the full detriment of a full pluggable scheduler. This was done recently, and they were called out on this flip and explained quite well how they were a little hard, and this was a little different.

      Go read LWN [lwn.net]'s kernel pages. They talked about this in the last month or so, so it should be available to non-subscribers by now (although you should subscribe, they're great).

      • Re: (Score:3, Insightful)

        by r_jensen11 (598210)
        I'm voting for keeping it selectable when compiling the kernel.

        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 t
        • Re: (Score:3, Insightful)

          by bersl2 (689221)
          I really don't understand why Linus didn't take this approach*. He could have merged SD with the stipulation that he'd rip it out if he ever wanted to. I'm sure this would have kept Con around, instead of chasing off an important resource to the kernel's development.

          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...
  • by EnsilZah (575600) <EnsilZah@nOSPaM.Gmail.com> on Saturday July 28, 2007 @04:43PM (#20025961)
    Come on, it's quite obvious that Linus's secret superhero alter-ego has done battle with Kolivas' supervillain identity before (I mean, Con Kolivas? Do the writers even try to make these things sound authentic?) and is now trying to thwart his evil plans of global domination.
  • by 3seas (184403) on Saturday July 28, 2007 @04:49PM (#20026015) Journal
    ... I find a bit of hypocrisy.

    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 .... consideration about inclusion of code they wrote.. Uhhh did I forget to say its "Open Source"?
    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.

    • by shaitand (626655)
      '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.'

      Remind me again WTF that has to do with scheduling and desktop performance?
  • I am not a kernel developer and do not follow the mailing list. I was under the impression that a new scheduler that was supposed to drastically improve performance went into the kernel a couple years ago? I know there has been a huge difference in desktop performance from that time.
  • by forgoil (104808) on Saturday July 28, 2007 @05:33PM (#20026387) Homepage
    Start profiling the damn thing! Write performance tests, good ones, write really evil stress tests, stress the crap out of it, and then you will know what is *wrong*. Might not be the kernel at all, in fact, I think that a lot will be because of applications (always a huge source for problems), the UI/Graphics subsystem (again, huge source for trouble, X11, drivers, UI toolkits, they all tend to be far from perfect) and such.

    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).
  • Excuse me? (Score:3, Interesting)

    by deblau (68023) <slashdot.25.flickboy@spamgourmet.com> on Saturday July 28, 2007 @06:30PM (#20026835) Journal

    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.
    OK, Linus doesn't like people who don't play well with others.

    instead of keeping to your isolated world, instead of just talking about your own machine and ignoring other peoples machines and issues and instead of just denying that problems may exist, and instead of attacking people who report problems, how about working with them?
    OK, he really doesn't like people who don't play well with others. We get it.

    If a kernel developer uses Windows for his day-to-day work, I sure as hell wouldn't want to have him developing Linux. That has nothing to do with anything anti-windows: but the whole "eat your own dogfood" is a very fundamental thing, and somebody who doesn't do that shouldn't be allowed to be even _close_ to a compiler!
    Wait, what? Now who's not playing well with others? My hypocrisy meter just pegged.

    And what's with the massive ego? It's as if suddenly Linus thinks he invented compilers or something. I think he needs to take a vacation and regain some perspective.

    • Re: (Score:3, Informative)

      by dbIII (701233)
      The third bit SHOULD be obvious - if you run the thing all the time you will know how it behaves. If you run somebody else's work all the time you know how that behaves instead and seriously limit your exposure to the thing you are working on. A second low end box is cheap or even sitting there to be taken for free in a storeroom.
  • by paleshadows (1127459) on Saturday July 28, 2007 @10:19PM (#20028405)

    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.

  • by jurgen (14843) on Saturday July 28, 2007 @10:36PM (#20028525)
    This whole situation reminds me a lot of devfs. The developer of devfs (Richard Gooch) was maybe a bit of an outsider with good ideas and strong opinions that sometimes clashed with those of kernel developers that were more insiders or closer to Linus. The story is a little different in that devfs had actually made it into the mainline kernel, but then later was replaced by udev (the first draft of which was by Greg KH in a day or so... again very much like Ingo's whipping up the first draft of CFS).

    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 /lot/ of energy into their work. But that energy was not lost to the rest of us, as without the experience of their groundbreaking we would not have gotten the solutions we eventually did. Even if Greg KH's udev and Ingo's CFS share no appreciable amount of code or algorithms with devfs and SD, if they are honorable, I'm sure they would admit that they could not have so quickly whipped up their solutions without the example and inspiration of RG and CK's work.

    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. /Maybe/ instead of losing them in the long run we could have gotten some more innovation from talented developers like RG and CK. The problem, I think, wasn't the decision adopt CFS instead of SD. Rather, regardless of whether or not is true, the problem is Linus's public judgement that CK is not a "responsive maintainer". I didn't follow the CK or the lkml lists in that time frame enough to know if he is right... but a really good leader would not have made such a judgement public even if hed believed it, and instead would have worked to find a way to keep such talented persons contributing.

God made machine language; all the rest is the work of man.

Working...