Slashdot Mirror

← Back to Stories (view on slashdot.org)

Linux Kernel Benchmarking: 2.4 vs. 2.6-test

Posted by CmdrTaco on from the number-crunching dept.

frooyo pastes from kerneltrap: "Cliff White recently posted some re-AIM multiuser benchmark results comparing the stable 2.4.23-pre5 kernel against the 2.6.0-test5 and 2.6.0-test5-mm4 development kernels. In his conclusion he makes reference to earlier scheduler tests posted by Mark Wong saying, "Short summary: we mostly rock.""

5 of 293 comments (clear)

  1. SMP by Doesn't_Comment_Code · · Score: 5, Interesting

    The SMP code (written by Linux developers by the way) is supposed to be kicked up a notch in the new kernel. That's what I've heard anyway. I'd love to see Linux being the best OS for multiple CPU scaling.

    That will help everyone from the server market, to me when I save up enough for a two processor motherboard.

    --

    Slashdot Syndrome: the sudden, extreme urge to correct someone in order to validate one's self.
    1. Re:SMP by GooberToo · · Score: 3, Interesting

      Yes, there are. The scheduler is fully HT aware. It seems that many of the SMP and numa optimizations also apply to HT'ing as well. As such, the developers have been working hard to support it.

      Worth noting, however, it's not uncommon, even for a system that fully supports HT, to see a noteworthy performance drop when HT is enabled. Seems many new systems come with HT disabled in the BIOS for this very reason. Granted, I'm not 100% that's not a Window's specific issue rather than a broad-board HT issue, but something to keep in mind, nonetheless.

  2. I'm a bit leery. by devphaeton · · Score: 5, Interesting

    "the general trend in the metric indicates everything has been improving, so I think we rock."

    For some reason, the scheduling seems to get more and more choppy (in that i've noticed) with every iteration of 2.4.x kernel. Currently i'm on 2.4.22, and while i don't have any specific tests, numbers or statistics i'm noticing some issues.

    Easiest way to reproduce it is to have the machine do something cpu intensive, such as mkisofs, cdrecord, bzip2 some huge file, cp anything large, installing (via aptitude) or even the "Reading Package Lists...." stage of apt-get update.

    Oftentimes, the machine will become unresponsive for about 3 seconds at a time, then jolt back up to speed, then pause for 3, on and on. Even after the command line returns the prompt, or gkrellm's cpu and proc krells show that everything is all done, i will still see lag in responses from the kb, mouse, or whatnot off and on for about 10-15 seconds.

    I've gone over my kernel config and tweaked a few things here and there but with no change. I can back down to a 2.4.18 kernel and it's not as bad. Going down to a 2.2.x kernel completely solves the problem, but of course will bring its own issues with some of my newer packages (such as gcc) and a few pieces of newer hardware.

    A friend of mine and I have gone over this (on my machine and his) and he experiences a lot of the same issues i do.

    Mind you, i'm not complaining. I'm very grateful to all the developers of the world that i even *have* a linux system to run. But this is something that makes me more excited about the kernel 2.6.x series. I haven't tried one out yet, but from what i've heard and read, it should be awesoe. :o)

    --


    do() || do_not(); // try();
  3. Re:novel idea. by stratjakt · · Score: 3, Interesting

    It's only faster if you have 8 CPUs, your single proc desktop box will be slower.

    Which just reaffirms my belief that linux is becoming ever more firmly planted in the server world, and desktop linux is still just a hobby for the most part.

    --
    I don't need no instructions to know how to rock!!!!
  4. Re:Rock? by arkanes · · Score: 3, Interesting

    It might very well be slower than 2.4, but "feel" faster. The low latency stuff can improve responsiveness at the expense of performance.