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: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: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.
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).
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.
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...
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!"
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
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.
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).
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.