Slashdot Mirror
Andrew Morton And The Low-Latency Kernel Patch
An Anonymous Coward writes: "KernelTrap has interviewed Linux kernel hacker Andrew Morton, author of the low-latency patch. Though his patch has received less attention than Robert Love's preemptible kernel patch (recently merged into the 2.5 kernel), it results in quite significantly lower latencies. The interview is quite interesting, delving into the low-latency patch, explaining how it works and the differences between it and the preempt patch. He also talks about his ext3 work, porting that journaling filesystem from the older stable 2.2 kernel to the current stable 2.4 kernel."
A realtime os, which usually has low latency, has nothing about the duration of latency, but rather a guarantee of latency.
For example, suppose you send a packet off into the internet, a realtime os would guarantee that the packet was sent within x number of nanoseconds. A realtime os would main this guarantee, regardless of the load on the system, the size of the packet, etc.
Is there a formal difference between low latency and a realtime OS?
Yes. A realtime OS _guarantees_ that certain events trigger defined responses within specified times. A realtime OS is almost by definition an embedded OS, i.e., its hardware is rigorously specific and very tightly bound. A realtime OS also typically provides a very limited set of functions, as opposed to a general purpose OS. A low-latency OS, on the other hand, provides generalized structures for 1st-level/2nd-level interrupt handlers, real/virtual memory management, and facilities for locking, preemptive-priority dispatching, etc., but offers low latency on a merely best-efforts basis depending upon what all happens to be inflight at the moment. See the difference?
Examples of realtime systems: automotive control systems including engine power/emissions management, suspension and braking management, even airbag controls; aircraft fly-by-wire systems that control aerodynamically unstable airframes.
Examples of low-latency systems: mainframes - if you're a high-priority system task, you get _very_ low latencies - but exact timings aren't guaranteed in all situations.
From my experience, NT doesn't so much have a guaranteed latency time as a probable crash time.
This is NOT a troll, NT makes it VERY hard to meet any true real-time requirements without writing at the driver level, which is a massive pain, and exposes you to BIG risks in destabilising the machine.
Linux currently (without these patches) has very good average latency, with these patches it has fantastic worst-case latency, windows CE (which is supposed to be real-time) cannot match it.
Windows hides behind it's multimedia guaranteed latency capabilities, fine if you want to do multi media, useless if you need machine control, or other real-time requirements.
"With an internally preemptible kernel, the explicit task yielding is not necessary because the context switch is performed in the interrupt return path via open-coded yields, which are hidden in the unlock code. But you cannot preempt an in-kernel process while it holds locks, so all the unlock, relock and fixup code is needed in either approach."
--Ben
Mach, especially micro-kernel mach, had sucktastic latencies. On the order of milliseconds to make a system call that, on a regular unix, would take microseconds. But, OS X is not micro-kernel, and being a multi-media machine, it is reasonable to assume that Apple tweaked it up for decent latencies. However, don't be surprised if the 2.5.x series was substantially fast than OS X. Predecessors to the low-latency work currently in the kernel were measured as providing better latency than BeOS on the same hardware and BeOS was famed for its low latency abilities.
When information is power, privacy is freedom.
Linux has been able to do what you describe (many priority levels, selectable real-time policies) for a long time. What Irix does have over Linux currently is scheduling of resources other than the CPU - disk I/O being the most important one.
On Linux, a low-priority process won't take much CPU away from a high-priority process... But if the low-priority process does a lot of disk I/O, it can cause significant delays in the high-priority process's own disk I/O. i.e. the notion of priority does not carry over to disk I/O. Whereas on Irix, you can set up a process to get a guaranteed level of disk bandwidth...
Look for this feature to appear in Linux soon though. The newly-introduced I/O elevator should make it easier to implement prioritization for disk I/O.
Yep, sounds familiar =).
Thankfully Andre Hendrick's IDE patch seems to find the optimal hdparm settings for a drive automatically - once I started using the patch, I got uniformly high transfer rates (20-30 MB/sec) without running hdparm manually.