Slashdot Mirror

← Back to Stories (view on slashdot.org)

Linux Kernel 2.4.10

Posted by CmdrTaco on from the download-compile-reboot-repeat dept.

erinntriggs writes "Kernel 2.4.10 is out and available at the usual places." You know the drill people! Time to make bzImage and wreck those glorious uptimes.

4 of 403 comments (clear)

  1. don't waste bandwidth by Ender+Ryan · · Score: 5, Informative
    And remember folks, don't waste precious bandwidth, download patches!

    patch-2.4.7
    patch-2.4.8
    patch-2.4.9
    patch-2.4.10

    Links for the lazy folks ; )

    --
    Sticking feathers up your butt does not make you a chicken - Tyler Durden
  2. Re:So... how's the VM these days? by Jeffrey+Baker · · Score: 4, Informative
    Well, AA contributed an enormous VM patch that basically changes the whole system. Apparently it has good effect for interactive uses like MP3 players and web browsing, but testers at HP labs say that the performance of the 2.4.10 VM is the worst of the (very bad already) 2.4.x series on their 4-8 GB machines with 30+ SCSI devices each. They make this conclusion based on NFS benchmarks.

    On my machines, I've had tons of problems, and 2.4.10-preXX didn't make them go away. Until Linux drops the concept of memory overcommit, I'm afraid that the VM is going to continue to suck.

  3. I'd put my money on tomorrow... by Ami+Ganguli · · Score: 5, Informative

    Well, I wouldn't be a lot of money, but I think if the VM on 2.4.10 looks good then 2.5 will start very soon. Linus has been hinting at it for ages, but I don't think he wants to pass 2.4.x on to Alan until it's up to standard.

    On the positive site, it looks like there's a ton of stuff ready to go into 2.5. This will be the first development kernel where the big boys (especially IBM, but also Compaq and SGI) have been involved from the beginning. They all started on projects during 2.3 that never made it into 2.4, but are now pretty much ready. The quiet time between 2.4.0 and 2.5.0 has also given a lot of other patches time to mature. It'll be interesting to see what happens.

    --
    It is tempting, if the only tool you have is a hammer, to treat everything as if it were a nail. - Abraham Maslow
  4. There may be no downside by marm · · Score: 5, Informative

    Basically, why is this not the default behavior?

    Well, the traditional view on this is that reducing latency by whatever means tends to lower overall data throughput, which is just what you don't want for a server OS, which is still what accounts for most Linux installations.

    However, it may be that the traditional view is wrong. It may well be that the increased usage efficiency that comes with kernel pre-emption may actually increase throughput - high-priority disk I/O for instance now never has to sit waiting for the CPU to complete a syscall. There were some interesting results posted linux-kernel regarding this, see here.

    The linux scheduler ensures that no process is ever completely starved of CPU time, so no huge backlog of syscalls ever builds up.

    The other reason that it's not the default behaviour is that it's an interesting and new approach to how to achieve a pre-emptible kernel. All other pre-emptible kernels have been designed as such from the ground up - Linux certainly hasn't. There are a couple of white papers, here and here from MontaVista (who kickstarted the pre-emptible kernel project) about the approach taken. They also detail a few other approaches to making Linux more responsive for real-time and interactive tasks.