Slashdot Mirror
Preemptible Kernel Patch Accepted
An Anonymous Coward writes: "The preemptible Linux kernel patch that was originally introduced by MontaVista Software and more recently championed by Robert Love has been merged by Linus Torvalds into the main linux development-kernel tree, beginning version v2.5.4-pre6. This adds a far greater degree of real-time responsiveness to the standard Linux kernel, by reducing
interrupt latencies while kernel functions are executing. The story at LinuxDevices.com includes comments by Robert Love, and there is also a recent interview with Robert Love about the preemptable kernel here and a whitepaper about the technology by MontaVista here."
After watching traffic about this almost every day for several months, I can say that I agree with this inclusion and hopefully some of the Low - Latency patches will make it in as well.
$home =~ s/work/play/gi; nice -20 run $home;
It's really good that it was put in now instead of later. In fact, I really think the new VM should have waited for 2.5 as well. I just couldn't figure out why you'd change such a fundamental piece in the middle of a stable tree! But hey, I don't wear the Linus nametag; not my job.
This will be a good first step in reducing latency and increasing response time in X and other programs.
You can't legislate goodness. Let each to his own destiny, by will of his freely made choices.
I am interested to know if this will make the response time on X86free faster. So far from what I have noticed, comparing the way MS-Windows works where the GUI is running within the kernal, and how X runs non natively. I have seen significant lag between mouse clicks and on-screen response.
Example. Running XMMS and pushing play on an MP3 the video display and the sound are not synched. I am running a reasonable video card and sound card (Geforce 256 and a SB-Live) and I expect the video to work on the same scale and rate as the audio, like MS-Windows.
BTW, this has been one of the biggest complaints I have had against X86free and why I haven't completely made the transition to Linux yet. If this patch does in fact improve the response time of X86free, then I would be more likely to use it more often than I use XP.
You don't get anything for free. What is the tradeoff that occurs when you integrate this patch?
*Condense fact from the vapor of nuance*
What effect would a pre-emptible kernal have on the scalability of Linux?
As far as I can tell, a particularly responsive kernal wouldn't scale very well, since there wouldn't any guarantees as how much "time" as being spent on a thread/process by the CPU.
Think of a large, multi-user environment based on Linux. Do you really want any user to pre-empt the processing in the kernal by CPU to the detriment of other users? A more logical answer to this is to have set guarantees as how much processing time is given to each user. It shouldn't matter if it's one user or 2,000 users, the speed of applications for each user should stay the same as much as possible.
Maybe I'm describing Solaris, or some other operating system like this.
I know this is somewhat offtopic, however to make Linux more responsive, we need to improve X somehow. I am not saying that X sucks...I think it is a fantastic system
Anybody who uses X and Windows regularly knows the difference in responsiveness. X Windows does what it was for designed extremely well-- a client/server display system. However, due to the marshalling and de-marshalling of X calls, even if completely local, it will always be less responsive than other methods (winblows).
But I have an idea. Develop a system that implements the exact same interface as X but does no marshalling/demarshalling. Pixels can be written directly to the framebuffer. So you are thinking, "Yeah, but I want to use X apps without recompiling". Ok, use library interposition. This also allows you to use a "local" and "global" X library to maintain client/server capabilities. For those who aren't familar which library interpositioning, it essentially takes advantage of dynamic linking (set LD_LIBRARY_PATH on Unix). If you want to run a X program that directly writes to the framebuffer, then switch your LD_LIBRARY_PATH to a different directory before the program is executed. This could get annoying, but a Window Manager like Gnome could take care of this automatically.
Granted that our existing X server would have to be retrofitted to allow 2 different types of X libraries to update the same display to that we can run standard client/server X apps with the new "directXfree86" (no pun intended) apps.
However library interpositioning can be used to make X programs more responsive without sacrificing client/server capabilities and compatibility with existing applications (except those statically linked of course).
I compiled this into 2.4.17 with the preempt-kernel-rml-2.4.17-1 patch. When i booted i got PPP module errors, and when i tried to install the NVIDIA (2314/2313) drivers it gave me more errors. So i went back and disabled it...
Im looking foward to trying this patch out again when 2.4.18 comes out and i hope it works better.
-phinn
Has anyone tried this patch on non-x86 hardware?
I've got a Powermac 7200 I'm playing with YDL on right now...
(Note: I am not a programmer. Should this be something patently obvious to anyone with the most casual knowledge of OS programming, I still don't know. So don't flame me.)
--saint
Writing pixels directly to a frame-buffer is slow. You lose all of the acceleration features of your video card. Keeping as much of the protocol at a high level as possible is good. The only things that benefit from direct frame-buffer access are programs that do all their own rendering. (Think video decoders.)
Still, if you think about it, the basic gist of your idea is to get rid of the network channel from the communication protocol, and instead have the app talk directly to the X server, say, in shared memory. If so, then how does your idea compare to MITSHM and Shared-Memory Transport? Or the Direct Rendering Interface for that matter? And for 2-D stuff, let's not forget the Direct Graphics Architecture extension. Nothing stops GTK, Qt and friends from using any one of these technologies if they'd improve performance and latency.
--JoeProgram Intellivision!
I guess I reasoned that I would always have a sort of love/hate relationship with UNIX and its clones. Then when RTAI and RTLinux came along, that solved that, but it did so (I ASSUME) by philosophically thumbing its nose at UNIX tradition. Ok. So Linus decided to keep the default behavior not preemptable, which makes sense, but--given that the "Linus blessed" Linux version numbers have an optional preemption behavior built in--doesn't that mean a significant parting of company between the Linux kernel and UNIX as people know UNIX to be?
Yes, I know I'm pushing my own post, but I'd appreciate it if some moderator would either mod this post up or if someone would post similar information where it will get seen -- there's a lot of misinformation running around.
i ncoming-data issue I run into under Linux, but it won't make your windows drag more smoothly.
As for the "preemptability effect on users". Um...I have to say, not quite. There's a rather large difference between process-level preemptability -- which Linux has had forever...hell, Win95 has had forever -- and kernel-level preemptability.
The kind of stuff that a user can notice in normal use -- click on a different window in your desktop environment, takes a third of a second to do anything because it wasn't that app's turn to use the CPU -- derives pretty much completely from process level preemptability. In this kind of environment, the CPU is always pegged at 100%, switching between tasks if nothing else. Never happened in Linux. See classic MacOS or Win 3.1 for an example of this.
Kernel level preemptability exists completely to allow the kernel to switch away from some "long" (please understand that the kernel's idea of "long" is quite different from a human's) operation inside the kernel. These chunks of time are so small that they're really mostly relevant to tasks that need realtime scheduling (or as near to realtime as Linux can do), usually stuff in embedded systems. There are very few things that a desktop user will notice as a result of this patch (aside from probably some instability for a bit until everything gets ironed out). It might fix the polling-the-MIDI-port-makes-the-serial-port-drop-
This is a good thing, but not nearly as applicable as people are talking about.