Posted
by
CmdrTaco
from the download-compile-reboot-repeat dept.
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.
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?
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).
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.
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.
There are lot of changes in the VM. In fact it's almost entirely new with a big patch from Andrea Arcangeli.
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.
It may or may not still blow (I haven't tried it), but there have been substantial changes. Andrea Arcangeli did a large rewrite in pre11 ("major VM merge.")
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.
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.
Okay...that's just rediculous:). Whatever memory is curently being used most frequently stays in physical memory. Whatever is being used most infrequently stays in swap. Simple as that.
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
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!
Well, AA contributed an enormous VM patch that basically changes the whole system. Apparently it has good effect for interactive uses like MP3 players and web browsing, but testers at HP labs say that the performance of the 2.4.10 VM is the worst of the (very bad already) 2.4.x series on their 4-8 GB machines with 30+ SCSI devices each. They make this conclusion based on NFS benchmarks.
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.
He knows what he's talking about. Even with overcommit_memory=0 the behaviour is still somewhat overcommit. "Turning overcommit off" just enables a check that any SINGLE allocation doesn't exceed available memory. This is fine except available memory == paged in memory. Easy example to kill a program:
256MB of RAM in machine...
Allocate 100 * 128MB using mmap. None of these ENOMEM.
Clear 100 * 128MB. Receive rather ungraceful SIGBUS.
I know about the/proc setting, but the kernel overcommits regardless of your preference. It just does it more or less aggressively. Either way, the kernel will deliver SIGBUS to your process just because you tried to use some memory that was sucessfully allocated. How is any programmer supposed to deal with that?
That's a stupid comment. If someone has been using the 2.4.10-preX series and can volunteer some information, isn't it easier if he just talks about it rather than making everyone go through the processes of trying it out?
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.
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.
There is no need for any existing process to die in an OOM condition, although it may be necessary to prevent new processes from being spawned.
For the existing processes to continue they would need to be able to keep working without allocating any memory. That's feasible on a real-time OS, but on a general purpose OS at least some of the processes are going to become useless, even if they don't actually segfault. In that case it's better just to kill them off and free up the memory.
Preventing new processes from starting is very bad. It means you can't, for example, start a new console session in order to administer (and hopefully save) the system. I've had this happen on commercial Unixen and it sucks big-time. I would much rather have had an OOM killer that gave me a chance of regaining control of the box.
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.
For the existing processes to continue they would need to be able to keep working without allocating any memory. That's feasible on a real-time OS, but on a general purpose OS at least some of the processes are going to become useless
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.
Preventing new processes from starting is very bad. It means you can't, for example, start a new console session in order to administer (and hopefully save) the system
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.
If every process has adequate paging space as it should
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.
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.
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".
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.
There are systems where every app is controlled and written with non-overcommit in mind, and there's no reason Linux should intentionally ignore these possibilities.
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.
There's a single process (apart from a custom init) which is the only userland allocator in the system, and it allocates pretty much all of memory (13-15MB out of 16MB).
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.
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...
So you would rather your box locked up if it happened to run out of memory? I know I sure wouldn't.
Neither would I. I'd prefer that the condition be prevented than that it be allowed and then handled so stupidly.
Or do you throw out every code idea you have the moment you discover a bug in it?
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.
Sun disagrees with you too - Solaris has an OOM killer...
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?
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.
Quite cool to see this latest upgrade. Kudos on the quick announcement. I'll start upgrading my workstations in a about an hour, but we have a pretty big project going on this weekend, so I won't be able to upgrade any of our servers until mid-week at the earliest.:(
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?
Time to make bzImage and wreck those glorious uptimes.
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?
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.
I've given an IBM NetVista S40 legacy-free to two other guys so the three of us can try to get X working on 'em. I spent a couple hours hand patching some stuff in drivers/char/agp and drivers/video to improve the AGP handling for an i810e, but make bzImage still isn't compiling..
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.
Having asked this question myself, it turns out that Linus is ready to merge ext3 any time right now, but in order to do so he needs to merge a bunch of other VFS changes from Alan's kernel. Since this release seems to have focused on merging a lot of Alan's other changes, perhaps Linus will get to the VFS merge in 2.4.11. That's just speculation.
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.
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.
You're forgetting that 2.5 is the development kernel. They're already discussing what it's going to encompass, and some of the projects have already begun, but no release date for the first test kernel have been announced.
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.
So some other people have had problems with 2.4.7 (Redhat 7.2 beta)? How many people out there are actually using 2.4.8,and.9 and if so... do they handle swap better? There should be no reason why a box with 512 megs of ram should be swapping running xmms (i'm not kidding... after being up for about an hour just running X, Gnome and xmms... my computer hits the swap... of course i fixed this (more ram, hasn't swapped yet) but its a little concerning about the aggressivness of the kernel to swap. I'd be appreciative if anyone who has used one of the new kernels could tell us whether swapping is handled a little more gracefully.
There have been some persistent VM bugs for several versions (since about 2.4.4). 2.4.10 fixes them because Linus incorporated Andrea Arcangeli's VM patches. I'm running 2.4.10pre13aa1 and things are vastly improved. The "swap storms" of previous versions have completely gone away. 2.4.10 should be excellent.
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.
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.
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.
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.
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.
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.
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
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.
He should get together and have a beer with Hans Reiser.
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.;-)
I hope I'm wrong too, but I'm right. The 2.4.9 VM didn't understand pages that were only read once, as by a DVD player. Hence all of the read-once patches floating around on l-k lately. Most of them are questionable hacks, but the idea, as you note, has been around for a long time and should be implemented.
Simple test: dd if=/dev/dfd of=/dev/null, then see if your other programs got swapped out.
Time to make bzImage and wreck those glorious uptimes.
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.
Okay, I'm gonna play along.
Yeah, I use windows. On 2 computers. Out of a dozen others. And you dont need to run Windows to write about it.
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.
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.
I've been running this patch on my desktop and notebook systems for a few days now, and my experiances have been very(!) positive. Desktop interaction, games, movies and music all interact a lot smoother (quite noticable on high loads, like compiles etc)
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.
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.
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.
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:
Is your mp3 player running with real-time scheduling? Even with a pre-emptible kernel, if your mp3 player is not running real-time, which is the default for both XMMS and Noatun, then it can easily get starved of CPU time for long enough that it causes a skip. The Linux scheduler is... just too fair to other processes on your system. From the symptoms you describe, this sounds like the most likely cause. Yes, this should be fixed in XMMS and artsd (which does the mp3 decoding for Noatun), but it's pretty easy to turn real-time scheduling on for both of them.
Are you using a filesystem other than ext2 on your system? The filesystem code is generally the largest source of latency in Linux, and the pre-emptible kernel patch has had most of its testing so far on ext2-based machines. This is why the pre-emptible kernel patch needs all the eyeballs it can get, to pick out areas of long-held spinlocking that have been missed.
Do you have a very slow hard disk, or maybe your partitions are highly fragmented? All the fancy kernel trickery in the world can't help you if your hard disk simply cannot seek or pull data off the disk fast enough.
Is your sound card driver broken? The only machines I've seen the pre-emptible kernel running on were using the kernel sb16 and emu10k1 drivers. If you're running one of the less-used kernel sound drivers, or worse, a sound driver that's not in the mainstream kernel (this includes ALL of ALSA, btw) then all bets are off. For instance, it could be that your sound driver is a little too cocky abouts its buffering, and when the PCI bus gets busy (as could well happen when switching to a VT or switching workspace, especially if you have a PCI graphics card) then the sound driver's kernel buffer overflows. ALSA in particular seems to have some kind of interaction problem with the pre-emptible kernel, again, this is why the pre-emptible kernel patch needs eyeballs.
I'm using ALSA, and I didn't set high priority for the mp3 players I tried (mpg123 and xmms).
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!
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.
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.
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.
Thinking about it...on systems in the past, they ran fairly slowly, and to get a real-time pre-emptible systems ment making the system very small, so that each event didn't hog (relatively) system resources too long. But today's systems that run at upwards to 2 gigahertz, the process switching time even for large processes is so fast, that resources can be quickly reallocated and thus are not spent waiting. TANJ, it's been too long since I studied OS kernels and read Tannenbaum's book! I bet Minix's message passing system would run real nice on today's hardware!
Well, why isn't this configurable, requiring people to patch it? Windows NT/2000 has a similar setting (Optimize Performance for Foreground/Background) for quite a long time. It's time for the Linux kernel to add such a capability to gain more desktop accetance.
kernel.org is down for the count; unfortunately, we can't get it restarted until at the earliest some time tomorrow (there are some issues that hadn't been resolved yet after the move, and remote management when the kernel deadlocks fall into that category...)
I think it is finally time to write a new kernel that supports Linux kernels as module so I could just compile a new Linux kernel and then with modconf just unload the old one and kick in the new one. This is because usually I wait until the machine crashes before doing kernel updates. This is bad due to stability of Linux. Last time my server crashed it had 397 days of uptime (and the crash was a IDE hardware error), now the machine has 347 days and this time I hope to exceed the 400 day limit, but this forces me to use 2.2.14 kernel (until next crash).
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*)
Went through the usual procedure of make menuconfig/make dep/make modules/make modules_install/make bzImage/lilo, etc. Reboot, rebuild the NVidia drivers and install them, but X keeps crapping out.
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?
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...
I assume you don't have one of those computers with two (or more) redundant power supplies in it, as in some Dell Poweredge servers. I had to move our file server from one room to another, but didn't want to shut it down just for that. So, I got a long power cord and attached it to the 2nd power supply and disconnected the first. Then I moved the computer towards the other room and switched it to use the other power supply and disconnected the now-unneeded power cord. I repeated this procedure a few times and finally the server was happily churning in its new place, all without rebooting. Using this method for moving the computer was absolutely unnecessary, as there was nobody at work at that time (except for me), but at least I managed to keep the high uptimes:)
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.
You know, this kind of thing just kills me. I suspect you did it right, so this is not aimed at you personally, but I work with a bunch of folks who would not fix security holes or other GOOD patches because it might case them to reboot - having to run over to my cube to telnet into their box because the x server horked up again, etc.
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!
Just downloaded it and built it. I just came off of a 2.4.5 kernel... was used to an instant free memory drain -- 512Mb used to go to about 40Mb free in no time with X up. WOOHOO... now showing 328Mb free with full KDE 2.1, xawtv, mozilla, and a few other thingies running - 60 processes in all. I think I'm gonna like this!!
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.
According to the Kernel stats [li.org] of the Linux Counter, the proportion of 2.4 kernels has actually gone slightly DOWN recently - it was briefly above 50%, but is now back to 47.7%.
Two possible reasons:
More 2.2 persons have registered
The 2.4 persons have forgotten to use "machine-update -c", and have slipped out of the list after not updating for 60 days.
The first 4 2.4.10 persons are in there already - but all of them run prereleases.
So, the new kernel is out. Great. The last kernel failed to compile on the Alpha. (OK I know 2.2.19 is the last kernel on alphalinux.org)
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.
emu10k1 was fixxed in 2.4.9, and the only problem you're referring to is when built as a module. This is further refined in 2.4.10, and it works perfectly.
So nobody has any idea. Hmmm.
I think I read somewhere that this _could_ be because of faulty include files.
Should I or should I not make symlink to/usr/src/linux/include/[linux|asm|scsi] from/usr/include? This used to be the way to go from the beginning of linux up till somewhere in the 2.2 kernel. Then it was said that you should just leave the glibc includes where they are.
I tried both options, both give me the error.
Running Debian unstable glibc-2.2.4.
This extra abstraction means that Linux has no chance of ever matching the AGP throughput of Windows
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.
No, "O(n) NP-complete" proves that trolls don't actually have to understand the jargon, they just have to use a lot of it to get modded up by someone who understands less.
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)