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."
I thought that the preempt patch was quite a way from being part of the linus tree. On the other hand, early in a development kernel is probably the right place to integrate it, so that all those device drivers with problems with the preempt stuff (like NE2000, I think) can get fixed.
Napster-to-go says "Fill and refill your compatible MP3 player", which is a lie. It's not MP3. It's WMA with DRM.
If you don't like it, treat it the same way as SMP...turn it off!
The fact that this is built into the kernel means that we don't always have to go out and download patches to change this. I would assume that vendors using the Linux kernel would make decisions on how to compile the kernel to suit their environment.
There are lots of people that are frustrated by the current need to go and get patches to change this. Incorporating it into the main kernel should be very positive, IMHO.
Aside from the technicalities of this particular patch, your assumption that you're going to lose something when you apply a beneficial patch because 'you don't get anything for free' is, despite appearing mature and clueful, way off mark.
The cost doesn't have to be borne by the end user. The cost can be developer time / clues. In the Free Software world, you do get that for free.
Yours Sincerely, Michael.
"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."
Actually, I would think it would be the opposite. Being able to preempt within the kernel can pretect you against a DOS attack where a process repeatedly makes long running kernel calls. That would give that process more than it's fair share of time, and other processes couldn't respond to interrupts as well. Without a fully preemptable kernel, you can't guarantee how long a process can run, because it is impossible to preempt them while they are in a kernel call.
-no broken link
Consider, however, the case where the reason a task is preempted in the kernel is that it has used all of its timeslice. Without the preemptable kernel patch, the task cannot be interrupted to schedule another task. In order to make guarantees about how much time will be given to each process, it needs to be possible to stop a process when its time is up essentially no matter what the process is doing.
The issues you raise are a matter of scheduling policy, not of whether the kernel is preemptible. Furthermore, for most interactive tasks, the correct behavior is to react quickly, because those tasks haven't used up their timeslices, since they blocked waiting for input. In this case, interactive processes give up the CPU to wait for input, and then get their time back as soon as they have a use for it.
Of course, this all also applies to tasks which "interact" with the network or the hard drives, which is any task when you have swap space. Processes which are waiting on input want to run as soon as their input is ready, and don't care about time before that. Processes which are not waiting on input want to run as much as possible, and don't care exactly when. Having the scheduler's instructions followed as closely as possible benefits both kinds.
Not quite true - some Linux patches give unilateral improvement. But I do see your point.
None of the other responses to this thread (that I've noticed) addressed one tradeoff: complexity and bugs. Ever since Linux started to support SMP systems, SMP kernels have been somewhat buggier than UP kernels. This is because there are a lot of potential mistakes to be made - getting and releasing spinlocks and semaphores at the right places is not trivial stuff. Of course bugs have been fixed over the past several years, and SMP is now considered a standard Linux feature (in 2.0 it was "experimental"), but there are still no doubt lots of SMP bugs in some of the more obscure device drivers.
The problem with the preempt patch is that it introduces all these potential bugs into a standard non-SMP kernel, since preempt uses much the same basic mechanism as SMP. Most people only have one CPU, but now these people will be exposed to the same "increased level of risk" as SMP systems.
In a way, that could be considered a benefit - this may serve to flush out some of those last remaining SMP bugs. The SMP code paths will be exercised by a lot of people now.
"How can you claim that you are anti-crack, while still writing a window manager?" — Metacity README