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

Comments

Re:Will this apply to X Windows?

[sinserve]

This must be a bottle-neck in the GTK signal
routing code; I beleive it could be eliminated with
some manual optimization (i.e. loop unrolling, and
inline assembler.)

file it as a bug, and let the developers take a look
at it. I am using a GHz machine, so I don't notice
the 2D math calculations. Or maybe, my monitor/gfx card
have higher refresh rates.

Re:Tradeoffs?

[chuckw]

despite appearing mature and clueful, way off mark.

No, despite trying to sound like the wiser one, you are way off the mark. If this was just a patch that unplugged a logjam it would have been applied a very long time ago. No, it took time because there were tradeoffs. Yes, those tradeoffs may not be entirely tangible or even noticeable by the end user, however there *are* tradeoffs.

For more proof, I'll direct you to the large number of clueful responses to my original question.

Re:Tradeoffs?

[RelliK]

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.

False. There *is* a tradeoff. And you probably want to take an Operating Systems course before spewing "there is no tradeoff with Free Software" nonsense. (BTW, I wanted to ask the same question).

Anyway, here is how it works: a ready, higher-priority process can kick off a running, lower priority process before the running process's time slice expires. This does indeed improve responsiveness so that your machine "feels" (*)faster, but in reality it actually runs slower. The cost of pre-emptible kernel is that it does more process switching than a non-preemptible one (see above, it can (and does) interrupt a process before its time slice is finished). More process switching requires more CPU time, concequently, less CPU time is spent on actually doing work. So yes, the good thing is that it decreases latency (hence better responsiveness). But the bad thing is that it decreases throughput (the amount of work actually done) because of the increased process switching overhead.

(*) The reason your machine "feels" faster is that the GUI becomes more responsive. But that is pure illusion! Your machine actually does less work. Thus, the pre-emptible kernel patch would probably be useful for workstations, but you definitely don't want to use it on a server.

So the question becomes: what is the throughput/latency tradeoff with the current implementation of the preemptible kernel?

Re:Tradeoffs?

[chuckw]

Oh come on sydb you coward give me a kiss :-)