Slashdot Mirror


User: paleshadows

paleshadows's activity in the archive.

Stories
0
Comments
32
First seen
Last seen
Profile
(view on slashdot.org)

Comments · 32

  1. Linus's double standard: a historical perspective on Torvalds Explains Scheduler Decision · · 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.

  2. Linus's double standard: a historical perspective on Torvalds Explains Scheduler Decision · · Score: 5, Informative

    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.

  3. Re:"the mainstay of Open Source clustering..."? on openMosix Is Shutting Down · · Score: 1

    why don't you use the original MOSIX? you can download it, you know (see links above). do you really care some parts of it come only in binary form?

  4. Re:What does this mean? on Secretly Monopolizing the CPU Without Being Root · · Score: 1

    masterpiece :)

  5. Re:What does this mean? on Secretly Monopolizing the CPU Without Being Root · · Score: 1

    What's this then ?

    0 00
    1 01
    2 11
    3 10
    Excellent question! This is the proof of how ignorant you are.
  6. Re:Solaris doesn't suffer from this on Secretly Monopolizing the CPU Without Being Root · · Score: 1

    Yes, I did miss the point and I thank you for pointing that out. I know how the default Solaris scheduler works and yes, it is vulnerable to this. However, I'm not so sure it's really a problem. I suppose it can become a problem for systems where you have a lot of users sharing the CPU, but other than that it's really a non-issue in most cases.
    It's definitely a problem in the common scenario where users share CPUs, because currently Solaris allows one user to starve all the rest!

    Perhaps Sun should ship a specific scheduling class that can be used for untrusted processes (although I suppose FIXED can somewhat fulfill this requirement).
    Yes, fixing the current scheduler seems the best way to go. All they need to do is use the accurate information they already maintain also for scheduling.
  7. Re:Fixed recently in Linux on Secretly Monopolizing the CPU Without Being Root · · Score: 1

    iabervon (1971) said:
    They took too long to publish this. Linux 2.6.21 (released in April) added support for using one-shot timers instead of a periodic tick, so it avoids the problem like OS X does ... The CFS additionally removes the interactivity boost in favor of giving interactive tasks no extra time but rather just quick access to their available time, which is what they really benefit from.
    Anonymous Cowered said:
    from reading the CFS documentation, I suspect Ingo read (or at least heard) of this paper, which is available on-line for more than a year according to one of the comments above. this is probably what Ingo means by saying "the CFS scheduler is not prone to any of the 'attacks' that exist today" see http://kerneltrap.org/node/8059

    iabervon (1971) said:
    On the linux-kernel mailing list, there was a lot of discussion of patterns that cause bad scheduling decisions with various schedulers, generally focused on making test cases for interactivity problems for workloads people had seen. Since the authors of the paper got their initial hint from having problems with a particular real load, this and the work that Ingo is referring to independantly encountered the same issues.
    Anonymous Cowered said:
    Perhaps you are right, but AFAIK, the LKML doesn't contain any mention of a systematic "attack": Much like the initial hint upon which the paper is apparently based, the workloads that are described in the LKML discussions are "legitimate", in that no application is doing anything malicious. (Also note that process hiding is never discussed.) So the fact Ingo chooses to use the term "attack" in this context suggests he knows something that was not mentioned in the LKML.
    Also, as was pointed out above, the paper was available on-line (in the form of a technical report) a year before the first version of Ingo's CFS and the tick-less patch. It often takes some time to publish a scientific paper, and there's nothing you can do about that.