Slashdot Mirror

← Back to Stories (view on slashdot.org)

Linux Kernel Performance How Will 2.6 Measure Up?

Posted by Hemos on from the time-for-the-blowhards-to-weigh-in dept.

An anonymous reader writes "This story offers some interesting performance comparisons between the latest stable Linux kernels (2.4.x) and the latest development Linux kernels (2.5.x), comparing performance on both a single processor and dual processors. These numbers help validate that the upcoming 2.6 kernel will outperform the current 2.4 kernel, at least in some instances..."

6 of 177 comments (clear)

  1. Compile time speedups by IamTheRealMike · · Score: 5, Interesting
    The thing I'm most looking forward to is the better scheduling under heavy disk load. This'll hopefully make Linux a lot more responsive when compiling software, at the moment my machine can get bogged down and jerky when doing this.

    Of course, the real solution would be to not need to compile software (plug plug :)

    1. Re:Compile time speedups by pkplex · · Score: 4, Interesting

      Yep.

      I first tried FreeBSD about a month ago, and thats exactly what I noticed about FreeBSD. Smooooooooth.

      For example in Linux ( 2.2.x and 2.4.18+ ) I found that when something demanding was going on ( like building mozilla, kernel, or such like ), all X11 became all choppy ( Mouse stuttered, typing lagged in bursts ).

      Not so with FreeBSD. Many times ive had GnomeICQ hit a bug and use 100% cpu, but I was unaware of this until days later when looking at top.

      A few days ago I installed FreeBSD onto my p100, with 64Mb of ram. Playing around, I ran many many dnetc's by having thousands of 'nohup ./dnetc &' lines in a file and executing it.

      At a load of 350 the p100 box was still very happy to do what I told it, and with very suprising responsivness. However, once the load got up to 450, my ssh connection to the box was terminated, and I had to restart sshd locally. Which is fair enough, I guess.. one will run out of swap and ram sooner or a later.

      I can recall doing this same dnetc thiwith slackware, running 2.4.something, and after a short while at load 50, I started getting seg faults every time I ran a command.

      Untill Linux shurgs off huge loads effortlessly and in a stable manner like FreeBSD does, its not going to live in my boxen :)

      Tux needs to get fit and learn how to balance on one leg properly :)

  2. Quick question by Anonymous Coward · · Score: 5, Interesting

    What is the weakest specced machine that anyone here is getting productive/useful work with Linux done on? Do people use Linux on 468s at 12mhz? P75s? Just curious.

  3. It may be faster... by cperciva · · Score: 4, Interesting

    but will it corrupt my filesystem?

    Performance is important, certainly, but I think some people (*cough* overclockers *cough*) assign it a bit too much importance.

    --
    Tarsnap: Online backups for the truly paranoid
  4. BSD? by pkplex · · Score: 4, Interesting

    I wonder how well it compares to the BSD kernels, in both performance and stability?

  5. People in glasshouses shouldn't throw stones by marm · · Score: 5, Interesting

    Amazing, I've been running FreeBSD since 2.8 and I've never had an unresponsive system even while doing a build world; I guess the 2.4 kernel is alot worse than imagined.

    This is, by and large, the fault of the scheduler, largely unchanged in 10 years and described by Linus, even whilst he wrote it, as a 'hack'. However, it worked, and Linus, being the extremely sensible and conservative maintainer that he is, kept it until recently - process schedulers are difficult things to get right, and their performance is crucial to the performance of the kernel as a whole. Not to mention that for the tasks that Linux has been used for historically, primarily low-volume server tasks on low-end hardware, it isn't really a bottleneck.

    Still, the scheduler has been gutted and rewritten for 2.6 by Ingo Molnar - the now somewhat-famous O(1) scheduler, which performs much more fairly under load, and dispenses with almost all of the strange pauses and scheduling glitches under load. Current vendor kernels based on 2.4 (Red Hat's and SuSE's at least, I think) have had the O(1) scheduler backported to them as well. In fact, if you're running near enough any current 2.4 kernel other than mainline, you get the O(1) scheduler and your share of scheduling fairness.

    The new scheduler is also a fundamental basis for Linux 2.6's new NPTL 1:1 threading, which has so far proved spectacularly (record-breakingly?) fast. Hmm, on second thoughts, perhaps I probably shouldn't mention threads and FreeBSD in the same post. I mean, isn't this the same FreeBSD that's still waiting for a single half-decent pthread implementation? Oh well, better hope 5.0 is out soon...