An interview with Robert Love is at KernelTrap. Robert is author of the kernel preemption patch which has been merged into the 2.5 development kernel. In this interview, Robert discusses the status of Linux kernel preemption, talks about his recent involvement with the O(1) scheduler and explains his recent VM overcommit work. He also reflects upon Linus’ use of Bitkeeper, the future of Linux, and the recent Kernel Summit in Ottawa.
Out of curiosity, why would one want to have a preemptable kernel? What does that buy you, exactly?
“JA: Is there any recent or near-future development outside of the kernel that you find interesting?
Robert Love: GNOME2 is amazing!
Metacity (a new GNOME2-compliant window manager) is very slick and quite quick. Havoc is a genius!”
So true.
better performance
It brings better UI responsiveness (similar to what BeOS had, but not as extreme).
A preemtable kernel will reduce the speed for a server (throughput goes down), but it makes a desktop-only installation to respond better and not skip mp3s when there is high load and stuff like that.
AFAIK, the preemptable patch is an option in the new kernel, when you compile it, it is not ON by default, as Linux’s primary focus is the server market.
The guy is in college -just finished his SECOND year he says. And he still has een able to write kernel-level code!! I wonder if he gets laid ???
I wish all the paper-smart whinies here could sit down and write some code instead of whining
To answer the first poster’s question. A preemptible kernel basically means that a task running in the kernel can’t block a higher priority task. Say, for example, you have a low priority task (a compiler instantation) and a high priority task (an audio thread) running at the same time. The audio thread is asleep, waiting for its next chance to feed the soundcard some data. Thus, the compiler thread gets to run. It invokes a lengthly kernel call, and in the middle of it, the audio thread wakes up. Now, in the stock 2.4 kernel, the compiler thread has to finish the kernel call and leave kernel mode before the audio thread will get a chance to run. In fact, the compiler thread (running kernel code now) will get to keep the CPU as long as it wants, and the scheduler will never take it off the CPU. The net effect is that for long kernel procedures (and some of them are several hundred milliseconds in length) a low priority thread can effectively block a high priority thread. That leads to lost audio/video frames and a jerky GUI. With the preemptible kernel patch, being in kernel mode does not automatically lock a thread onto the CPU anymore. If a higher priority thread becomes ready to run, scheduler will remove the currently running thread from the CPU even if it is running kernel code. Thus, the high priority thread gets to run when it needs to. The danger of this is that a non-preemptible kernel simplifies kernel programming. The developers don’t have to worry as much about locking, because they know that no-one else will get the CPU (and potentially mess up some data structure they were working with) until they are done. Of course, this is a very similar situation to what happens with SMP systems. Since there are multiple CPUs, proper locking is required whether the kernel is preemptible or not. The preempt patch hooks on to the fact that locks exist all over the kernel already to support SMP. It then disables kernel preemption whenever a spinlock (a type of busy-wait lock in the kernel) is being held. For those waxing back to BeOS nostalgia, this was one source of the requirement that interrupts be disabled whenever you were holding a spinlock. With interrupts disabled, the scheduler would not run, and your thread could not be preempted. More detailed information about the patch is available at: http://www.linuxdevices.com/news/NS3989618385.html
More information here:
http://www.linuxdevices.com/articles/AT5503476267.html
Rayiner, that was a great explaination.
Rayiner’s explanation seemed to imply that the kernel in Beos is preemtible. Is that right?
Yes, indeed.
Do any other strains of Unix, or even Win XP, have that feature?
The original unix did not have this feature, no. I am not sure that any other unix later implemented anything similar to BeOS either… Not sure about XP, but XP seems to be in between of a server and desktop OS speed-wise, so they might have implemented something like that.
The NT Kernel has been preemptible since at least NT 4.0.
Robert raises an interesting point about the direction of Linux.
JA: Do you have any concerns over the future direction of the Linux kernel?
Robert Love: Yes, at times I am scared of what the high end work will do to the common case. You either scale to 128 CPUs or you run great on one or two. You either optimize for a few running tasks or you have a system with 1000 ready database threads.
I truly believe that one of the main problems with Microsoft’s design approach with NT (this includes W2K & XP as well) is that they are trying to fulfill the needs of everyone from the same code base (Workstation, Server, Advanced Server, etc).
Some code could certainly be used across product lines, but the fact that a Server OS runs it’s graphics sub-system in kernel mode so that the windowing system is more responsive is silly. This is great for a Workstation product, but why would you want this added risk for a server OS?
If we expect the same kind of diversity from Linux (Embedded, Desktop, Laptop, Workstation, Workgroup Server, Mid-Range Server, Enterprise App Server, MainFrame), I suspect that most of us will end up pissed off that it doesn’t work as well as another OS that has focused on one or two domains.
Think about this the next time you question whether Linux will ever be ready for the desktop. Should it be? Where should the focus be? Afterall, creating a document in a word-processor has nothing in common with controlling a satellite or supporting thousands of concurrent users submitting queries to a terabyte sized database. These are very different problems with – I suspect – very different solutions. Linux should be able to excel in some of these areas, but we certainly shouldn’t expect it to excel in all of them.
Solaris, HP-UX and AIX have preemptable kernel.
I would say any solid SMP capable kernel has it.
Practically, any modern OS where SMP wasn’t introduced as a patch was designed with it from beginning.
BeOS had it.
NewOS (and so OBOS) have it.
I’m not sure about FreeBSD and Windows is a crap of it’s own – Microsoft has enough of good coders to make it but the design is dictated by management and who knows what compromises went into latest version of Windows kernel.