Slashdot Mirror

← Back to Stories (view on slashdot.org)

Byte Benchmarks Various Linux Trees

Posted by timothy on from the root-and-branch dept.

urbanjunkie writes: "Moshe Bar has an interesting article, essentially benchmarking the standard kernel (with aa VM) against the -ac kernel (with Rik's VM)." He also raises some very interesting points about how patches (and entire development trees) interact.

13 of 269 comments (clear)

  1. Interesting conclusion... by NOT-2-QUICK · · Score: 3, Interesting
    The author came to the quite informed conclusion of:
    I prefer the 2.4.17 or 2.4.18pre2aa for my heavy-duty servers. The reverse-mapping patch by Rik, however, has great promise once it has stabilized. Finally, the Red Hat 2.4.9 is a very good kernel, fast and reliable.

    While I personally may not have agreed with this synopsis prior to reading the article (and am still not completely sold...), there are certainly some interesting facts and figures to ponder the next time you reload your system or update your kernel...
    --
    Beer is proof that God loves us and wants us to be happy. -- Benjamin Franklin
    1. Re:Interesting conclusion... by peripatetic_bum · · Score: 3, Interesting

      What a nice article and it seems to come at a time just then everyone is talking about "Fork this and Fork that" that in fact this is exactly what is needed in this healthy debate.

      I think perhaps that we should start having "kernel" races if you will, and we could have various categories (ie, I/O races, Stress test races) in which the various trees would compete and by-and-by the best kernel trees would become known.

      Please, I would like to hear your comments!

      --

      Sigs are dangerous coy things

    2. Re:Interesting conclusion... by Rik+van+Riel · · Score: 5, Interesting
      What a nice article and it seems to come at a time just then everyone is talking about "Fork this and Fork that" that in fact this is exactly what is needed in this healthy debate.
      Indeed, forks are (IMHO) the best way of doing development. Doing your development in the main kernel will just lead to contradictory code being integrated and the code never working quite right because it's missing fixes (guess why RH's 2.4.9 runs faster ... it does have the fixes).

      One minor nitpick though ... I never released an -rmap VM against 2.4.18-pre3, the latest is still against 2.4.17. I suspect that the crashes Moshe saw are due to some change in 2.4.18-pre3 conflicting with the -rmap VM patch, especially since rmap-11c has survived the kernel torture lab at RH. ;)

  2. [ot] So what's the best kernel to get right now? by wrinkledshirt · · Score: 4, Interesting

    Sorry for the dumb, offtopic questions.

    I'm sitting at home with my fresh install of RH 7.1 and I'm wondering what kernel to upgrade it to. Any suggestions? Is there a stable one in there somewhere that I should go with? Should I stick with the default kernel that's on their now?

    If I'm regularly compiling new programs using gcc or g++, is it safe to go from one tree to another, as long as they're all 2.4.x, or what? Do I need to recompile with a new kernel? Or is that a red herring?

    --

    --------
    Bleah! Heh heh heh... BLEAH BLEAH!!! Ha ha ha ha...

  3. Red Hat 2.4.9 is a very good kernel, fast...WHY? by srw · · Score: 4, Interesting

    Can anyone explain this? Was the stock 2.4.9 faster and more reliable than our current stable kernel? If there are stability and speed patches in the RH kernel, why haven't they been adopted in the standard kernel? How close is RHs 2.4.9 to Alan Cox's kernel? I'm assuming he has a strong influence on RHs kernel.

  4. Re:Red Hat 2.4.9 is a very good kernel, fast...WHY by Rik+van+Riel · · Score: 4, Interesting

    Thanks to Alan Cox, Red Hat (and most Linux distributions) do have the patches for my VM that Linus didn't have the time for.

  5. Stable kernel? by sitturat · · Score: 4, Interesting

    It is hard to believe that all this is going on with what is meant to be a stable kernel version, ie 2.4.x

    So far the VM has been replaced twice, and now the rmap patch is apparently going to be added despite the fact that "something is seriously messed up in the reverse-map implementation".

    Have they saved any experimental code for the 2.5.x kernels, or will that now be stable?

  6. Number of crashes in 100 days? by alexhmit01 · · Score: 3, Interesting

    It's good to see that Slashdot users still don't use computers for anything... I'm not looking for a system with better uptime than Win95, and that seems to be all you guys want.

    I can't have multiple crashes in 100 days. If you are doing real load, spend real money, get real systems.

    Don't build machines with your screw driver, get QA'd servers. Don't roll your own kernel, let Redhat test it.

    These types of tests are useful as commentary and recommendations for what people should do in the development process.

  7. Hopefully Someone Has an Answer... by jschmerge · · Score: 3, Interesting

    Since I've seen posts from at least one kernel developer in response to the attached story, I figured that this might be a good place to ask the following question:

    A little while ago, I wrote an application that uses an incredible amount of memory... A very space inefficient implementation of Eratosthenes' Sieve. In essence, what the algorithm does is cycle through the entire contents of memory sequentially many, many times (not a completely correct description). What I found with the following three kernel versions:

    • 2.4.4
    • 2.4.8
    • 2.4.17
    is that any time the program's footprint exceeded the physical ammount of available memory, performance degraded exponentially. I found this to be very suprising, considering that I was only exceeding the physical 1024 Megs of memory by less than 10 Megs. About the only difference between the three kernels I listed above is that the 2.4.17 kernel would kill of memory intensive processes a lot quicker than the other 2 versions.

    My question for the Kernel gods out there is as follows: are there any stable 2.4.x kernel releases out there that would handle this type of stress without the performance degradation that I've experienced with these kernels?

  8. Don't understand Moshe's conclusion by DaveWood · · Score: 4, Interesting

    Under the section "Allocation and Swapping Results," I assume larger numbers are higher times and therefore worse. By the numbers, 2.4.18pre2aa (the Arcangeli kernel) seems to be the fastest overall, due to the 5th run (I would consider it the common case) results. Yet Moshe says:

    "From the above figures it seems that the old van Riel VM is somewhat faster (considerably faster in the case of 2.4.9) than the new Arcangeli VM..."

    Is my math wrong? The RVR VM in 2.4.9 is ever so slightly faster on the 2nd run and slower on the 5th, and the slowest of all is the newer one in 2.4.18pre3rmap. What's my mistake?

    Moshe's politely indicating that van Riel was an ass when asked for comments; we can conclude either that Moshe didn't have a proper recent RMAP kernel to test with (as a result), or that the recent RMAP kernels are hit and miss.

    From looking at van Riel's comments here, he vehemently believes his kernel is perfect and Moshe just got it wrong... The problem is that lots of people seem to "get it wrong" with that VM, including Linus... Overall in Rik I get the sense of an aggressive person who may have trouble admitting mistakes or accepting failure; not good traits in a programmer, since it's humility and communication skills which can often be the critical factors in a team programming effort... and lack of them can cause exactly the kinds of problems we've observed.

    --
    We're on the road to Tycho.
  9. This is nearly impossible to measure by roystgnr · · Score: 3, Interesting

    If you see a Linux kernel crash, it is either hardware failure or a kernel failure. Since hardware failures (especially RAM and power supply) can be imposssible to repeat, the only way to prove that it is a kernel failure is to find the kernel bug. If you find the kernel bug, then the bug gets fixed, and suddenly your crash data is for an obsolete kernel.

    You could try to take a statistical run at it, of course, but I suspect the number of machines required to give meaningful results would be on the order of Google's farm.

  10. I thought about it some more... by nusuth · · Score: 3, Interesting
    You should do something like starting with a large J (K*J comparable to but not exceeding total memory size) and read K*J pages without any preaccessing. E.g read values at offsets N,N+K,N+2K,...,N+KJ, then continue normal processing until you reach N+KJ. Repeat procedure with new N=N+KJ. This way you hint the VM that these pages are active, and should not be swapped out. K should be selected as large as possible, not exceeding a page boundary. Too large K will make fail to mark some pages as active, too small K will consume unnecessary processing time while hinting.

    If everything goes according well, your kernel should swap out and swap in exactly M amount of memory for each preaccesing pass, where M is the amount of data that does not fit in the main memory. So if you have total memory T, total data T+M and K*J size prefetch, total swapped data per whole process would be M*(T+M)/(K*J).

    --

    Gentlemen, you can't fight in here, this is the War Room!

  11. server this, server that by paulbd · · Score: 3, Interesting

    it seems that the vast majority of commentary here all assumes that a linux machine is run as a server, or at best, some kind of generic desktop machine. while linux may be very good at running servers, and may be capable of acting as a good generic desktop machine, some of us are interested in it for much more specific tasks such as realtime audio processing, editing, synthesis and recording. we care about those extra 2 seconds spent in the VM code during a benchmark. we care about all the extra paging that goes on with some designs. we care about the internal operation of the buffer cache and how it affects attainable peak i/o performance because we stream, and when i say stream, i'm not talking about measly HTTP numbers, i'm talking about 64-128 streams of 24 or 32 bit 96khZ audio data. stop assuming that a top-end linux box is a server, please.