Forgot your password?
typodupeerror
Linux Software

Non-Deathmatch: Preempt v. Low-Latency Patch 178

Posted by timothy
from the floor-wax-and-dessert-topping dept.
LiquidPC writes: "In this whitepaper on Linux Scheduler Latency, Clark Williams of Red Hat compares the performance of two popular ways to improve kernel Linux preemption latency -- the preemption patch pioneered by MontaVista and the low-latency patch pioneered by Ingo Molnar -- and discovers that the best approach might be a combination of both."
This discussion has been archived. No new comments can be posted.

Non-Deathmatch: Preempt v. Low-Latency Patch

Comments Filter:
  • by CathedralRulz (566696) on Friday March 22, 2002 @12:44AM (#3205646)
    The article doesn't mention this, but something some folks aren't aware of is that MontaVista is a serious linux partner with IBM. If the technologies described in the white paper can be merged, then the real effect can have a more significant impact in the embedded application/ PowerPC products from the World's 9th largest corporation.
  • by thesupraman (179040) on Friday March 22, 2002 @01:15AM (#3205760)

    One thing not mentioned so far is that one of THE largest scheduler latency problems comes from the driver for a PS/2 mouse, a very common item to be found plugged into servers which have no need for it. By removing the PS/2 mouse (and driver..) a significant latency improvement can be gained!

    It's a pity that most USB mice don't seem to provide quite the quality of use as the PS/2 items (although this is probably also a driver issue)

    Loy latency can be an advantage, but it is important that the cost of the lower latency is not an increase in total load, as in reality the lower latency does not provide a large gain in performance for most desktop or server roles, but rather is a measure more often used in real time systems, which it can make the difference between a system working or not.

    An example of this is in an ignition ECU for a V12 engine at 6000 RPM, a (pair of) plug is firing every 1/600th of a sceond (1.66ms), but the accuracy of the firing even must be in the order of 10us, which is not yet reachable be any 'standard' unix kernel, but quite easy to get on a much simpler ECU (I use an SH-2 at 24 MHz) than you would notmally find using a true real-time kernel.

    With some developments is may be possibly for a form of linux to reach this level, which would be fantastic, as a LOT of time is spent in embedded development providing 'operating system' level functionality around the actual application code, and with embedded processors getting faster, and memory getting cheap, embedding *nix has become much more of a possibility.
  • What's up with the degrading performance?

    It's called a bug - they'll figure it out. ;)

    it's not acceptable to reboot the machine every day to maintain performance

    Hey, it worked for NT4 admins, why not for embedded developers? *rimshot*

    Sorry. But seriously, anyone looking for hardcore low latency in Linux right now for systems that need that buzzword compliant "five 9's" should probably wait on using Linux until it's READY. Make no mistake, with as much interest and developer hours as are going into it, Linux WILL make it into this market, and it will succeed; it's merely a matter of time. (and hell, at this rate, it may not be long...)
  • Measuring latencies? (Score:3, Interesting)

    by acordes (69618) on Friday March 22, 2002 @02:18AM (#3205894)
    Here's a question. How do you go about doing fine grained measurements of these latencies? Every time I've tried doing timings with Linux I've had problems being able to get accurate, fine grained results.
  • by Anonymous Coward on Friday March 22, 2002 @04:16AM (#3206126)
    Check out this story [monolinux.com]. It was posted several hours before Slashdot got around to it.

    Pretty shameful for /.
  • Re:QNX vs. Linux (Score:2, Interesting)

    by Anonymous Coward on Friday March 22, 2002 @05:21AM (#3206262)
    "Interrupt and process latency

    All times given below are in microseconds (sec).

    Processor_______Context____Interrupt Latency
    Pentium/133_____1.95_______4.3
    Pentium/1 00_____2.6________4.4
    486DX4__________6.75_______ 7
    386/33__________22.6_______15

    With nested interrupts, these interrupt latencies represent the worst-case latency for the highest priority interrupt. Interrupt priority is user-definable and the interrupt latency for lower-priority interrupt sources is defined by the user's application-specific interrupt handlers. "

Suburbia is where the developer bulldozes out the trees, then names the streets after them. -- Bill Vaughn

Working...