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.

8 of 269 comments (clear)

  1. Re:Interesting conclusion... by utdpenguin · · Score: 5, Funny
    >>I think perhaps that we should start having "kernel" races



    Correct me if IM wrong, but dont races in the kernel cuase horrible security problems?? And who would decide the race conditions?

    --
    In Soviet Russia you dant have to put up with these crappy jokes
  2. Re:Red Hat 2.4.9 is a very good kernel, fast...WHY by keeg · · Score: 5, Informative

    2.4.9 was the last official kernel from linus which used Rik van Riel's VM which was introduced in 2.3.x. (The switch to Andrea Arcangelis VM occured in 2.4.9->2.4.10) Alan Cox and Red Hat used this in their kernels, and the Red Hat kernel was heavily patched with the patches from Rik van Riel which Linus "reportedly" dropped (among other things). The Red Hat kernel is also _very_ well tested, as all their kernels are. You might not like their distro, but their kernels are usually among the more stable.

  3. 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. ;)

  4. Re:Riels rmap is nice...... by Rik+van+Riel · · Score: 5, Insightful

    I am a little leary about using the rmap in prouction as of yet, it seems to be killing things each nigh, (no shit) that dont drop with 2.4.17 or 2.4.9


    Interesting. I've not managed to run into bugs like that on my computers here, so you must be running a very different workload to trigger such a bug.

    Would you have the time to help me debug this problem and is it still happening with the latest rmap VM ?

  5. Why is this funny? by megaduck · · Score: 5, Insightful

    C'mon guys. Show a little open-mindedness. One of the things I really missed from the Windows world when I switched to Linux was the "Windows Update" feature. Want to install the latest security or feature patches? Click a check box and hit "install". No dependencies, no patch conflicts, no esoteric config options, it just worked. Admittedly Ximian's Red Carpet comes close, but it's still a little quirky sometimes.

    I know there will always be those people who want to manually tweak their kernel (god bless 'em!). There's a lot of us, though, that don't want to deal with it. I'd rather have one-click shopping for all of my patch needs so that I can spend more time writing code or playing Quake. MS understands this. Apple understands this. Why doesn't the Linux community understand?

    --
    This .sig for rent.
  6. Re:Stable kernel? by Rik+van+Riel · · Score: 5, Informative
    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".

    Ummmm, -rmap is still under development. If there are any plans to put it into 2.4.x, people sure haven't told me about them. ;)))

    (and personally, I'd prefer to keep -rmap separate for quite a while more ... development is much more efficient in a fork)

  7. It's about the uptime, stupid! by Mullen · · Score: 5, Insightful

    A major problem with alot of linux admins is shown in the article. It's not about how fast your kernel is, especially when it comes to a 2 second difference in 50 seconds of computing time, but how long your machine will stay up.

    If a user compiles 35 gigs of code on a 6 processor box and it takes 5 minutes longer, he is not going to complain. If he compiles 35 gigs of code on a 6 processor box and it crashes half-way through the compile, your going to here it from your boss.

    Benchmarking kernels is plain pointless. Take a machine for each kernel, put it under real load and tell me how many times it crashes in 100 days, and I will you which kernel I want to use.

    --
    Linux O Muerte!
  8. Re:If you support forks so much... by Rik+van+Riel · · Score: 5, Informative
    Nice troll ... ;)

    My -rmap VM is a patch against marcelo's standard 2.4 kernel, because that is the thing people have. It just doesn't make sense to release patches against kernels nobody has.

    Also note that -rmap replaces pretty much all parts from the -aa VM I don't agree with, while at the same time integrating some parts from the -aa VM that I do like.