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
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.
How often do you see a Windows Kernel Update?
by
AnimeFreak
·
· Score: 1, Insightful
Whenever Microsoft wants more money from it's OS.
Oh wait, according to them Internet Explorer is their kernel.
Re:VM Changes
by
Trepalium
·
· Score: 2, Insightful
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)
The sooner Redhat stop leveraging its collection of kernel hackers to drive Linux kernel development the better for the rest of us that don't care for their crappy distribution.
I don't think RedHat had ANYTHING to do with Alan's objections. For one, numerous people have reported severe stability problems with Andreas' VM, which are things that simply should not occur in a so-called "stable" kernel. This kind of experimentation should be occurring in 2.5, not 2.4. The problem is that the VM got almost no testing before being rolled into 2.4.10. The same was true of ReiserFS when it was introduced into 2.4 -- it, too, had a number of problems, including stability and data integrity problems. Rik's VM is not very good, granted, but 2.5 is the proving grounds for new features, not 2.4.
-- I used up all my sick days, so I'm calling in dead.
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.
As you already said, it is on kernel.org. Unfortunately, it seems to be missing on the mirrors at this point. At least the patch from 2.4.10 to 2.4.11 was missing the five or six times I tried ftp.us.kernel.org (at which point I gave up and hit ftp.kernel.org)
Maybe that's why it wasn't 'announced' yet on www.kernel.org: mirrors hadn't picked it up yet.
-- Jesus was all right but his disciples were thick and ordinary. -John Lennon
NTFS, NTFS, NTFS boys. In a year or two most systems out there will have it in XP, and Linux will be catching up to support it. We can make a run for a majority of the NTFS 5.0 changes now, so at least people will be able to access their drives.
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.
"Stable" Versioning
by
labradore
·
· Score: 2, Insightful
I don't think that anyone takes the kernel versioning as seriously as they used to. I thought that stable kernels were not supposed to include any really new core features but mostly just bug fixes and perhaps new drivers, etc.
Rik's VM should have either showed up in the 2.3 tree and been stabilized there before entering 2.4 or the 2.5 tree should have been opened with it. I guess since 2.4 had to be pushed out the door (and I'm glad it was) there was no time for his VM to mature inside 2.3. But would it be worthwhile to let those ideas stagnate? So much really new activity has been going on since 2.4 that perhaps it would be too hard to manage 2.4 and 2.5 kernels with lots of active development going on both simultaneously.
It seems to me to be a hard management decision to make. The 2.4 series needed a lot of fixes and at the same time there has been a lot of new stuff floating around. Would introducing the 2.5 a few versions ago have slowed development on 2.4 and increased overall patch-management headaches? I suppose the answer is yes but I don't have an idea about how badly it would slow things down.
I do think, however, that it is wonderful to have both Linus and Alan Cox around and maintaining diverging credible trees. They can both gain perspective watching the other's code grow and break. When the two trees do finally merge again we (hopefully) will have the best characteristics of both.
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.
Stable branch or not.
You really should NOT run production servers (the ones at work anyway) on the latest and greatest kernels.
Who knows what data corrupting bugs are in a new kernel? I recall a few years back when a kernel was released in the that corrupted data over time. (Albeit that was in the testing branch, 2.1.44, but it's a matter of principle).
At least set it up on test servers first before launching on production servers.
Do yourself (and us) a favour, try before you buy.
Production boxes using vendor kernels?
by
A+Masquerade
·
· Score: 3, Insightful
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.
Anyone running a production set worth their salt
will be running their own kernel base, tuned for
their own environment. The vendor kernels are a
compromise, trying to please everyone, with every
service you could ever imagine compiled in (and hence every bug/exploit included). Production boxes doing serious work are more likely to have a kernel set built for the purpose.
Vendor kernels are far more likely to be used by people who are not that bothered about kernels and stability
FWIW my production boxes run a 2.2.19 heavily patched.
Re:Thoughts on the 2.4.10+ VM
by
Anonymous Coward
·
· Score: 1, Insightful
2.4.10 is the only kernel in the series since 2.4.2 that I have been ABLE to even RUN on a daily basis
Which is nice, yet as soon as even one user reports a problem this is a condition to look into. No problems here means nothing more than your usage profile is just one that does not trigger lurking bugs. One cannot argue away flaws.
Re:reasons to upgrade..
by
tao
·
· Score: 2, Insightful
XFree 4.1 requires a v2.4.10 or v2.4.11 kernel to use DRI/DRM. On the other hand, Xfree 4.0 doesn't work with v2.4.10/v2.4.11.
Other than that, the need for upgrading is mostly if you experience problems or have new
hardware.
AFAIK you can use make rpm to build
an RPM of your kernel nowadays (new in v2.4.(some number > 3). For Debian, the counterpart is ake-kpkg which has existed
for ages.
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...
Whenever Microsoft wants more money from it's OS.
Oh wait, according to them Internet Explorer is their kernel.
I used up all my sick days, so I'm calling in dead.
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.
As you already said, it is on kernel.org. Unfortunately, it seems to be missing on the mirrors at this point. At least the patch from 2.4.10 to 2.4.11 was missing the five or six times I tried ftp.us.kernel.org (at which point I gave up and hit ftp.kernel.org)
Maybe that's why it wasn't 'announced' yet on www.kernel.org: mirrors hadn't picked it up yet.
Jesus was all right but his disciples were thick and ordinary. -John Lennon
NTFS, NTFS, NTFS boys. In a year or two most systems out there will have it in XP, and Linux will be catching up to support it. We can make a run for a majority of the NTFS 5.0 changes now, so at least people will be able to access their drives.
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.
Rik's VM should have either showed up in the 2.3 tree and been stabilized there before entering 2.4 or the 2.5 tree should have been opened with it. I guess since 2.4 had to be pushed out the door (and I'm glad it was) there was no time for his VM to mature inside 2.3. But would it be worthwhile to let those ideas stagnate? So much really new activity has been going on since 2.4 that perhaps it would be too hard to manage 2.4 and 2.5 kernels with lots of active development going on both simultaneously.
It seems to me to be a hard management decision to make. The 2.4 series needed a lot of fixes and at the same time there has been a lot of new stuff floating around. Would introducing the 2.5 a few versions ago have slowed development on 2.4 and increased overall patch-management headaches? I suppose the answer is yes but I don't have an idea about how badly it would slow things down.
I do think, however, that it is wonderful to have both Linus and Alan Cox around and maintaining diverging credible trees. They can both gain perspective watching the other's code grow and break. When the two trees do finally merge again we (hopefully) will have the best characteristics of both.
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.
Stable branch or not.
You really should NOT run production servers (the ones at work anyway) on the latest and greatest kernels.
Who knows what data corrupting bugs are in a new kernel? I recall a few years back when a kernel was released in the that corrupted data over time. (Albeit that was in the testing branch, 2.1.44, but it's a matter of principle).
At least set it up on test servers first before launching on production servers.
Do yourself (and us) a favour, try before you buy.
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.
Anyone running a production set worth their salt will be running their own kernel base, tuned for their own environment. The vendor kernels are a compromise, trying to please everyone, with every service you could ever imagine compiled in (and hence every bug/exploit included). Production boxes doing serious work are more likely to have a kernel set built for the purpose.
Vendor kernels are far more likely to be used by people who are not that bothered about kernels and stability
FWIW my production boxes run a 2.2.19 heavily patched.
Which is nice, yet as soon as even one user reports a problem this is a condition to look into. No problems here means nothing more than your usage profile is just one that does not trigger lurking bugs. One cannot argue away flaws.
XFree 4.1 requires a v2.4.10 or v2.4.11 kernel to use DRI/DRM. On the other hand, Xfree 4.0 doesn't work with v2.4.10/v2.4.11.
Other than that, the need for upgrading is mostly if you experience problems or have new hardware.
AFAIK you can use make rpm to build an RPM of your kernel nowadays (new in v2.4.(some number > 3). For Debian, the counterpart is ake-kpkg which has existed for ages.