Slashdot Mirror
Kernel 2.4.17 Out
ThatComputerGuy writes "Linux kernel 2.4.17 is final, with a lot of fixes/updates. Check out the huge changelog. If you're on a desktop machine, you should try using RML's preempt patch, it definitely helps response times."
← Back to Stories (view on slashdot.org)
I used the preempt patch back when 2.4.14 was released and I kept getting consistent kernel panics. Mind you, I'd also applied an -ac patch, so I can't say for certain that preemption was the cause, but it was troubling and the panics went away once I disabled preemption.
STOP MISUSING APOSTROPHES, YOU MORONS!!!
You will want to wait until RML releases the finale preempt patch. It will just be the kernel version (2.4.17) without the rc on the end. His patches are very version specific.
Pbur
I haven't looked at the changelog yet, but I'm sure that there's a line reading something like
/promise/ not to corrupt filesystems when you 'umount /mnt/tmp/lifes_work'."
"This time we
All the same, many kudos to the kernel guys for giving me something new to play with for the holiday!
--
I Hit the Karma Cap, and All I Got Was This Lousy
It looks like we're actually seeing 99% bug fixes this time around, rather than new features being added. Yay for having a 2.5 branch, it seems to be getting the experimental code now. This may be the first 2.4 kernel I compile for my system (I'm not saying I'm still stuck in 2.2, just that I've kept the default 2.4 kernels from my Mandrake and SuSE installs). I also see a couple ext3 fixes, which means I'm pretty comfortable having this replace the patched-to-use-ext3 2.4.10 kernel in my SuSE 7.3 box.
My Greasemonkey scripts for Digg &
Does it work with the KT133a Chipset and Athlons? I looked and google and there were reports of the problem, but no report of a fix anywhere that I could find.
you don't HAVE to upgrade your linux box, either. but at least you have the OPTION of upgrading for FREE, instead of paying year after year if you want to upgrade.
as you said, you are happy with win98, more power to you. but many people are not happy with windows and have to shell out big bucks every couple years to upgrade.
yeah, i know, the post was flamebait. but hey, i'm a sucker for anything this obvious.
-sam
burn the computers. go back to the abacus.
Looks like the new kernel maintainer is really working out. I enjoy seeing these kind of detailed changelogs, to determine whether there is anything critical enough to upgrade my system.
Seems like Alan and Linux lately haven't been all that hot about doing the drudge detail work. This arrangement seems to be the best solution for everyone.
I have mirrored the patch and signature:
. bz2
. bz2.sign
patch-2.4.17.bz2 (388KB): http://home.earthlink.net/~noodlez84/patch-2.4.17
patch-2.4.17.bz2.sign (1KB): http://home.earthlink.net/~noodlez84/patch-2.4.17
After several of the last few kernels being released with major bugs, I thought the consensus on LKML was to use -rc versions for bugfixes, and then release a 'final' without making any changes in it. Yet, when I read this changelog, I see that changes were made in the final version. A lot of people will only download a 'final' kernel, because they think that it contains only tested, stable code. That is what the -rc system was to ensure, but releasing a 'final' with changes means that a partially untested kernel is being released to the unsuspecting public. Now, I will admit that there's a very good solution that any user can implement - just don't upgrade. However, these recent quality control problems have given Linux something of a black eye in the public's mind. Therefore, it just seems common sense to not release a kernel with code that hasn't been in for at least one -pre or -rc revision. So, if I were a kernel maintainer, about to release kernel 2.4.18, and I received a 'critical' patch from a project maintainer, I'd make one last -rc release to ensure that the code gets tested before I release it. However, I'm not a kernel maintainer, so take this as you will. I don't mean it as a flame, and I think that Linus and Marcelo have done a wonderful job so far with Linux 2.4.
in the changelong I noticed...
pre5 - Enable K7 SSE (John Clemens)
So we now have SSE for the K7 cpu? Does any programs on linux even take the extra speed of SSE/MMX/3D NOW? I have always wondered since these type of optimizations are only visible when the software application lists it, and most software is for windows.
The patch makes a big difference for me when using latency-sensitive software (xmms) while I'm really pummeling my system (big compile).
xmms usually skips a bit while I'm compiling something large, but it hasn't even once after applying the preempt patch.
I haven't noticed performance degredation from any effects on throughput, so it's all good here.
"Where shall the word be found, where will the word resound? Not here, there is not enough silence." -T.S. Eliot
You remember right. Lack of *any* documentation, more like it. Licensing I don't think is a problem, as everything is done blind. MS changes NTFS every time they put out a new OS though, so that kind of complicates things.
"If he thinks he can hide and run from the United States and our allies, he's sorely mistaken." Bush on bin Laden
Having a preemptive kernel just means that the kernel will allow itself to be interrupted by other programs and give them some cpu time.
This improves response time for your programs as now they won't get stuck waiting for the kernel to finish doing something time-consuming (like disk I/O) before they get some cpu cycles.
In most cases this isn't a big deal, but you'd definitely notice when your mp3 player skips because it's stuck in line behind the kernel.
"Where shall the word be found, where will the word resound? Not here, there is not enough silence." -T.S. Eliot
Something I feel like asking as 2.4.17 (bz2) trickles down the connection at 0.2K/sec from Australia's Planetmirror...
The kernel's are posted in both GZ and BZ2 formats. What do you guys mostly use? I can't see much point these days with having the Gzip format, I mean is there still a point to downloading it? Or even having them available in that format?
From what I can see, removing the Gzipped versions
*reduces network congestion
*saves space on the mirrors
*saves space on local storage (yeah only a couple megs)
Of course, it requires more processing time to extract, but that seems to be no big deal these days. I'm pretty sure everyone has bzip2 installed , and those who don't can easily get it, so that can't be a problem.
So is it really just traditional reasons it's posted in Gzipped format? Tell me if I've missed something. It would be interesting to know what everyone thinks about this.
There are two things here. Preemptive in userspace, and preemptive in kernel space. Linux is preemptive in user space, meaning that when a process is running application code, it can be preempted. When it is running kernel code, however (ie. during a system call) the scheduler will not preempt the thread, even if a higher priority one becomes available. Essentially (on a single processor) the kernel code is cooperatively multitasked. Kernel code runs until schedule() is called to invoke the scheduler. Some kernel code paths are very long, which leads to long periods where the current process cannot be preempted, which kills latency.
Also, to expand on the original question, there are a couple objections to the patch: It has the potential total throughput, because more locking must be used since the kernel can be preempted at any time, not just at specified points. However, in practice, the effect on throughput seems to be negligible. It also increases complexity, due to additional locking, but most of the complexity is there anyway, in the form of the SMP locks.
A deep unwavering belief is a sure sign you're missing something...
"RML"? Robert M. Love stole my initials! Now I have to worry about people confusing me with someone who knows what he's doing.
Human/Ranger/Zangband
> I don't understand the difference between preemtive and the normal way (btw: which?).
The normal (old) way is "cooperative" -- meaning you don't yield a task until you're ready.
Pre-emptive means you can be forced to give up your task.
Ah! Partially right! But sorry, no dice. The only cooperative multitasking that is done in Windows 9x is with 16 bit applications, since all 16-bit apps are run in the same virtual machine. All 32-bit apps are fully preemptively (userspace multitasked. As for memory protection, that's only partially true. Application memory is indeed protected from each other. However, there is a big 1GB region of shared memory that is unprotected. Apps that use this region and asking to hose the system. Also, some bits of kernel memory are unprotected because DOS apps need access to them.
As for NT, it is a fully preemptible kernel, both in userspace and kernel space. Like all preemptive kernels, of course, it is not preemptible when interrupts are disabled (since the clock interrupt can't happen). The main reason why NT has always been preemptive is because its always been SMP. The locking requirements on SMP are similar to to locking requirements for a preemptible kernel, so you can get both together for the price of one. Indeed, the preemptive patch for Linux is very small because it uses the existing SMP locking mechanism.
A deep unwavering belief is a sure sign you're missing something...