Check out the Preemptible Kernel patches...
by
cymen
·
· Score: 5, Insightful
The Preemptible Kernel patches can result in a desktop that reacts/feels faster... I'm running it here with 2.4.10 on an Inspiron 4000 laptop and I'd have to say I'm impressed - everything feels a bit zippier. The only problem I've had is that there seems to be some loop that it has optimized that blasts bits around the memory bus at high speeds with a rthymic pattern - in short if I'm in a really quiet room the high pitched busses are a bit noisy... Maybe my hearing is too good!
Anyway - doesn't look like much changed since pre-6 so the pre-6 patches should work but if you want to be sure you can wait until rml releases the 2.4.11 final patch. I'd recommend checking it out if you have the time...
Re:Check out the Preemptible Kernel patches...
by
jmv
·
· Score: 5, Informative
These sound real good. Is there a reason that these patches are not the default behavior? Is there a downside to having a premptible kernel?
AFAIK, there are two reasons why these patches aren't in default kernel. First, I understand that decreases latency at the price of slightly decreasing throughput. The second is that though the patch is small, its effects can be complex and nobody's too sure it doesn't have any bad side effects (crash, oops,...), especially on SMP systems.
Re:Check out the Preemptible Kernel patches...
by
Adam+J.+Richter
·
· Score: 4, Insightful
For things like playing buffered video and sound,
where you just need to get the CPU every few milliseconds, I would think that the system call code paths are not so long that you really need a preemtable kernel. I would expect that it would be enough to just change the time quantum from 1/100th of a second to, say, 1/5000th, by replacing the "#define HZ 100" in include/asm/param.h to "#define HZ 5000". I have not tried this, but this sort of thing has been discussed on the linux-kernel mailing list. One person there reported that doing this prevented his Palm cradle to no longer be able to sync, so be warned that this seems to trip at least one bug.
As someone who has only looked through the preemtable system call patch and never tried it, my impression is that while it may be great, I expect its design to change a bit. Right now, under this patch, you build the kernel with basically a fixed number of fake CPU's that basically make your computer look like it has more CPU's than it does. The kernel being preempted basically causes the old kernel's state to become associated with one of these fake CPU's and then the preempting context takes over a real CPU. [I'm really not doing justice to code in this oversimplified and possibly misinformed description.]
In the future, I would hope that the need for a fixed number of fake CPU's would disappear and the "old fashioned" way of doing context switching would also disappear when the preemtable kernel option is selected. In other words, that would be the only way that context switching would normally occur, rather than having two ways of doing the same thing.
I have always regarded the potential for a preemtable kernel as the biggest side benefit of the move to SMP in Linux 2.0, and I'm glad to see people turning it into a reality.
However, maintaining the option of making a non-preemtible kernel may be worthwhile, at least for a uniprocessor kernel, because the preemtible kernel code relies on running an multiprocessing kernel (even on a uniprocessor),
which has a slight performance cost in setting and releasing all those locks that never once experience contention.
Re:Check out the Preemptible Kernel patches...
by
achurch
·
· Score: 4, Insightful
Having a preemptible kernel makes things feel faster because what you're doing right now is getting serviced the
most, but the overall system performance is actually decreased a bit.
Which is bad why? The important thing is not (always) some arbitrary absolute measurement of "speed", but rather the apparent (to the user) speed of the system. If you're reading mail, you probably won't care, or even notice, that your compile takes 49 seconds instead of 47.
Re:Check out the Preemptible Kernel patches...
by
DGolden
·
· Score: 4, Informative
One thing to note, and I find myself saying this again and again, is that one of the simplest performance tweaks you can do is to negative-renice the X server. It's even mentioned somewhere in the X manual, and makes a hell of a difference.
This means that the GUI then pre-empts background tasks, like on Windoze, and other systems intended for desktop use. Of course you don't want to do that on a server machine, but only Microsoft are stupid enough to do it by default even on their "server" OSes.
I'd like to see "workstation" installs do it automatically, but there's a few small notes:
(a) if you renice it too low, it also ends up pre-empting audio tasks too much, and audio could conceivably skip when you move windows about. Shouldn't happen on today's reasonably fast computers. Easily fixed by careful tuning, perhaps including renicing important audio tasks too if your computer's really slow.
(b) If you're using the xfs font server, it needs tuning too - if it's starved of cpu time, then you might actually make text-heavy parts of the gui slower, not faster. I really wish distros would stop using xfs, since truetype support is now built into the X server, and server-side font support is being phased out thanks to XRender and Xft anyway.
Back in 2.4.10, Linus made a fairly radical change in the virtual memory system - a rather unusual one for a stable kernel. While a lot of people are rather unhappy about it (notably Alan Cox, Rik Van Riel (the maintainer of the existing VM system), from all public accounts so far it seems that the new VM system works considerably better than the old one.
So - - - Is that the case? Has there been any stability problems? Is the performance better (not that it really matters as a workstation user, but ... )
--
Any sufficiently advanced technology is indistinguishable from a rigged demo --Andy Finkel (J. Klass?)
Re:VM Changes
by
Ian+Schmidt
·
· Score: 5, Informative
Performance under my normal working set (KDE 2.2 w/default theme + Mozilla nightly version + the CRiSP text editor + KMail + XMMS + GAIM + several xterms, with occasional compiles and runs of very large apps like Wine and XMame) is substantially better (faster, smoother, way less swapping) on 2.4.10 vs. 2.4.9. I should note I'm running 512 MB RAM and 640 MB of swap on 2 partitions, and the system barely ever goes to swap now (with the previous VM, just starting up that environment got me into swap and it quickly maxxed out the swap from there).
So while I do appreciate Alan Cox's caution, the new VM works substantially better for me and I say "Go Andrea and Al!"
Re:VM Changes
by
TheGratefulNet
·
· Score: 4, Informative
I'm not sure I agree it works better.
I ran all the 2.4.x's, both at home and at work. I am a software developer (not kernel, though) and so I beat on my systems pretty heavily. both systems run dualhead X and my work system additionally runs hardware (dac960) raid. cpu is a k7 tbird, in the ghz range.
anyway, 2.4.9 was ok for me. I tried 2.4.10 and both my systems (home and work) locked up within days. hard tight lockup.
I brought both back to 2.4.9, and so far, so good (less than a week running, though; it was only a week ago I went to.10 and had those problems).
I, too, worry about 3k line commits to so-called 'stable' trees to radically change an algorithm or model. can't say for sure if.10 was really a dog for me, but my systems usually run for months and months before being rebooted (usually due to my swapping of pci cards and such, necessitating a shutdown to do the board swap). so it does seem unusual for me to have a modern linux kernel freeze on _both_ of my hard-working linux boxes. hmm..
Ruling aside the obvious objections (changing major subsystems in a so-called "stable" kernel, NIH syndrome) I can only assume Alan's objection is that it was yet another really neat thing developed (or sponsored) by rival Linux company SuSE (like reiserfs, which he also objected to)
That's a very strong allegation, and you'd better have some solid facts to back it up. I don't care for RedHat but I have great respect for Alan Cox. His objections seem valid to me. I'd also be very reluctant to do a major change in the stable release of any software, especially if I was the primary maintainer (like Alan Cox is for Linux). You'd better come up with some concrete evidence to justify your claim, or I'll assume you are just trolling.
-- ___
If you think big enough, you'll never have to do it.
Re:VM Changes
by
CraigParticle
·
· Score: 5, Interesting
It shouldn't surprise anyone that 2.4.10 VM performs better than 2.4.9. Even in terms of the "traditional" 2.4 VM from Rik, the Linus and Alan trees deviated starting around kernel 2.4.7. There were numerous complaints about the Linus tree missing important patches, and having contradicting patches applied. It ended up quite a mess, and VM performance reflects this. Alan's tree was much more conservative in this regard.
If you compare 2.4.11 to anything, please compare it to the latest -ac kernels from Alan, where the traditional 2.4 VM is actually working very well. There's NO sense in comparing 2.4.11 to 2.4.9; the VM in 2.4.9 and its kin -- it was just plain broken.
Side note: In Rik's VM, please remember to not just look at swap used as a gauge of whether you're swapping or not. All anonymous pages are mapped to swap, so the space is simply allocated. You can create a huge image in GIMP and lots of swap will be allocated, but without a drop of disk I/O! Use vmstat and look at the 'si' and 'so' columns to see if you're actually writing pages to swap. Or look in/proc/meminfo and subtract "SwapCached" from the amount of swap you think you're using. That's the amount of *written* swap you're using (a better comparison to 2.4.10).
This needs to be made sensible in 2.5, if this VM is to be resurrected.
Andrea's work has cleaned up the handling of inactive pages (which could have been done under the old system), and the new "classzone" approach and VM balancing isn't documented anywhere outside the code itself. In addition, there are very normal loads where it performs badly compared to the -ac tree. Here is a test suite that tests different aspects of aging and swapping, and the results as provided to linux-kernel. 2.4.10 (patched with Andrea's VM tweaks) swapped more pages, took longer, and had to swap more pages back in when the tests completed (i.e. it could have chosen better pages to swap out). It also caused XMMS to skip mp3 playback throughout the tests, whereas -ac didn't.
Nothing's perfect of course; a process that randomly walks through pages performs better in 2.4.10 since it's more streamlined and not trying to be as "intelligent" about page handling. Rik's code could no doubt be improved here.
That's the great thing about open source: let the best idea win! No doubt in 2.5 we'll see these two VM schemes hash it out in much more complete form (i.e. lose the remaining kernel 2.2-isms, maybe add physical page mapping, almost certainly swapfs -- mostly for Rik's scheme; I'm not sure what the next steps for Andrea's VM should be).
Re:Where do I find more detailed changelogs?
by
worldwideweber
·
· Score: 4, Informative
There are a few changes to the emu10k1 driver that may affect you:
- Mixer improvements (should add support for treble, bass, volume, and others).
- Fixed a dead lock in emu10k1_volxxx_irqhandler.
- Small code cleanup.
-- w o r l d w i d e w e b e r
Re:Syncing with AC kernels
by
worldwideweber
·
· Score: 5, Informative
The two trees are very different in certain cases, and are likely to stay that way for a while.
The -ac tree has the following major additions:
- Uses the Riel VM (Linus uses AA)
- 32bit uid safe quota
- Ext3 file system
- PnPBIOS support
- Various PPro and Pentium workarounds
- Simple boot flag
- Faster x86 syscall path
- PPPoATM
- Elevator flow control
- DRM 4.0 and 4.1 support not just 4.1
- CMS file system
- Intermezzo file system
- isofs compression
-- w o r l d w i d e w e b e r
Thoughts on the 2.4.10+ VM
by
Shane
·
· Score: 5, Interesting
My personal feelings on the new VM is that it was the right decision. The VM problems have been going on for months. When people would report a problem, Rik would pretty much say: I don't have time to work on so and so.. feel free to pay me or convince my employeer to fund the work. Which is fine, that is his choice... But if I was Linus this would make me more open to looking at alternitive approches even if the short term risks were moderate.
It is also interesting to note that Rik's vm core has had say 15 kernel releases (unstable + stable) to become stable and meet up to the expectations that Rik sold the kernel hackers on in the first place and judging from the reports on LK it is just now becoming stable enough for most work loads.
The new 2.2.10+ VM had a couple minor to moderate problems for _SOME_ work loads but over all has received very good reports as far as I can tell for being so new. 2.4.11 is bound to be even better.
Some people are complaining about the inclusion of major VM modifcations in the stable tree. I believe the truth is that most people that use Linux in production do not roll their own kernels. They use the vendor supplied kernels.
Redhat for example will be releasing a 2.2.7-11-AC kernel which uses Rik's VM, it is what they have been testing for months and thus is what they will end up shipping. So the fact that Linus made this change in the "Stable" tree makes very little difference to me from a stability stand point, and I think it will prove to be a very good call in the short/medium/long run.
Thats my 2 cents anyways.
-- -- You can be a geeklord too:)
Re:Thoughts on the 2.4.10+ VM
by
KidSock
·
· Score: 4, Insightful
The problem with Rik's VM was Rik. He has been an arrogant piss ant for as long as I've been watching the list. He obviously ain't no dummy and I have no problem with working with people like that but I think Linus was itchn' to get that monkey off his back. They were applying all sorts of desperate patches ("tuning") and falling all over each other in the process. They just don't know why his VM goes off into la la land under high loads. What do you do about that? Stable or not Andrea totally rewrote the VM in like 5 weeks. Sometimes rewriting something from scratch like that is just the Right Thing to do. Linus saw that on the surface it worked better than Rik's and took it as a blessing. Sure 2.4.10 was bleeding before it left the gate and immediately needed triage (anyone running 2.4.10 should get this release patch folks) but so far it's not been a disaster like some people have been warning about. In fact most people claim it's quite a bit better than Rik's. If you've been using 2.4 without luck, try this one folks.
Unfortunately that picture is not at all of Andrea Archangeli, who is most definitely male. Sorry.
Re:Syncing with AC kernels
by
ASM
·
· Score: 4, Funny
AC kernels? Now THAT's open source at its best. I mean just think Annonymous Cowards writing an OS, and they don't even know each other....
-- Fish
Thoughts on kernel development model
by
Erik+Hensema
·
· Score: 5, Insightful
During the stable life of 2.4.x it became more or less clear to me that the current model of development for the Linux kernel doesn't work very well.
Changes that were too experimental for a stable kernel but too important to be deferred to an experimental kernel were included in 2.4.x all the time (the VM changes in 2.4.10 being the best example).
This makes me wonder: isn't it possible to improve the scheme of x.even.y = stable and x.odd.y = unstable? Even as we speak the -ac series provides an experimental kernel within the stable series. Maybe we could enhance this model into something more official.
I'm not sure about the actual form yet. I was thinking about something in the line of three kernels:
Stable: users should be able to rely on this blindly. This kernel works. Each and every release.
Testing: this kernel should evolve into the next stable kernel. More ambitious than the current -pre kernels; longer running development and more testing. Yet, nothing really radically new.
Experimental: playground for hackers. New features are introduced here.
The 'Testing' branch is new. I imagine these kernels to be released every month or so, at about the rate the stable kernel is released now. As soon as the Testing kernel proves something works and it stable, it's up for inclusion in the stable kernel.
Stable kernels should IMHO be lower-paced. Maybe a major release every four to six months or so. The VM is allowed to change radically, but only after having been tested extensively in the Testing series. Offcourse simple bugfixes should be allowed in. This would give us a stable kernel every month. It just wouldn't be a terrible interesting one, as it should be.
The Experimental kernels are as experimental as the current x.odd.y series.
--
This is your sig. There are thousands more, but this one is yours.
I won't run 2.4.11
by
Stonehead
·
· Score: 4, Interesting
Just like the majority of you readers, I am not a kernel developer. But I like to know what I'm running. My conclusion is that if you want a stable kernel, ignore Linus' tree and use the Alan Cox tree. To say it blunt, 2.4.10+ really is 2.5, and you should only run it if you are prepared for some weird behaviour.
Now am I a troll? Hope not. I did get my info out of Kernel Traffic, which I've been reading for months. It is a very good, understandable and clear compression of all important things that happen on the linux kernel mailinglist. If you use Slashdot as your only information portal about the kernel, you are *braindead*.
Ok, now my point - it is the VM subsystem. By now you should know that 2.4.x, until recently 2.4.10, used the VM code by Rik van Riel. That code has taken some time to develop, but you definitely can't blame Rik as the cause for all 2.4 stability problems, as well as the eternal delay of 2.5. But according to the l-k list, Linus himself made several errors in including Rik's patches, which indeed caused 2.4.7 and up to be unstable! Ok, now stop and think about this. Linus has an enormous responsibility. He didn't realize where the fault was, but he did perceive that the stable kernels were NOT stable. He knew that Andrea Arcangeli was still working on his own VM (that work improved Rik's VM too in 2.3. Not having a monopoly really does improve invention!) Then Linus made the big step: even in a *stable* series, he took over Andrea's VM and threw out Rik's one. This is really an important decision, and I applaud it!
The only thing Linus should not have done, is labeling this thing 2.4.10. It really is 2.5. For the big public, that kernel was definitely everything but a stable kernel. Luckily a lot of problems have been solved since (2.4.11 is a hell of a lot better than 2.4.10), and I consider Andrea Arcangeli really a good coder, but actually I trust Alan Cox most. He commented that Linus' recent kernels trashed several boxes of his overnight. Alan really sees the -ac tree as the stable one currently. I run 2.4.9-ac18 too, with the kernel preemption patch as mentioned earlier, on a p2-233 with quite some load, and it doesn't show any strange behaviour. (The kernel preemption patch doesn't do really much here: I still get skips when I record an mp3 from my soundcard and switch desktops in the meantime. But I should not expect wonders:))
One last thing: Rik van Riel's VM has improved *too*. Alan Cox catches up with his patches very speedily. No more big bugs; Rik even added some optimizations in 2.4.9-ac16. I can't see that of course, but overall the system is a lot more responsive than 2.4.3-pre6, my last kernel before this one.
So my advice: use the ac-series of the kernel. Linus has made some wise decisions. I think he should start 2.5 and leave 2.4 to Alan, before people go sulking about 2.4.10 versus the always-stable reputation of the Linux kernel.
Slashdot Mirror
The Preemptible Kernel patches can result in a desktop that reacts/feels faster... I'm running it here with 2.4.10 on an Inspiron 4000 laptop and I'd have to say I'm impressed - everything feels a bit zippier. The only problem I've had is that there seems to be some loop that it has optimized that blasts bits around the memory bus at high speeds with a rthymic pattern - in short if I'm in a really quiet room the high pitched busses are a bit noisy... Maybe my hearing is too good!
Anyway - doesn't look like much changed since pre-6 so the pre-6 patches should work but if you want to be sure you can wait until rml releases the 2.4.11 final patch. I'd recommend checking it out if you have the time...
So - - - Is that the case? Has there been any stability problems? Is the performance better (not that it really matters as a workstation user, but . .. )
Any sufficiently advanced technology is indistinguishable from a rigged demo
--Andy Finkel (J. Klass?)
There are a few changes to the emu10k1 driver that may affect you:
- Mixer improvements (should add support for treble, bass, volume, and others).
- Fixed a dead lock in emu10k1_volxxx_irqhandler.
- Small code cleanup.
w o r l d w i d e w e b e r
The two trees are very different in certain cases, and are likely to stay that way for a while.
The -ac tree has the following major additions:
- Uses the Riel VM (Linus uses AA)
- 32bit uid safe quota
- Ext3 file system
- PnPBIOS support
- Various PPro and Pentium workarounds
- Simple boot flag
- Faster x86 syscall path
- PPPoATM
- Elevator flow control
- DRM 4.0 and 4.1 support not just 4.1
- CMS file system
- Intermezzo file system
- isofs compression
w o r l d w i d e w e b e r
It is also interesting to note that Rik's vm core has had say 15 kernel releases (unstable + stable) to become stable and meet up to the expectations that Rik sold the kernel hackers on in the first place and judging from the reports on LK it is just now becoming stable enough for most work loads.
The new 2.2.10+ VM had a couple minor to moderate problems for _SOME_ work loads but over all has received very good reports as far as I can tell for being so new. 2.4.11 is bound to be even better.
Some people are complaining about the inclusion of major VM modifcations in the stable tree. I believe the truth is that most people that use Linux in production do not roll their own kernels. They use the vendor supplied kernels. Redhat for example will be releasing a 2.2.7-11-AC kernel which uses Rik's VM, it is what they have been testing for months and thus is what they will end up shipping. So the fact that Linus made this change in the "Stable" tree makes very little difference to me from a stability stand point, and I think it will prove to be a very good call in the short/medium/long run.
Thats my 2 cents anyways.
-- You can be a geeklord too
Unfortunately that picture is not at all of Andrea Archangeli, who is most definitely male. Sorry.
AC kernels? Now THAT's open source at its best. I mean just think Annonymous Cowards writing an OS, and they don't even know each other....
Fish
During the stable life of 2.4.x it became more or less clear to me that the current model of development for the Linux kernel doesn't work very well.
Changes that were too experimental for a stable kernel but too important to be deferred to an experimental kernel were included in 2.4.x all the time (the VM changes in 2.4.10 being the best example).
This makes me wonder: isn't it possible to improve the scheme of x.even.y = stable and x.odd.y = unstable? Even as we speak the -ac series provides an experimental kernel within the stable series. Maybe we could enhance this model into something more official.
I'm not sure about the actual form yet. I was thinking about something in the line of three kernels:
- Stable: users should be able to rely on this blindly. This kernel works. Each and every release.
- Testing: this kernel should evolve into the next stable kernel. More ambitious than the current -pre kernels; longer running development and more testing. Yet, nothing really radically new.
- Experimental: playground for hackers. New features are introduced here.
The 'Testing' branch is new. I imagine these kernels to be released every month or so, at about the rate the stable kernel is released now. As soon as the Testing kernel proves something works and it stable, it's up for inclusion in the stable kernel.Stable kernels should IMHO be lower-paced. Maybe a major release every four to six months or so. The VM is allowed to change radically, but only after having been tested extensively in the Testing series. Offcourse simple bugfixes should be allowed in. This would give us a stable kernel every month. It just wouldn't be a terrible interesting one, as it should be.
The Experimental kernels are as experimental as the current x.odd.y series.
This is your sig. There are thousands more, but this one is yours.
Just like the majority of you readers, I am not a kernel developer. But I like to know what I'm running. My conclusion is that if you want a stable kernel, ignore Linus' tree and use the Alan Cox tree. To say it blunt, 2.4.10+ really is 2.5, and you should only run it if you are prepared for some weird behaviour. :))
Now am I a troll? Hope not. I did get my info out of Kernel Traffic, which I've been reading for months. It is a very good, understandable and clear compression of all important things that happen on the linux kernel mailinglist. If you use Slashdot as your only information portal about the kernel, you are *braindead*.
Ok, now my point - it is the VM subsystem. By now you should know that 2.4.x, until recently 2.4.10, used the VM code by Rik van Riel. That code has taken some time to develop, but you definitely can't blame Rik as the cause for all 2.4 stability problems, as well as the eternal delay of 2.5. But according to the l-k list, Linus himself made several errors in including Rik's patches, which indeed caused 2.4.7 and up to be unstable! Ok, now stop and think about this. Linus has an enormous responsibility. He didn't realize where the fault was, but he did perceive that the stable kernels were NOT stable. He knew that Andrea Arcangeli was still working on his own VM (that work improved Rik's VM too in 2.3. Not having a monopoly really does improve invention!) Then Linus made the big step: even in a *stable* series, he took over Andrea's VM and threw out Rik's one. This is really an important decision, and I applaud it!
The only thing Linus should not have done, is labeling this thing 2.4.10. It really is 2.5. For the big public, that kernel was definitely everything but a stable kernel. Luckily a lot of problems have been solved since (2.4.11 is a hell of a lot better than 2.4.10), and I consider Andrea Arcangeli really a good coder, but actually I trust Alan Cox most. He commented that Linus' recent kernels trashed several boxes of his overnight. Alan really sees the -ac tree as the stable one currently. I run 2.4.9-ac18 too, with the kernel preemption patch as mentioned earlier, on a p2-233 with quite some load, and it doesn't show any strange behaviour. (The kernel preemption patch doesn't do really much here: I still get skips when I record an mp3 from my soundcard and switch desktops in the meantime. But I should not expect wonders
One last thing: Rik van Riel's VM has improved *too*. Alan Cox catches up with his patches very speedily. No more big bugs; Rik even added some optimizations in 2.4.9-ac16. I can't see that of course, but overall the system is a lot more responsive than 2.4.3-pre6, my last kernel before this one.
So my advice: use the ac-series of the kernel. Linus has made some wise decisions. I think he should start 2.5 and leave 2.4 to Alan, before people go sulking about 2.4.10 versus the always-stable reputation of the Linux kernel.
Soo... what you're saying is that the Linux version acts exactly like the MS one? Most exellent.