Linux Kernel 2.4.10 403
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.
This discussion has been archived.
No new comments can be posted.
Linux Kernel 2.4.10
Related Links Top of the: day, week, month.
The fancy is indeed no other than a mode of memory emancipated from the order of space and time. -- Samuel Taylor Coleridge
So... how's the VM these days? (Score:4, Interesting)
Re:So... how's the VM these days? (Score:2)
The ChangeLog [kernel.org] doesn't mention any VM changes, so I'd have to assume it still blows.
Re:So... how's the VM these days? (Score:1)
pre11:
- Neil Brown: md cleanups/fixes
- Andrew Morton: console locking merge
- Andrea Arkangeli: major VM merge
It know its hard, but lets read before we post.
jrw
Re:So... how's the VM these days? (Score:2)
Well, yeah, I read that. But what does it mean? Is MAME now part of the Linux virtual memory subsystem? Is it optimized for playing MP3s? What does this "major VM merge" contain, and what does it fix/break/improve?
Re:So... how's the VM these days? (Score:2)
Read the fucking mailing list. God you slashdot jockeys are pitiful. Here's the mailing list url:
http://www.uwsg.indiana.edu/hypermail/linux/kerne
Start with the long threads where Andrea Archangeli, Linus Torvalds, Rik Van Riel, Marcello Tossatti, and Daniel phillips are going back and forth. Yes, it is a major VM change, and for the better. Rik's vm that started in 2.3.99 is not showing signs of getting better, so they are scrapping most of the experimental stuff and going for a solid design from andrea (the guy who finally got 2.2's vm stable under heavy load).
Re:So... how's the VM these days? (Score:2)
Re:So... how's the VM these days? (Score:2)
I did read it, but I confess that I missed that one entry. I expected that if there were significant VM changes we'd see a whole list of entries like "fixed XXX bogosity from previous VM changes" instead of a single line.
Re:So... how's the VM these days? (Score:2)
Don't be an ass. Things like "VM/shmem" cleanups" (pre13) and "sysctl/VM documentation" (pre8) don't give any indication of serious changes to how the VM subsystem actually works. Similarly "VM race fix" (pre12) could as easily refer to something that has been in there for a year as to something that was introduced recently. Aside from those, there is still exactly one hint that anything major occurred - "major VM merge" in pre11. That phrase is still pretty darn vague; "major" could still refer to a bunch of fixes that merely required lots of lines without really changing anything deep. I already 'fessed up to the error, which was a simple honest mistake, so I'm not going to take any more gratuitous crap from karma whores about it.
Re:So... how's the VM these days? (Score:1)
- Andrea Arkangeli: major VM merge
Sounds like a major VM-change to me
Re:So... how's the VM these days? (Score:1)
Re:So... how's the VM these days? (Score:1)
pre11:
- Neil Brown: md cleanups/fixes
- Andrew Morton: console locking merge
- Andrea Arkangeli: major VM merge
Re:So... how's the VM these days? (Score:3, Informative)
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.
The kernel mail list is full of VM stuff (Score:2, Interesting)
Re:So... how's the VM these days? (Score:2)
If you're looking for a stable VM, I've heard a handful of good things (like this [iu.edu]) about 2.4.9-ac10. Alan's been much more cautious than Linus about merging VM changes.
Re:So... how's the VM these days? (Score:1)
Re:So... how's the VM these days? (Score:3, Informative)
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.
Re:So... how's the VM these days? (Score:2)
And if you're already using swap space when you first boot up your computer, I might seriously recommend you invest the 30$ for some more memory:P
Re:So... how's the VM these days? (Score:2)
The VM has been totally rewritten by Andrea Arcangeli using his idea of 'classzone' balancing, and was merged in at 2.4.10-pre11.
I've been using 2.4.10-pre13 for a couple of days and... it's AMAZING! All your swap problems will disappear, and for me at least, the VM system is ~3x faster than any 2.4 kernel before it, adn faster than any 2.2 kernel as well by some distance.
Go get it whilst it's hot! No longer must we look enviously at FreeBSD!
Re:So... how's the VM these days? (Score:4, Informative)
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.
Re:So... how's the VM these days? (Score:2)
Until Linux drops the concept of memory overcommit, I'm afraid that the VM is going to continue to suck.
No offence, but you don't seem to know what you're on about. Linux does not overcommit memory by default, although it can if you tell it to.
root@funkster:~# cat /proc/sys/vm/overcommit_memory
0
which is the default setting. To turn on memory overcommit...
root@funkster:~# echo "1" >/proc/sys/vm/overcommit_memory
Re:So... how's the VM these days? (Score:2, Interesting)
256MB of RAM in machine...
Allocate 100 * 128MB using mmap. None of these ENOMEM.
Clear 100 * 128MB. Receive rather ungraceful SIGBUS.
Re:So... how's the VM these days? (Score:2)
Re:So... how's the VM these days? (Score:2)
Re:So... how's the VM these days? (Score:1)
I'm beta-testing Redhat 7.2, which includes the 2.4.7 kernel. Fat lot of good my bug reports would be if I started switching out major components, like the kernel.
I would only forgive that comment if...
Bite me, bitch.
Re:So... how's the VM these days? (Score:2)
If your system is out of memory (totally out - no RAM, so Swap) then stuff will fail. That's true on any system. The "OOM Killer" applies some heuristics to try to fail somewhat gracefully.
It's a fair assumption that on a production machine you'll run out of memory only when something has gone terribly wrong - some process is leaking badly or under attack. If you can kill that process then you're more likely to get your system working again quickly. (Or at least into a state where you can log in and repair things.)
In any case, even when the OOM killer chooses the "wrong" process, it's probably no worse than killing a "random" process, which is what happens without the OOM killer.
Re:So... how's the VM these days? (Score:2)
The second part of your arguement regarding quotas doesn't really contradict what I said. I said that if the system is truly out of memory then something has gone horribly wrong. You said the system should never run out of memory.
In order to prevent the system from running out of memory you would like a nice quota system. I can't argue with that, but it doesn't conflict with the idea of an OOM killer. Ideally we should have both.
Re:So... how's the VM these days? (Score:2)
No, it's entirely feasible and has been done in general-purpose OSes. If every process has adequate paging space as it should, and there's also an emergency reserve as there should be, then you can be smart about how you apply that emergency reserve and avoid having the system lock up. It's actually a generalization of the policy decision that the OOM killer makes, in that you have choices between "allowed to survive" and "killed". In a degenerate case you could get behavior very similar to what the OOM killer gives you, with certain "victim" processes starving instead of being killed, but you can also do much better because of the additional flexibility.
Again, this is where emergency reserves and policy-based mechanisms come into play. Some filesystems on Linux have space reserved only for root; the same can be done for paging space. Nobody has to die in order that root may live.
Re:So... how's the VM these days? (Score:2)
Um, then you're not out of memory.
Really I don't think we're disagreeing. You keep bringing up ways to prevent a true out of memory condition. Fair enough and totally valid. There were actually some RSS limit patches floating around once, but I don't know if they ever made it into 2.4. If not then I assume they'll go into 2.5.
Re:So... how's the VM these days? (Score:2)
Yes, you are, you're just not overcommitted - which is sorta "out of memory, and then some". The whole point is to stop selling tickets when all the seats are full, instead of selling more tickets than you have seats and then shooting someone in the head to make room when everyone with a ticket actually does show up.
OK, maybe that metaphor's a little bit too colorful, but you get the idea.
Possibly not, except that if these mechanisms had been in place sooner there would never have been a (perceived) need for an OOM killer at all...and I think that would have been a good thing. In any case, it has been nice talking to you.
Re:So... how's the VM these days? (Score:2)
Oops, that last paragraph was in response to an accidentally-omitted blockquote. "Possibly not" was in response to "Really I don't think we're disagreeing".
Re:So... how's the VM these days? (Score:2)
If you're running in non-overcommit mode, without an emergency reserve, and your important program has piss-poor error handling...whose fault is that? The VM-system designer's? Hardly.
Re:So... how's the VM these days? (Score:2)
That's what I meant by real-time, although I suppose you're right. My only experience with that kind of system is in real-time applications under a real-time OS, but there's nothing inherently RT about it.
That's a pretty unusual situation, but maybe the answer is to make the OOM killer a configure option. I still think that for the general case the OOM killer is a good idea.
Re:So... how's the VM these days? (Score:2)
The OOM killer does deserve to be killed.
So you would rather your box locked up if it happened to run out of memory? I know I sure wouldn't.
There's nothing stopping you from implementing resource quotas as well. The Linux OOM killer just gives a little breathing room for those who failed to set them. The fact that in earlier 2.4 kernels it triggered far too early does not make it a bad idea, it's just a bug that has been fixed. Or do you throw out every code idea you have the moment you discover a bug in it?
Sun disagrees with you too - Solaris has an OOM killer...
Re:So... how's the VM these days? (Score:2)
Neither would I. I'd prefer that the condition be prevented than that it be allowed and then handled so stupidly.
That's totally uncalled-for. I've been a developer for over a decade, and a significant portion of that time has been spent fixing bugs in my own and other people's code - including VM-system bugs (no, not in Linux). I know the value of leveraging existing code - which is what makes me wonder why the Linux crew reinvented yet another wheel in this case instead of taking the opportunity to adapt and improve on existing tried-and-true approaches. The Linux VM system as it exists today bears all the hallmarks of code written by people who didn't find out what they were getting into before they started.
Someone at Sun might have thought it was a good idea, but I know other people at Sun who realize it stinks. BTW, do you really think Solaris is that exemplary an OS?
Re:It's not all about the VM, what about X? (Score:2, Informative)
X in itself should not be a problem with 64 megabytes of RAM - are you running something like Enlightment and Gnome too? The window managers differ quite a bit in their memory usage, and Gnome/KDE grab some of it too.
Personally, I still use Windowmaker without Gnome/KDE (or rather have the neccessary library stuff installed for programs that are for KDE/Gnome, but not actively using resources) even though I have 256 megabytes of RAM.
European mirror (Score:2, Informative)
ftp://galileo.luon.net/linux/
Hmm... (Score:1)
Wooohooo, new kernel to try (Score:1)
cool,though my servers need to run this weekend :( (Score:1)
Here's to progress! (Maybe time to finally upgrade to to KDE 2.1.1, too).
Anyone know how soon the nForce chipset will be supported?
Re:cool,though my servers need to run this weekend (Score:2)
Hate to break it to ya, but KDE 2.2 has been out for a while...
And 2.2.1 is done and in the hands of the packagers, with the announcement of release due any minute now.
--
Evan
Interesting quote, Taco. (Score:1)
By "wreck those glorious uptimes," are you referring to rebooting so that you can start running the new kernel? Or do you mean after rebooting, you will never see those "glorious uptimes" again after having enough stupidity to install a new, bleeding edge kernel without so much as finding out how stable it is from others?
Use the mirrors, people! (Score:3, Informative)
Re:Use the mirrors, people! (Score:2)
i810e victim waiting.. (Score:1)
I'm probably not going to upgrade to 2.4.10 on that box for quite some time.. my laptop, though.. I use that every day so I like to try out new kernels. Anyone know if kernel bug reporting will ever get as easy as Ximian's? That is just plain nice.
x86-64 stuff (Score:1)
Did i see x86-64 [x86-64.org] stuff in the change log, some of this being
merged into the standard Kernal. AMD will be happy.
How much x86-64 support will be in the
standard kernal release (and gcc) by summer
next year? (Which is Hammer time).
I refuse to download a official kernel until ... (Score:1)
Re:I refuse to download a official kernel until .. (Score:2)
I think the big issue is that there was an oops associated with autofs/nfs usage, and that this oops was fixed just a week or two ago.
So I suspect Linus is letting it percolate in the ac series now.
Or maybe the ext3 team has not asked for it to be merged in the stable kernels yet. They are pretty conservative in adding stuff to stable kernels.
Anyhow, I've been using ext3 for a while now, crashed a few times, no worries in replaying the journal and booting really fast.
Ext3 may eventually debut in the 2.5.0 series and be re-merged back into the 2.4. But there will be patches for 2.4.10, I am sure.
Re:I refuse to download a official kernel until .. (Score:2)
But the question everyone is asking is (Score:1)
... when will 2.5.0 be out ?
I'd put my money on tomorrow... (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.
Re:XFS - Soon? (Score:3, Insightful)
I read on Linux kernel (I'm a lurker, but not a kernel hacker) that the current XFS patch contains a lot of cruft carried over from Irix. It helps SGI to keep the code base mostly the same as Irix, but it offends the sensibilities of the Linux hackers who don't want to have an Irix compatibility layer tacked on to their nice clean kernel.
I'm not sure what the compromise will be, but I'm sure they'll work something out. I wouldn't count on anything too early in 2.5.x - it'll take time to make whatever changes are agreed upon.
Re:But the question everyone is asking is (Score:2)
Re:But the question everyone is asking is (Score:2)
He means 2.5.
and that will probably be out in several months.
Or maybe it's already out, considering this article is about 2.4.10.
2.4.5 already exists,
Wow! I spotted the single true fact in your comment! Do I get a prize?
when it becomes suitably non-crashy, they wil release it as 2.4.6.
How interesting... you're applying the odd/even devel/release idea to the micro version number and not the minor one... and pulling the rest of the numbers out of your ass. Incidentally, 2.4.6 has been out for a while. And so have 2.4.7 through 2.4.9.
Didn't you notice that a 2.3 kernel was never officially released?
2.3 was the devel series which became 2.4. An odd minor number is always a development kernel.
They went straight from 2.2 to 2.4.
I congratulate you on your consistency in being wrong.
don't waste bandwidth (Score:5, Informative)
patch-2.4.7 [kernel.org]
patch-2.4.8 [kernel.org]
patch-2.4.9 [kernel.org]
patch-2.4.10 [kernel.org]
Links for the lazy folks ; )
Re:patches & RedHat (Score:2, Informative)
Hmmm... swap (Score:2, Interesting)
Re:Hmmm... swap (Score:3)
If you still find swap problems, grab Andrea's latest patches (look in the people/andrea directory on the kernel mirrors). He's added some modified swap code the other day that's not in 2.4.10.
--Bob
Re:Hmmm... swap (Score:4, Insightful)
Re:Hmmm... swap (Score:2)
That shouldn't be a problem. Effective methods of recognizing and/or dealing with this sort of process-doing-sequential-I/O problem have been well known for the better part of a decade. After the first few accesses, XMMS's activity shouldn't be polluting the rest of the page cache with no-longer-wanted pages.
That would be totally inane, if it were true. I don't think it is, but I have to admit I haven't actually looked into that particular aspect. God, I hope you're wrong.
OK, Rik has pissed me off with his defensiveness and general attitude lately, but I still think that's unfair. Despite its warts, there are also some good reasons not to go making major architecture-level changes to the VM system at this stage in 2.4 development. If a strong enough case can be made that something is actually broken - not just subject to improvement - and that the proposed fix will do no harm or invalidate the testing that has already occurred, I'm sure Rik and the others would listen.
I've been in the room with both of them and a bottle of liquor. They've had their opportunity to just that, though I can't quite recall whether they took advantage of it. Must've been because I was drinking too. ;-)
Re:Hmmm... swap (Score:2)
Simple test: dd if=/dev/dfd of=/dev/null, then see if your other programs got swapped out.
Current bandwidth utilization: 96.11 Mbit/s (Score:3, Interesting)
1 kernel every 2-3 seconds
or
5 patches every second
or
96% of the bandwith from kernel.org is used
Glorious Uptimes? (Score:2, Funny)
adapting a Linus phrase to the current situation: like masterbation, recompiling and installing a new kernel as soon as it is released feels good, but doesn't get any work done.
Re:Glorious Uptimes? (Score:2)
User Bio
i created survivor. now i troll slashdot. first probst bitches.
Yes, you're a troll. You don't bother me. Unlike you, I can spell. So get mad, have a fit, and go to school.
Congratulations. You can search archives. Too bad you don't have the capacity to understand anything spoken on that mailing list.
I too have the ability to post mindless links, try this one [dictionary.com]. That should help you avoid looking so stupid in the future.
Re:Glorious Uptimes? (Score:2)
About OpenBSD? I said OpenBSD because it has better bridging support. People don't always use OpenBSD just because 'its more secure'.
And I 'talk like i can hack'? I'm not some script kiddie, I dont talk in 'idjit sp34k' or anything like it. So where you get that idea from, I dont know.
And logos at the bottom? Hmm, gee, showing my support for the EFF, Debian, RedHat, Apache, Snort, Sourceforge, of course Slashdot, and other things that I rely on DAILY is bad? I just give credit where credit is due.
I am in fact smarter than you, and I can understand what is being talked about on the list. I have hacked kernel code before
Good for you. So have I. (specifically 2.2 firewalling. again, for bridging.) Big deal? Tens of thousands of other people do too.
four eyed freak? Haha, I don't even have to respond to that.
Now here I am getting in a flame war, On slashdot no less. I guess I'm allowed a few a year.
Either way, How bout just ending it? I apologize for taking your spelling and blowing it out of proportion. I wasn't aware of the Linus quote. Otherwise, I wouldn't have ever replied to your post (A link would have been nice in the beginning) It's a waste of time trolling/flaming over nonsense, and isn't my thing. I won't be responding to any more flames, unless you have something constructive to discuss.
Desktop users may like the pre-emption patch (Score:5, Interesting)
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 [tech9.net].
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.
Re:Desktop users may like the pre-emption patch (Score:2)
However as someone pointed out, the average throughput does suffer somewhat (last figure i heard was 4% decrease). This might not be the right thing for a server.
However if you primary use a system as a desktop system, go for it and try it out! it could use all the eyeballs it can get.
Re:Desktop users may like the pre-emption patch (Score:2)
I was really excited about the preemtible kernel when I first heard about it. Now I'm disappointed. This is one place where Linux is actually worse than Windows. Feh.
Re:Desktop users may like the pre-emption patch (Score:2)
I dunno. I've installed the patch and built a preemtible kernel, and mp3s still glitch pretty easily when I switch from X to console or switch workspaces.
Well then, there's a few things to consider:
Hope that helps.
Re:Desktop users may like the pre-emption patch (Score:2)
I had thought the preemtible kernel would make it unnecessary to set a priority, but I see now that it doesn't help if the sound syscalls aren't blocked but the app is stuck.
Looks like I'm in for more testing. I did recompile the ALSA driver, but would that be enough to make it preemptible? Hey, stop laughing!
Re:Desktop users may like the pre-emption patch (Score:2)
How to switch workspaces: There are multiple-workspace window managers for Windows. VirtuaWin [telia.com] is the one I use.
How to switch to console: DOS fullscreen mode. It's true that I don't often switch to a fullscreen dos session (i.e. text mode) under Windows. I'll let you know how that works out.
You're right, though. Part of the problem is that I do things with Linux that I'd never try with Windows.
Re:So what's the downside? (Score:2, Interesting)
As I understand it, it's not the standard behavior because to take advantage of it, you need to have much finer-grained locking in the kernel. But...they added that anyway in 2.4, for SMP. This guy just took the existing locks and made them work for a new purpose.
There may be no downside (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. [theaimsgroup.com]
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 [mvista.com] and here [mvista.com] 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.
Re:There may be no downside (Score:2)
ttyl
Farrell
Re:There may be no downside (Score:2, Informative)
Links to mirrors (Score:2, Informative)
http://www.kernel.org/mirrors/
Re:Links to mirrors (Score:2)
You can access the mirror list at:
http://master.kernel.org/mirrors/nindex.html [kernel.org]
Re:Links to mirrors (Score:2)
http://master.kernel.org/mirrors/nindex.shtml [kernel.org]
Leland Dallas Multipath... (Score:2)
Don't want to reboot my machine (Score:2, Interesting)
If it ain't broke.... (Score:2)
Seriously, unless it's a performance thing, sounds like your machine is doing sweet:). Leave her alone, and let that big red fire engine clock the 400h....... Then inform management(Just incase they are getting a horn over XP *ugh*)
NVidia driver broken under 2.4.10? :( (Score:2)
It seemed to be something like this in the log:
(II) NVIDIA(0): Not using default mode "1280x1024" (vrefresh out of range)
(II) NVIDIA(0): Not using default mode "1280x1024" (hsync out of range)
It did that for every possible display mode.
Is something broken here or have I just messed up?
UPTIMES!!! WOOHOO!! (Score:3, Interesting)
Today marks my one year anniversary of uptime on not one but TWO Linux machines herer. The only reason I powered them down a year ago was to move them into rack mount cases. There's hardly any load on either box, since ones a router and the other a name server, but still...
moving the box without shutting it down (Score:2, Insightful)
Unfortunately nearly the whole city lost its electricity for a few hours just a few days after I had moved the computer. Damn lightning strikes.. And as Murphy's law dictates, our UPS was just having its battery replaced so it didn't help in this case. Bummer.
Re:UPTIMES!!! WOOHOO!! (Score:2)
Granted, its nice to reboot because you need to rather than the box just doing it on its own, but come on (you know who you are) its time to try the 2.4x kernal like the rest of us. I, for one, will not let my uptime get in the way of adding another CPU!
Re:UPTIMES!!! WOOHOO!! (Score:2, Informative)
After installing 2.4.9 at a maximum my uptime would be about a month, except for an unfortunate hardware failure.
18:49:30 up 17 days, 1:31, 3 users, load average: 2.00, 2.02, 2.00
What kernel was the most recent a year ago? Would that be one of the ptraceable 2.2 series?
Looks real good to me!! (Score:2, Interesting)
First Impressions 2.4.10 from 2.4.8 (Score:4, Interesting)
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
2.4 is stabilizing as proportion of the whole (Score:3, Interesting)
Two possible reasons:
The first 4 2.4.10 persons are in there already - but all of them run prereleases.
Go register!
Need more!? (Score:2, Interesting)
I have followed (not lead) Linux for the last 10 years with interest,used it extensively, absolutely love it and what it has done for the reliability and enjoyment of personal and now professional computing.
Unfortunately we can all foresee (if not accept) the end of our beloved Linux as the kernel of choice. Even CmdrTaco mentioned it this morning. We have to reboot. Hot swappable kernel, as was mentioned in a previous post is a possibility but I believe this is just bolting on functionality to a now outdated kernel proposition. Linus and the community did a fantastic job of emulating a UNIX kernel. Just what we wanted. We now want more. Linux is not the answer to our future. GNU and the tools around it maybe but not the kernel and I think Linus will be amongst those to accept this.
Maybe HURD is the answer for reliability, extensibility, versatility, Hot Swapability etc. in the future. I will love to follow this trend when it lifts.
To the HURD folk. I watch and wait and long to follow. Thanks.
Re:EMU10k1 anyone? (Score:2)
Re:EMU10k1 anyone? (Score:2, Insightful)
Posting to slashdot will do nothing.
Re:Odd kernel error message [slightly OT] (Score:2)
Re:Odd kernel error message [slightly OT] (Score:2)
I think I read somewhere that this _could_ be because of faulty include files.
Should I or should I not make symlink to
I tried both options, both give me the error.
Running Debian unstable glibc-2.2.4.
Re:Linux 2.4 is an incredible step backwards (Score:5, Funny)
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.
"Erisian principal"...see below for more info. (Score:2)
ttyl
Farrell
fnord
Great! (Score:2)
Oh. Reiserfs. It's got some things that are not good... so? Who said you had to use it?
And to boot.. what's preventing you from using 2.2.x?
Re:WTF, "O(n) NP-complete" ??? (Score:2)
Re:Oh no! (Score:2)
Doh!! I should have noticed that big red flag! I am a moron.
Re:Mirrors? (Score:2)
Re:is kernel.org dead? (Score:2)