Slashdot Mirror


Linux Kernel 2.4.10

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.

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