Slashdot Mirror

← Back to Stories (view on slashdot.org)

Preemptible Kernel Patch Accepted

Posted by michael on from the a-little-Love-for-everyone dept.

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

4 of 352 comments (clear)

  1. Tradeoffs? by chuckw · · Score: 4, Interesting

    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*
  2. Scalability of a pre-emptible kernal? by Maddog_Delphi97 · · Score: 4, Interesting

    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.

  3. Other arches? by saintlupus · · Score: 4, Interesting

    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

  4. Can you say "Re-inventing the wheel?" by Mr+Z · · Score: 5, Interesting

    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.

    --Joe
    --
    Program Intellivision!