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)
Some of the mirrors already have the files, so make sure to use them. Also, be considerate! Try to get the patch-*.bz2 files, rather than the linux-*.tar.gz files.
jesus the VM in 2.4.2-2.4.8 sucked BADLY. 2.4.9 shows marked improvement.
Tip: after boot, issue a swapoff on all your swap space, get your X up and running, and all your other stuff, then AFTER that, su root and swapon your swap devices.
Makes my system run a TON faster.
"Champagne for my real friends - and real pain for my sham friends!" http://ericblade.postalboard.com/
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
Answering to another post, YES, it _should_ be better for listening MP3 files because the mmap used for most players should work nicely with the read-once technique.
Although cannnot be assure until is hard tested, Linus found several mistakes in the cache and page aging.
DISCLAIMER: I am not a kernel hacker (although I tried it ;-). I just knew it reading every day the linux-kernel mailing list.
sgis ddo ekil t'nod i
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.
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.