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

13 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. Re:SMP by Arker · · Score: 2, Interesting

      This aspect is improved across the board in 2.6, as well as the SMP issues. Sure, the uniprocessor machine may be a little slower, but response latencies in X are a lot better, and this makes more of a difference to users.

      I beg to differ. I couldn't care less about X, I haven't even used it in over a year. Like the vast majority of Linux boxes, mine runs in console mode only, and on a single processor. I, and the rest of the world that uses it like this, find it hard to see anything to get excited about in 2.6. It could be that misty thing that happens with your memory over time, but it certainly seems like my first linux box (slack 1 on a 386-25) had better performance than I get now with substantially more powerful hardware in fact. At the very least I'm certainly not seeing any dramatic improvements. I used to upgrade kernels as a matter of course, but now I just don't care, unless there is a security update involved. If it weren't that necessary maintainence work (security patches, in particular) were suspended long ago I'd be tempted to swap in a fresh drive and give it a try, in fact.

      Like I say, it's nice to see SMP support getting better, I've got nothing against it, or any of the other features that have been introduced over the years, but when it starts interfering with performance on the machines that need performance the most, and coincidentally the ones that account for the vast majority of boxes running Linux as well, there is obviously something going wrong. Maybe the config scripts need more work, maybe there is nothing to do but fork large sections of the kernel, I don't know, but if Linux keeps getting worse at fulfilling its bread-and-butter role it will eventually have to be replaced with something else.

      Do you really want to see Linux running on Minicomputer class machines (the kind that private citizens usually can't afford) exclusively, at the expense of being usable in its traditional role of turning cheap old boxes on their way out the door into powerful and stable servers? Does Linus?

      I don't, and I predict there are enough programmers out there that agree with me that if the trajectory continues we'll eventually see either a kernel fork, or a mass migration to *BSD, or both.

      --
      =-=-=-=-=-=-=-=-=-=-=-=-=-=-
      Friends don't let friends enable ecmascript.
  2. I just can't do it by Anonymous Coward · · Score: 0, Interesting
    I spent 5 minutes trying desperately to think of anything even remotely interesting to say about this article and couldn't.

    Is it really worth posting this kind of stuff on its own on Slashdot, surely it would make more sense to include it in a roundup of news.

    And I didn't call you Shirley.

  3. 2.4 vs 2.6 by Doesn't_Comment_Code · · Score: 2, Interesting

    I assume that when they say the 2.4 Kernel outperforms the 2.6 on a uniprocessor computer, but not on a multi processor computer, that they have recompiled the kernel for each hardware environment.

    This struck me as strange, because when the kernel is compiled without SMP support, all that code is left out. So it doesn't seem like the 2.4 should outperform the 2.6 on one cpu.

    Does anyone know why this might be?

    --

    Slashdot Syndrome: the sudden, extreme urge to correct someone in order to validate one's self.
  4. 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();
    1. Re:I'm a bit leery. by Dacmot · · Score: 2, Interesting

      I've experienced this exact behavior before. It's because you don't have DMA enabled for your hard drive(s). "hdparm -d /dev/hda" will confirm that (off).

      To fix it you need to compile the kernel with the right PCI IDE chipset support. The only way I know of checking which one it is is to compile all the PCI IDE chipset support into the kernel and catch yours by doing "dmesg | more" after rebooting with the new kernel. Find which is yours and recompile without the other ones... that should do it.

      With DMA enabled you should see a very good overall speedup and no more lock-ups. Especially for hard-drive I/O stuff like "mkisofs, cdrecord, bzip2 some huge file, cp anything large, installing (via aptitude) or even the "Reading Package Lists...." stage of apt-get update"

  5. Architeture by HogGeek · · Score: 2, Interesting

    I didn't see anything in the articles to support this, but I'm assuming this is based on x86 architecture. Has 2.6 been ported to other architectures? And if so, have these AIM tests been run ?

  6. Re:Rock? by kasparov · · Score: 2, Interesting

    Where did you see that it is 7% slower with one proc? What is 7% slower than what with one processor? Not trying to disagree with you or anything, I just didn't notice anything in the article and was hoping for link.

    --
    There's no place I can be, since I found Serenity.
  7. 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!!!!
  8. 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.

  9. Re:GREAT by stevezero · · Score: 1, Interesting

    ok, that was funny. I usually get blase(insert accent aigu) about Soviet Russia jokes, but that one made me laugh, sir/madam/beast/cronjob.

  10. Scaling, et al by Anonymous Coward · · Score: 2, Interesting
    First, we need the common elements of bproc/mosix in the kernel. The specialized stuff, for each approach, may need to be kept out, but some level of generic process migration support is important.


    Second, unicasting looks to be slower. Ugh. I don't like that. That suggests to me that there are segments of code which are optimized for multi-processor use - which is great - but either there aren't uniprocessor versions, or the uniprocessor versions are highly non-optimal.


    Third, scaling needs to be improved. I don't know if Linux staggers bus use, to optimize usage, but if it doesn't, it should. Perhaps make use of the existing QoS code, or inject wait states if you know an internal bus is going to be heavily loaded.


    Fourth, the scaling between 2-CPU and 4-CPU suggests that something is kicking in at the 4-CPU level that's seriously good. My guess would be NUMA, which IIRC, was tied to the 4+ CPU level. NUMA developers might want to look and see if there's anything which stipulates more CPUs than it actually requires.


    Fifth, we need to sort out this damn RTOS issue. Linux 2.6 is supposed to go RT when the priority reaches a certain level, but it seems to be more of an rtsched-type scheduler trick than actual RT code. There are lots of approaches out there (RTAI springs to mind) and it might be good if someone added some good hooks into the OS for real-time operation.


    Sixth, and this goes along with the above, HP have a scheduler plugin system. Ok, it seems that pluggable schedulers aren't in vogue, but I do like the concept of a scheduling tree with tunable branches.


    Seventh, either use UGASI or don't. Adding in IPSEC is cool, and all that, but the old IPv6 stack is beginning to get stale. (In fact, there's also a lot in the IPv4 stack that's stale, and needs to be replaced.)


    Last, we've got the filesystems. I've not seen much serious CODA or Intermezzo work, recently, and I've never known the kernel-provided Intermezzo to work without problems. On the other hand, we've got Lustre, which seems to be a whole lot faster, and seems to be under active development. Yes, it's "late in the day" to go adding whole new components, but the impact would be minimal, and it would make a lot of networked users very happy.


    (And happy network users give karma to slashdot freaks! :)