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.
← Back to Stories (view on slashdot.org)
← Back to Stories (view on slashdot.org)
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
Those of you who use Linux as a desktop may be interested in the pre-emptible kernel patch for 2.4.10, available from here.
This patch allows the rescheduling of in-flight kernel syscalls if a higher-priority process than the process calling the syscalls becomes eligible to run.
What it means in practice for the typical desktop user is a major enhancement to interactive performance under Linux, especially when under heavy load. Your X pointer will never freeze with this patch. Using this patch, I have played skip-free mp3's whilst my system has had a loadavg of 20, and my KDE desktop was still usable. I could never hope to achieve this with ordinary Linux. It's a really impressive bit of work. Go try it out.
Of course, people with the need for proper real-time response out of Linux (musicians, for example) will love it even more... maximum latencies for me with this patch are under 4ms - again, very impressive.
It's slated for inclusion in the mainline kernel early in 2.5, but could do with lots of testing first... you know what to do.
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
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.
Actually, that performance hit is alleviated by the fine grain security model that allows for DMA access to kernel threads. By loading additional channels for multipath sychro-byte emulation (necessary for future 64 and 128 bit systems), a parametric pseduo-attenuated curve is achieved on both framebuffer and X driven graphics. This, combined with the new temporal_io_queue() system call, allows pre-fetch of as yet uncalculated frames, resulting in a framerate on AGP devices only limited by a simple #define statement. Somewhat cryptically, Linus has chosen the value 4711 for this in his branch, while AC has chosen the more conservative 5, with the cryptic inline comment that there is an "Erisian principle to consider - see random number functions". Not being too familiar with the inner workings of the kernel, I can't comment on his choice.
--
Evan "Who feels a bit like a random poem generator" E.
"$30 for the One True Ring. $10 each additional ring!" -- JRR "Bob" Tolkien