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.
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: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.
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...
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.
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.
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.