Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 


Forgot your password?
Close
typodupeerror
×
Linux Software

Byte Benchmarks Various Linux Trees 270

Posted by timothy 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.
This discussion has been archived. No new comments can be posted.

Byte Benchmarks Various Linux Trees More

Byte Benchmarks Various Linux Trees

Comments Filter:
  • of course they wouldn't actually benchmark each kernel and distro separately....too much work i guess

  • Interesting conclusion... (Score:3, Interesting)

    by NOT-2-QUICK ( 114909 ) on Monday February 04, 2002 @05:40PM (#2952349) Homepage
    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...
    • 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!

      • Re:Interesting conclusion... (Score:5, Funny)

        by utdpenguin ( 413984 ) <[moc.kcirdnek] [ta] [nhoj]> on Monday February 04, 2002 @05:53PM (#2952431) Homepage
        >>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?

        • Mmmmm, not a bad point, I see what you mean is to say that if we really put kernel tress head to head in preformance, then the developers will ingore security issues? not bad, could be. I need more data from you about that

          As for who would decide the race conditions, Im sure that woulnd tbe too hard to come up, of course the obvious downpart would be if the racers themselves choose the race conditions but i think that could be solved no?

      • Re:Interesting conclusion... (Score:5, Interesting)

        by Rik van Riel ( 4968 ) on Monday February 04, 2002 @06:00PM (#2952454) Homepage
        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 [surriel.com] 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. ;)

        • then why is your -rmap patch a diff against the -aa VM? I thought your own old VM should be superior, have you stopped believing in it? And correct me if I'm wrong, but isn't RH porting it to a more recent 2.4 kernel?

          Or is the article incorrect?

          • Re:If you support forks so much... (Score:5, Informative)

            by Rik van Riel ( 4968 ) on Monday February 04, 2002 @06:30PM (#2952583) Homepage
            Nice troll ... ;)

            My -rmap [surriel.com] 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.

            • This is not a flame, am really just curious...

              I compiled and ran the "memory hogger" application
              and it did not eat more than 424K on FreeBSD..

              I know you have a lot more to do thatn to answer silly simple questions BUT.. why is that :-D..?

              Thx in advance..
        • Phew.... a good thing that the thing performs as well as you claim it does...

          [quote]
          while Rik restricted himself to question whether the standard Linux kernel would ever even finish a stress test
          [/quote]

          Of course I'm far from serious with this remark, I'm glad to see a Dutchman "die graag zijn kop boven het maaiveld uitsteekt" (let's see how google translates that ;-).

          PS. Actually, this is a test to verify whether our average /. moderator has the sense of humor not to moderate me into oblivion. :-P

          • Re:Interesting conclusion... (Score:1, Funny)

            by Anonymous Coward
            Google doesn't translate Dutch, however InterTran gives us :

            "who willingly one's pate upstairs the mowing field uitsteekt"

            I'm guessing it kinda looses something in the translation...
      • What you are proposing is a very fascinating concept...essentially, a detailed comparison/benching of various metrics of a kernel's performance performed by an objective third party on a semi-frequent basis (at least, I believe that is where you were headed...).

        Immediately, I see a great deal of benefit that could be derived from such a venture for the common Linux user. This information could not only render which kernel is the "fastest", but could also provide information on which kernel design is best optimized for a given task. Effectively, we would have "Open Information on Open Source" (TM).

        Alternatively, however, I would never want to see this go to the extreme of a kernel tree being abandoned nor neglected as a result of these "Kernel Olympics" - variety is the spice of life, and IMHO the strength and diversity that drives Open Source!!!

    • Red Hat 2.4.9 is a very good kernel, fast...WHY? (Score:4, Interesting)

      by srw ( 38421 ) on Monday February 04, 2002 @05:51PM (#2952416) Homepage
      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.

      • Re:Red Hat 2.4.9 is a very good kernel, fast...WHY (Score:5, Informative)

        by keeg ( 541057 ) on Monday February 04, 2002 @05:59PM (#2952450)
        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.

      • Re:Red Hat 2.4.9 is a very good kernel, fast...WHY (Score:4, Interesting)

        by Rik van Riel ( 4968 ) on Monday February 04, 2002 @06:04PM (#2952476) Homepage
        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.
      • There was no stock 2.4.9 in the test; only RedHat's highly modified 2.4.9.

        RH 2.4.9 is a lot like the ac kernels. Mainly because, Alan runs that part of the RH distro. But, there are many concerns that RedHat addresses. They work with corperate customers and partners (like Oracle) to make sure the kernel they ship is as stable and fast as they can get it. So the RH kernel does diverge from the "plain" AC kernel.

        Of course they submit all their patches back to Linus. But Linus just hasn't been keeping up with them. Linux accepts patches based on three factors: his previous experience with the developer submitting the patch, the "correctness" of the patch, and the phase of the moon. And the phase of the moon is the dominant factor, because even Alan Cox complains that Linus won't accept his patches.

        So the RH kernel is excellent because Alan Cox, RedHat, and RedHat's corperate partners make sure the kernel is fully fleshed out. This is the kind of vetting that Linus doesn't do.

        "If it compiles it is Good, if it boots it is Perfect!" -Linus Torvals.
      • Is there any telling what patches are used in the Red Hat kernel releases? Or is that a trade secret? I know the source is there, but when you start talking about multiple patches, it seems like it would be a tough one to figure out.

        It seems like this may be the key source of competitive advantage for a Linux distribution vendor: the know-how to optimize the kernel and other software to make a fast, stable system.

  • Pournelle ? (Score:1, Redundant)

    by nick-less ( 307628 )
    [from the article...]
    > As Jerry Pournelle pointed

    I always though he's a sience-fiction author?

    ---

    • Re:Pournelle ? (Score:1, Offtopic)

      by netringer ( 319831 )
      I always thought he's a science-fiction author?
      He is.

      He also is(was?) the author of the "User's Column" in BYTE magazine.

      I haven't seen nor heard of him in the last decade, although I did talk to him on the phone once. (I did tech support and called him back.)
      • I haven't seen nor heard of him in the last decade

        He's still writing - good classic Science Fiction, and still writing Chaos Manor, his collumn for Byte. He's also got a site that is similar to Slashdot in "umm... vaguely geeky stuff, lots of visitor feedback and opinionated as hell". It is located (in all its hellishly difficult to navigate, 'spend a few hours finding the good stuff buried deeply' glory) here [jerrypournelle.com].

        --
        Evan "Many many years spent with Byte" E.

    • Pournelle is a science fiction writer and also a computer columnist for Byte magazine (byte.com now). I think his original degree was in political science (!) but somewhere he learned quite a lot about engineering, and he did the original (DOS/BASIC) programming for his wife's learning to read program. I assume his computer skills are self-taught -- he's got to be at least 60 and there were no programming classes when he was young. He wrote political columns for Intellectual Capital a few years ago, when that website was worth looking at. In the 60's he was something in NASA management -- and also he appeared at least once on national TV in a debate about the Vietnam War.
      • Not a lot of info, but in one of his BYTE columns, he talked about getting free time on an old Honeywell or IBM mainframe and that is where he learned to program.

  • [ot] So what's the best kernel to get right now? (Score:4, Interesting)

    by wrinkledshirt ( 228541 ) on Monday February 04, 2002 @05:44PM (#2952373) Homepage
    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?

    • Re:[ot] So what's the best kernel to get right now (Score:4, Informative)

      by JediTrainer ( 314273 ) on Monday February 04, 2002 @06:19PM (#2952537)
      If you're using a fresh install, stop now.

      You should use RH 7.2 instead. It comes with kernel 2.4.7 or something, but can (and should) be upgraded to RedHat's kernel 2.4.9 via up2date. The RedHat kernel is quite stable and fast.
    • I'll probably get flamed for this - but I installed 2.4.17 from Red Hat's Rawhide distro (find it on rmpfind.net) and it worked like a champ.

      rpm -Uvh kernel-2.4.17-athlon.rpm or whatever it was and rebooted. I'm sure everyone will chime in on how 'evil' it is to install a kernel by rpm, but for my typical desktop box, it's no big deal.

      I think you'd need to get the new modutils package, but i don't recall.
    • 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?


      The current kernel supported by Red Hat for Red Hat Linux 7.1 is 2.4.9-21, which you can see does a good job in this test.

    • The linux-2.4.17 kernel rocks the world. I have had not a single problem since compiling and installing it AND I've also had more things begin working.

      Before 2.4.17, I couldn't get sound to work with Return to Castle Wolfenstein... trying to run the game with sound would just put the machine into a probable race state... I'd try to run a program and it would just hang... switch to another virt term login run top and hang...

      I'd have to restart the machine because I couldn't even kill the processes. But with 2.4.17, NO MORE PROBLEMS.

      Me is a happy camper.

  • The folly of Open Source (Score:1, Flamebait)

    by Anonymous Coward
    Open Source has shown itself to be an effective strategy for the implementation of small to medium sized projects. Many eyes, blah blah blah, and the project leader makes the final decision on what goes in. It's very cool.

    However, as was discussed on /. before, when projects pass the "medium sized" mark, the effectiveness of having such an open system becomes self-defeating. It's simply a case of too many people having too many different ideas about the direction the project should take.

    With closed source, a single person can make all the final decisions about what will make it into the final release, but Open Source has no such system. A person who feels that his ideas are not being taken seriously can fork the project and create his own possibly incompatible tree. This seems to be what is happening now with Linux.

    At the early stages of tree forking, there is usually little problem. Most of the forks coexist with each other peacefully with only minor manual tweaking to fix any conflicts. Over time, though, further development along one of the forks will inherently diverge further from the root tree.

    The argument that good patches will make it back into the root tree, thus preventing fairly deep splitting, is fallacious. Many of the reasons for forking are precisely because the root project refuses to take a fix from a contributor. What happens afterwards is that users will get 'locked into' a particular strain of the project and will be unable to incorporate other good features that are present in other strains which, for whatever reason, can't be merged into their chosen strain.

    Kernel hacking just isn't as fun as it used to be. :-(

    • Do you think the BSD projects reflect this? (Score:4, Insightful)

      by twilight30 ( 84644 ) on Monday February 04, 2002 @06:27PM (#2952567) Homepage
      I take your points about forking, but as a counter-example I'd think about the BSDs instead. They all operate under the same license, all forks from roughly the same code base.

      The advantage here is that with three BSDs you have three separately-tuned operating systems that attack different problems very well, yet maintain a certain level of commonality and compatibility.

      Call me a starry-eyed optimist, but my exposure to this open source fad started with the Wired article in the autumn of 1997. In it the writer painted a picture of a 'computing epic', one collectively started and maintained. I still think that metaphor is accurate and useful.
    • I don't think this is a bad thing, really. People have conflicted ideas so two forks form. Each fork is evaluated in the eyes of the hardcore users and in the eyes of distributors such as RedHat. Sure, we look now and think that things will get ugly as all these trees evolve, but as the past has shown, the trees that work better, or are closer to the pre-exsiting "standard" given a tie, dominate and often extinguishes less succeful trees whose ideas didn't pan out, usually folding in the improvements the other tree made succcessful.

      The process of having these trees sprout up and played with by businesses and advanced users provide a sort of natural selection for improved evolution of the system. While all this complicated mess plays itself out among the bleeding edge people, the common users have the stock redhat or what have you kernel to play it safe with.
      • Conflicting ideas are not the only cause of a fork. Conflicting needs can make a strong argument for forking. The various realtime forks are a prime example here.

        Keeping the realtime code in the main code tree would be counter productive -- confusing the development of the larger Linux tree, but not providing much of anything to the 98% of us who have little need for hard realtime in our systems.

    • Most of the 'forks' seem to actually be marshalling grounds for maintainers to prove the reliability of their work to the kernel community in general. Once things gain some faith in the community and in Linus' head, they get incorporated in the main tree. The process needs work, but it has gotten the community this far ...

      Can you provide some high profile forking examples that have occured in the recent history of Open Source, out of interest? Or evidence of similar forks in Linux. Not, to coin a phrase(?), "soft forks" as I have mentioned here, but "hard forks". Fundemental changes in ideology or personality clashes that have seriously caused a split in the community?

      • And they all forked from THE Original Berkeley Software Distribution, didn't they?

  • hmm (Score:1, Funny)

    by Zanek ( 546281 )
    I'm waiting for a standardized procedure to allow downloads of the latest updates and patches,ie: just like MS.

    • Re:hmm (Score:3, Informative)

      by DeadeyeFlint ( 38220 )
      If you have RedHat use up2date, with Debian use apt-get.

    • Why is this funny? (Score:5, Insightful)

      by megaduck ( 250895 ) <dvarvel AT hotmail DOT com> on Monday February 04, 2002 @06:11PM (#2952511) Journal

      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?

      • Some of us do understand. I've got apt-get update and upgrade in my crontab, which emails the results to me every night at 12:00am.

        That means 'Aunt Tilly' never even has to even update her box, ever.

        Granted the typical 'desktop user' wouldn't know how to do this ... but it is possible to do - maybe an install time option for this would work.
      • > Want to install the latest security or feature patches? Click a check box and hit "install".

        That's bullshit. Latest security patches find their way to windows update several days, if not weeks, after their initial release. Windows Update is great service but unfortunately Microsoft uses it mainly for distributing the latest version of IE/MP/Messenger. I'm sure that one of the factors causing long delays is that I don't use an english language version of Windows, but my friedns who do say it isn't much better. I hope to see more security patches in Windows Update now that Microsoft has promised to take the matter seriously, we'll see how it goes.

        And before anyone says this is just FUD from a linux fanboy let me say that the only OS in my PC is Windows 2000 and I have no plans to change that.

      • Re:Why is this funny? (Score:2, Interesting)

        by DrSkwid ( 118965 )
        debian has it

        freebsd has it

        in fact both of those also upgrade third party software that's not part of the OS

        windows update will never upgrade mozilla for you or KDE whereas apt-update & cvsup-portsupgrade upgrade EVERYTHING you've installed (if installed via apt-get or /usr/ports)

        [my understanding of the debian process is through the grapevine so if I'm off the mark, be cool; not a fool]

      • Re:Why is this funny? (Score:2, Interesting)

        by Pastis ( 145655 )
        Let's compare Windows update with another typical Linux update.

        1. Windows 2000

        2. I installed windows 2000 on my new Inspiron 8100 yesterday. And I used the so cool 'Windows update' function.
          Note that it requires to use IE (No IE, no windows update? At least the help doesn't describe any command line method.)
          • First I installed the OS (one reboot - pretty normal)
          • Then I installed Service Pack 2 (another one)
          • Then a group of security fixes (reboot)
          • Then another (missing ???) security fix (reboot)
          • Then IE 6 (reboot)
          • Then a new security fix, probably for IE6 (reboot)
          • Then DirectX 8.1 (reboot)
          • Then new drivers (reboot)
          • I also modified the fonts to large fonts: reboot.

          Until I had the drivers installed, everything was done with IE 5.0, in 640x480 mode, and (I think) 8 bits; so ugly!
          And if you do that from home on a modem, you have to restart your connection at every reboot. That's optimum.
          And when this is finished, you can now start installing non-windows applications!

          I forgot to mention that the first time I installed windows 2000 on a logical partition, is wasn't able to boot it after I installed Linux. Impossible to repair as my disk was not detected correctly.
          [Perhaps because w2k doesn't support DMA 100.
          When I face this kind of problems I am pretty happy to be able to recompile a new kernel.]

          I completely reinstalled it on a new Primary partition and, after I installed the drivers, I had a crash (blue screen) during reboot. [Note I was updating the win modem driver while using it to download the driver from the web]. Anyway, it was impossible to restart (crashing even in FailSafe mode or with 'last known good configuration'), and impossible to repair even with an up-to-date ERD. Had to restart the install from scratch for the third time! Damn!

        3. Debian 3.0


        4. On the other hand, I have installed Debian 3.0 (aka testing) from floppies on the same machine. I rebooted once during install, and then another once again after I installed and tweaked the new kernel.
          Of course, you are not obliged to compile the kernel. I bet that if you use Mandrake or Red Hat, you will have a pretty good hardware detection process. I just like Debian and like to tweak the kernel.
          I did everything on the command line. Didn't have to have a full graphical installation (I don't like too much laptop built-in mouses).


        To summarize:
        Windows: requires graphical environment and a mouse to install correctly plus requires having at least 9 non-necessary reboots (with modem disconnections /reconnections)to have an up-to-date system. Don't mention the un-repairable crash and the non-recognized partitions...

        Debian GNU/Linux: two reboots (one optional). All in command line, with a 15 seconds boot. No problem. There are perhaps GUI front-end to apt, but I do not need them. Can something be simpler than 'apt-get upgrade'?

        I let you decide who is the easier and who is my winner.

        So to come back to the subject of the thread: download kernel and patches.
        • Note that windows update only updates your Windows stuff, none of your other applications. (and without applications and OS is nothing, right?)
        • Note that possible dependencies problem may arise after you upgrade non-Windows applications.
        • Note that you can automate the install of the updates on Linux (cron the apt-get command). That's even better than on windows, where you can only be warned that you need to update your system.



          • I could go on...

  • Riels rmap is nice...... (Score:3, Informative)

    by CDWert ( 450988 ) on Monday February 04, 2002 @05:57PM (#2952446) Homepage
    The rmap patch is nice.....

    It makes a big difference on loading the hell out of my woefully under memoried workstation at work. My home machine, used mostly for surfing has seen a dramatic imporvment in free memory and is no longer swappin , it has 512 meg, so it really shouldnt swap too much, but was constantly with the stock redhat kernel, as well as 2.4.17 plain vanilla, trhe 2.4.18 -rpma12a has been ROCK solid.

    On my server however with 256 megs , the stock redhat roll has done nicley with the minimal load its under.

    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

    I would like to see an option at configure to select a VM, I think the preemptive added would be fun too, I know its a pain because of the way it all intergrates to the other code, but thats my desire, it seems to be alot of other peoples desire as well, its funny how I bitched and moaned about the Riel VM , that was in the kernel prior to AA's , but since then and all the patching that was done I think Riels would give it a run for its money .....

    • Re:Riels rmap is nice...... (Score:5, Insightful)

      by Rik van Riel ( 4968 ) on Monday February 04, 2002 @06:09PM (#2952498) Homepage

      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 [surriel.com] ?

  • Stable kernel? (Score:4, Interesting)

    by sitturat ( 550687 ) on Monday February 04, 2002 @06:07PM (#2952488) Homepage
    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?

    • Re:Stable kernel? (Score:5, Informative)

      by Rik van Riel ( 4968 ) on Monday February 04, 2002 @06:14PM (#2952522) Homepage
      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)

    • "Stable" doesn't necessarily mean what you think. It refers to the APIs. All releases in 2.4 are supposed to be compatible, but 2.5 is allowed to do things that break code between versions.

      Now, by keeping the interfaces stable, they usually make the kernels more stable (in the uptime sense) as well, but that's not exactly the goal.

      If you blindly upgrade to the latest kernel, you will be bitten. It'd be like grabbing Mozilla nightlies, or if MS released IE nightly builds, or whatever. There will be a few stinkers.

      Frankly, if you're the type to complain when a kernel is buggy instead of sending in bug reports, you probably should be at least two full releases behind the latest. (When 2.4.17 comes out, upgrade to 2.4.15) The exception being when there's been a big hole found in a line of kernels. And if you need the stability, consider downgrading to the kernel before the problem one instead of upgrading to a less-tested one.

  • Why use an unstable patch? (Score:3, Informative)

    by Hagmonk ( 201689 ) <lukeNO@SPAMburton.echidna.id.au> on Monday February 04, 2002 @06:09PM (#2952497) Homepage
    Most of those 'forks' are going to be maintained by kernel hackers to marshall patches for eventual inclusion in Linus' tree. I wouldn't put them anywhere near a production server.

    There are various patches like the Robert Love's [tech9.net] preempt patch which might be considered production quality. And perhaps some collections of production quality patches exist out there. But I wouldn't say -ac or -dj are in that category.

    Or any of the patches marked 'preXYZ'. They're 'pre' for a reason you know. I'd be thrashing them on test servers, then giving feedback to the maintainer of that series. Let the maintainer declare them stable first.

    You'll find in environments ambivalent to Linux that you really need to prove its stability to management first. Trying a new whiz bang kernel can have unforeseen side effects, in meetings that you'll never be invited to; and whose outcome you will only learn when it's too late to change it. "We let Bill convert server X to Linux and then it corrupted the filesystem. Clearly Linux carries more business risk than expected."

  • Seems that 2.4.18pre3aa has some really good perfs, anyone tried? What are the main differences with Linus tree?

  • It's about the uptime, stupid! (Score:5, Insightful)

    by Mullen ( 14656 ) on Monday February 04, 2002 @06:21PM (#2952545)
    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.
    • 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.
    • Why would I want to play Quake at a measily 60 fps for 2 years straight, when I can play it for at most 1 hour at a blazing 61 fps? :)
    • 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.
  • I think Rik's discovered a good new way to karma-whore.

    1. Write a VM.
    2. Get a fine article written about your work
    3. Have somebody post the article on /.
    4. Post. Post. Post.

    Rik's put in at least 3 comments in this tree and they're all being mod'ed up.

    I'd better start on my own VM!

    (Or, I'll write a reverse disk-sector mapper)

  • Hopefully Someone Has an Answer... (Score:3, Interesting)

    by jschmerge ( 228731 ) on Monday February 04, 2002 @06:58PM (#2952681)

    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 [utm.edu]. 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?

    • While I'm not a kernel hacker, I think I know why this happens.

      As soon as you fill up physical memory, you're using swap space. The kernel will either swap other programs to disk to make room for yours, or it will swap parts of yours out that aren't being used. Either way, disk i/o is very expensive - hence the performance decrease. No kernel can help that, really. Once you're out of memory, you're out.

      • I'm sorry that I wasn't clearer in the original post... With all three kernel versions, what I experienced was not only performance degradation, but a change in runtimes from about 15 minutes to over 8 hours. Unfortunately, I never managed to really quantify times or run a thorough set of benchmarks, but it seems that such a drastic difference in runtimes would imply that the VM's in all of these kernels are not handling a worst-case scenario correctly.

        • You generally don't optimize for the worst case... I'd wager that a single process requiring all physical RAM and then some is a rare occurrence.

          Besides, think about the access time differences between RAM and your hard drive... you're going from a few nanoseconds to a few milliseconds; that's a thousand times slower. Your test went from 15 minutes to 480 minutes, which is only an increase of a factor of 32. That means it was talking to swap what, 30% of the time?

          I'm not entirely sure how the math breaks down here, exactly, but it really doesn't seem too bad considering the OS itself (and anything else you might have had running) was taking up some of that physical RAM, too.

    • A suggestion (Score:1, Offtopic)

      by nusuth ( 520833 )
      I can't answer the kernel related part of your question, however a possible workaround is forcing future reads from active pages by preaccessing them. E.g, before starting on processing [N,N+K) cluster, read value(s) of N+K, N+2K, N+3K up to N+JK and write them back. For a suitable K,J pair, you should experience linear performance drop. A K=8000 and J=1 sounds reasonable to me.

      &ltspeculation> AFAIK kernel uses a hairy buddy system (but I did not check that myself), if that is the case, not whole memory is accessible in an arbitrary allocation sequence. So your analysis of exceeding 1024Megs of memory by less than 10 Megs is incorrect. You have to allocate progressively smaller page sizes that follow fibinocci(sp) series (or something like that, see your local kernel hacker for more info) if you want whole your data in memory. &lt/Speculation>

      • 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).

    • If you're using a program that cycles through all available memory + 10Mb, of COURSE it will be slow! The VM can't squeeze 1044 Mb of data in 1024 Mb of RAM, no matter what ugly hacks it uses, and as soon as it needs more memory than it has, it has to hit the disk. As soon as you start hitting the disk, you get horrible performance decreases because your program is stalled until the data can be read from disk (which is orders of magnitude slower than RAM).

      The reason VMs usually work well is because most programs don't actively use all the memory they allocate at once, so the VM swaps out the memory that isn't being used. If your program uses all the memory it allocates, the VM has no choice but to use the slow disk to store some of it. No magic VM will solve your troubles.

    • Walking repeatedly and sequentially over All Memory + K tends to result in worse case performance. The reason is that when you hit the +K at the end of the loop you page out the oldest memory, which is the K at the beginning of the sequence. When you restart at the beginning you need to get this back in, so it pages out the next oldest K, which is of course the next part of the sequence. Thus you end up paging in and out the whole 1GB on each iteration, resulting in a massive slowdown.

      (The real answer is less simplistic, but this is close enough to the truth.)

  • Don't understand Moshe's conclusion (Score:4, Interesting)

    by DaveWood ( 101146 ) on Monday February 04, 2002 @07:01PM (#2952693) Homepage
    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.

    • Re:Don't understand Moshe's conclusion (Score:3, Insightful)

      by Anonymous Coward
      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.

      ehh... when i think "top rank" open-source programmer, I think: Theo de Raadt (his early work on netbsd/sun alone is brilliance), RMS (GCC, emacs, etc), Jordan Hubbard (of FreeBSD fame), Linus Torvalds, Alan Cox, etc.

      Of that group, Only Jordan and Alan strike me as having "humility and communications skills." Linus is often curt, sometimes cordial, and sometimes very rude. Theo is almost always rude. One look at RMS' TCL outburst and 'communications skills' obviously don't belong in the same sentance with that guy. I'm not trying to troll or flame here, I'm just saying that expecting open source (or Free Software, whatever floats your boat) programmers who run insanely popular projects and who get treated like gods whenever they show up in Slashdot (ooh.. it's Alan, +5 - not that he doesn't usually deserve it), at a Con, or on IRC or something... expecting these guys to have normal-sized human egos is asking a lot. It's clearly asking too much of most of them.

      also please note that i'm not slotting rick in next to AC, Linus and John... yet. Just making a comparison.
    • vehemently??

      come on... the guy takes pride in his work, enjoys working creatively in the linux kernel code. he not believe his kernel is perfect (why would he conclude the rmap is still under development?). how about a little love? you know a show of hands for AA, RVR, Alan, hell even Linus. they spend their time writing, developing, arguing over a linux kernel so i can have a choice in the OS i put on my machine. so i can spend my time developing wannabe c++ applications for KDE. thanks guys for the work and dedication.

  • why didn't author measure page faults? (Score:4, Informative)

    by brer_rabbit ( 195413 ) on Monday February 04, 2002 @07:46PM (#2952863) Journal
    I've asked this before when people do benchmarks and I'll post it again: why don't these authors measure page faults? Measuring the total time the process runs is good, but if you can measure how many page faults occured you'd be providing a lot more infomation.

    So how do you measure page faults? Be sure your kernel is configured with "BSD process accounting". Then use a shell like tcsh. The man page of tcsh describes the "time" variable, you can set it to report the number of major/minor page faults that occured during the lifetime of the process.

    I did my own unscientific test back in November. I ran 32 simultaneous instances of mpg123 on a just-booted machine. Among other things I measured the number of page faults. The results for the then-current kernels I had were:

    kernel: 2.2.20 2.4.8 2.4.12

    mean elapsed time: 88.6 86.5 88.4
    mean page faults: 7833 7285 8990

    those number are the means of the 32 values from each process. Anyway, you get the idea.

  • The raw performance of the VM is certainly important and all, but what I'd like to see are some *application* benchmarks among the various kernel trees. Star Office, the window managers, KDE, GNOME, etc. Graphics. Storage. Networking. Unles we're talking heavy metal servers running the usual suspect daemons the average user doesn't really give a hoot if the VM is well-designed or not - only if The Gimp runs quickly enough.

  • Kernel Test Suites Article (Score:4, Informative)

    by goingware ( 85213 ) on Monday February 04, 2002 @09:00PM (#2953155) Homepage
    Some of the test suites in Using Test Suites to Validate the Linux Kernel [sunsite.dk] might be good for benchmarking.

    Yes, I post the link to this here all the time, I think it's useful to people.

  • Rik van Riel Chat (Score:4, Funny)

    by sfrenchie ( 524076 ) on Monday February 04, 2002 @09:17PM (#2953196) Homepage
    Wow! Reading this story at +5 is like seeing Rik van Riel have a conversation with himself!
    • talk about whoring...

      He's the fucking pimp.

      50 karma in a single story.
      • Grow up you fking teenaged dipshits.

        You've got one of the leading mojo's in Linux Kernel development prettymuch being interviewed by "the people" here and answering Q's etc, and you decide to lambast him as a "whore" because people are actually interested in what he has to say. Note that Linus, RMS , ERS , A-Cox or any of them pretty much have never(as far as I remember) have shown up in here, so that's a pretty nifty thing IMHO

        And for christ sake, promoting interesting responses what Karma is for you idiots. (and Karma cap stops it going nuts). Get a life.
  • In the context of evolution Torvalds represents natural selection, and kernel developers changing the code represent mutation, albeit a poor representation because the developers have some sense and purpose in what they do, while mutation "in nature" has absolutely none.

    I have to disagree with the notion that this isn't Exactly how evolution occurs. Evolution isn't Random, Virus are the vector for almost all radical natural genetic manipulation. The purpouse of a virus is to use the resources of a host organism to replicate it's DNA sequences because Virus are too small to replicate themselves. In doing so It injects it's DNA inside a host cell and basically exploits the RNA strands inside to replicate it's own DNA. While doing this The virus can in fanct find new DNA within the host and borrow it for it's own protection. In many cases this is to make it resistant to antibodies produced by the body (HIV.) Now, not all Virus destroy the host cell especially when antibodies destroy it before it can complete it's task. In some instances the Virus may act as a Vecor Borrowing the DNA from one species, and inserting that code in another. Many virus can cross infect species. For example humans and pigs can catch influenza from each other. Geese and pigs can also catch influenza from each other, while humans and geese cannot infect each other with influenza.
    Virus are acting for thier own self promotion and preservation. When a DNA stand from one species makes that species less able to destroy them they would try to splice that DNA into as many species as they can. Comparing that to kernel developers
    is pretty straight forward. They try to 'infect' the kernel tree with the 'code' they've produced for any number of reasons. Being known for coding on linux, to get promotions at a linux friendly workplace, for the challenge and fun of contributing to the linux kernel, or just to fix something so that they can do something with linux that they were trying to do but couldn't.
    This introduces variation along the same analog as virus changed DNA. As for 'uncorrected errors' in the DNA strand the only thing we can prove comes from that is cancer. Thus that type of 'mutation' is analog to 'bugs' in the code of the linux kernel. Unfortunately humans aren't anywhere near as good as the roughly 99.7% error correction rate of replicating double helix DNA strands, so code tends to get a lot more malignant tumors (root exploits) to cut out.

  • server this, server that (Score:3, Interesting)

    by paulbd ( 118132 ) on Monday February 04, 2002 @10:22PM (#2953356) Homepage
    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.

  • picking nits (Score:3, Insightful)

    by darkonc ( 47285 ) <stephen_samuel AT bcgreen DOT com> on Tuesday February 05, 2002 @12:03AM (#2953592) Homepage Journal
    As a reader from Australia noted in an e-mail to me, "evolution is by definition an undirected process with natural selection." You might, however, argue that there is undoubtedly some direction in the Linux kernel development. ....

    I'm going to disagree with this notion of evolution. Evolution is not undirected. The current environment gives a good deal of direction to the sorts of evolution that occurs. For example: evolution appropriate to tropical beaches is unlikely to occur in the arctic tundra.

    Similarly, Evolution in the Linux world is also mostly in reaction to environmental needs. Where the difference in randomness comes is that the mutations that lead to biological evolution are generally random in nature -- but environment and statistics choose which mutations lead to enhanced viability.

    For Linux, patches are generally in direct response to specific needs. The nature of these changes are directed by nature but generally random in form -- ranging from the icky to the elegant. Fork maintainers like Torvalds and Cox are more like the social interactions which can shift the survivability of an otherwise brilliant mutation/patch. Although this social rejectin will deeply affect survivability, an especially bright change can still give a survivabillity edge that makes up for the rejection

    This is really the pleasant aspect of the Linux community; exactly those people who are busy and sought after by many journalists and hackers are also those who take time to answer questions with enthusiasm and a very positive attitude. Thank you Andrea, thank you Alan.

    This is something of a chicken and egg proposition. Those people "who take time to answer questions with enthusiasm and a very positive attitude" are precisely those who will likely be sought out by Journalists and others. I mean -- come on! Are you going to take your question to someone who regularly beats into submission anybody who comes to them with (what they consider) a non-profound queston?

    Journalists, especially often need their question answered today , and can't be bothered to wait for someone who berates them for half an hour for asking a straightforward question -- especially if they then forget what the origina question was (no known anectdote comes to my mind).

    • Linux "evolution" is thus a combination of Darwinian and Lamarckian. (Lamarck thought that acquired traits would be inherited -- that is, a giraffe's neck was long because its ancestors had stretched to reach high-up leaves. Darwin postulated natural selection of random variations -- that is, the tallest proto-giraffes got the most leaves and were more likely to survive, so the next generation was taller and the tallest of them survived better, etc. In biology, natural selection is so well established as to be basically a _fact_. Lamarckism is discredited; it was a nice idea, but now that we know about DNA there is no way the length of the neck could change the DNA in the gonads, and a long time ago some lab experiments seeming to show Lamarkian inheritance were proven fraudulent.)

Slashdot Top Deals

The rule on staying alive as a program manager is to give 'em a number or give 'em a date, but never give 'em both at once.

Close