Slashdot Mirror

← Back to Stories (view on slashdot.org)

Linux Gets O(1) SMP Patch As Late Christmas Gift

Posted by timothy on from the punishing-those-greedy-processes dept.

bodin writes: "Now that new-year's parties are over things are getting boring again. For those who want to see and perhaps even try something more complex, Ingo Molnar is announcing this patch that is a pretty radical rewrite of the Linux scheduler. This is big stuff!"

6 of 38 comments (clear)

  1. Will this help... by bihoy · · Score: 3, Interesting

    Before attempting to install this on my test box I'd like to know exactly what the performance inplications are to specific types of applications and services. For example I am extremely interested in improving JVM performance on a Linux box.

    Any information or direction about this would be very helpful.

  2. Warm Fuzzy by p3d0 · · Score: 5, Interesting

    Wow. I read this guy's description of what he has done. I hope he's a teacher, because his explanation of those complex issues was a joy to read.

    I have a BP6 dual-celeron Debian machine which already gives me the benefits of countless hours of volunteer time, including the SMP kernel and ReiserFS, along with dozens of free development tools. Now I see this guy working like a dog to tune the heck out of the scheduler for SMP machines, and I know that when I eventually run the 2.6 kernel, I'm again going to reap the benefits of his work.

    It's almost enough to make me learn to hack the Linux kernel out of a sense of obligation.

    --
    Patrick Doyle
    I mod down every jackass who puts his moderation policy in his sig. Oh, wait a sec....
  3. What I would like to know. by Anonymous Coward · · Score: 1, Interesting

    Will this make apache 1.x as fast as 2.0? I thought one of the main performance bottle necks in the 1.x series was that for every connection a new process had to be forked. And that the system suffered because each process added overhead because it was dependent on a scheduler that didn't scale well. Apache 2.0 solved this problem by using threads instead of forks. But with this new patch will the 1.x version work just as well as a 2.0 version that doesn't use the fancy new features

  4. Learning scheduler by adam613 · · Score: 2, Interesting
    Speaking of better schedulers, something I've been thinking about: What would happen if I made a scheduler that used a neural network to decide process priorities based on past behavior of the processes spawned by a specific program (how much time the process got last time, whether it gave up the CPU voluntarily, blocked for input, or got timer-interrupted, etc)?

    Each time a process became runnable, the NN could assign a priority, and the process would be placed on a priority queue (this isn't O(1), but it's better than O(p)). It seems to me like this would work; it would slow down wake_up_process() (i can't remember the exact name; i haven't looked at the scheduler since october) a bit, but the payoff as the NN got trained should make up for it...



    (if this is a terrible idea, tell me so before you moderate me down :) )

    1. Re:Learning scheduler by pthisis · · Score: 3, Interesting

      This is a terrible idea. The fact is, for 99% of applications the scheduler isn't a bottleneck. Even on Alan Cox's worst-case 8-way SMP machines the scheduler doesn't eat tremendous amounts of CPU; _way_ more than it should, but an approach like Ingo Molnar's or Davide Libenzi's will get rid of most of that overhead.

      But the real reason it's a terrible idea is because of the cache-line impact. At this level of the system, keeping the CPU cache intact and full of process data is critical to good performance. Otherwise when you switch tasks you wind up having to go out to main memory, which is sloooow. So compact code is more important than fast code in a lot of these situations, and a neural net like you describe is going to be enormous relative to the approaches of Davide and Mingo.

      And Linus rightly pointed out that as simple as the current scheduler is, it's basically the only part of the kernel that's pretty much the same code as it was 8 years ago, mostly because it does work very well for the vast majority of cases. Not to say that Mingo, Davide, Rob Love, et al aren't doing a huge boon, and on 4-way and bigger systems it's more of a concern, but e.g. the VM and I/O subsystems are areas that could reap far greater performance rewards for the most common cases (and the VM is getting a ton of eyes, and the I/O subsystem has been the focus of most of the early 2.5 work thanks to Jens Axboe and others)

      Sumner Hayes

      --
      rage, rage against the dying of the light
  5. Linus has included it in 2.5 by Shanes · · Score: 4, Interesting
    Linus has included Ingo's patch in 2.5.2-pre10

    Cool!