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)
I ask as a swap-laden 2.4.7 user...
Napster-to-go says "Fill and refill your compatible MP3 player", which is a lie. It's not MP3. It's WMA with DRM.
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
This is rubbish. The reason that Linux 2.4.x systems get into swap when running XMMS is because they read from the disk a lot, and they only need the page they read once. Consider an XMMS process that reads 4GB of MP3 from the disk over the course of a day. Well, Rik's VM is going to push *all* other processes out of memory in order to cache all of those disk pages that nobody ever wants to see again. Obviously this is the wrong policy. But, Rik the megalomaniac is never going to fix it because he's convinced that his system is the best thing that can be acheived by human beings. He should get together and have a beer with Hans Reiser.
My System:
Redhat 7.1
X 4.0.2
Hardware IBM ThinkPAD A21p PIII 850/512MB
1) Graphics performance for my M3 ATI processor in my IBM Thinkpad has quite frankly increased a great deal. This is way obvious do to the rapid spinning of my OpenGL plugin for XMMS.
MESA demo's show a 23% speed improvement. Especially tunnels mesa demo frame rate.
VWARE shows a drastic improvement in sound processing ability on my thinkPAD when I use 2.4.10. I am not sure why, 2.4.8 was a good improvement but 2.4.10 is even better.
(Gotta have my ArtBell...)
2) Virtual memory now shrinks its pool considerably when free memory is used up and you start to quit processes.
I loaded Oracle 8.1.7, VMWARE 2.0, Forte' , Bugseeker, and my website up, and MySQL. I was short 170 Megabytes of memory and the virtual swap space handled it very well.
Wasn't slow at all, at least too me. I then logged out and quit all my apps after running some non trivial tests.
I did notice my SWAP shrunk from 170 to 30MB when I logged out and shut everything out.
This is very good, I haven't tested whether or not the kernel will kill a process that takes all memory and is obnoxious about memory, without killing the machine. I would like this feature as normally Linux will just die.3) Startup time was faster by 5 seconds with no changes. I am not sure why, probably do to the memory management fixes.
My use of VMWARE suggests some rather dedicated speed improvments to the basic software.
If you have 2.4.8, you have little reason and everything to gain by upgrading to 2.4.10.
Speed, more effective VM, and graphics are improved noticably.
I highly recommend you upgrade.
-hack
Got Geometrodynamics? Awe, too hard to figure out? Too bad.