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 day in the life of a kernel hacker.
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.
I've been waiting for years for Linux to have finer control of process scheduling.
I hope someday that Linux will use a method similar to Irix, where you can specify a priority from 0 to 255, modify it's timeslice, and make it realtime or timeshared. This was one of the best things about Irix, and something I could really use for Linux.
I really like reading things like this.
That's why Linux is so great -- even if you're not good enough to work on the kernel, you can read about some of the issues that pop up. If you use Linux for awhile, and if you get to the point where you roll your own kernels and apply patches, you end up learning a lot about how the system works.
The MS guys are smart, and they're making some good systems now, but you can spend your whole life with them and not have much of a clue about what's going on under the hood.
If MS would open up their internal developer discussions to the public, it would take MS system administration to a whole new level. I understand why they can't do that, but it is a great example of what's nice about Linux.
"With an internally preemptible kernel the explicit task yielding is not necessary, because the context switch is performed in the interrupt return path and 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."
:)
Try getting your head round that one when needing sleep
The difference is that hard real time doesn't mean low latency it just means that there is a _guaranteed_ maximum latency.
Soft real time means that you can almost gaurantee the latency. Generally, of course, you want these latencies to be pretty small. Soft real time is for when you use check the "use real time where available" option on xmms and run it under sudo.
I hear that Linux (probably with patches) is a little better than windows and a little worse than os X for latency.
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.
"The low-latency patch yields worst-case latencies of around 1.5 milliseconds at present. The preempt patch is around 80 milliseconds,
but with the locking changes it should also yield 1-2 millisecond latencies." On what speed processor? 1.5ms is way too long for any kind of processor being sold these days. Try 100us maximum latency on a 133Mhz Pentium for starters and go down from there. And learn to use the term "deterministic" and I might raise an eyebrow. Make it POSIX 1003.1 compliant and someone will have a serious solution.
Programmers either need deterministic response in their applications or they don't. If they do, then Linux is not their OS. If they don't, then these half-baked solutions to reduce context switching time and interrupt latency are probably going to be fun to play with, but will cause nightmares in the long run.
Andrew Morton And The Low-Latency Kernel Patch
:)
.)"
Sounds just like a title of a bedtime story.
I also recommend you read "How CowboyNeal saved the world (with a little help from / and
IMHO, SoftUpdates are better than Journalled File Systems. There's no journal file to maintain, just careful ordering of the writes. Why no discussion of it for Linux?
You want your autopilot to never have a task scheduler? Obviously you have no experience in embedded systems design at all, or you wouldn't say something so blatantly stupid. I'm sorry, but that's just rubbish.
In EVERY embedded application, there's multiple layers of stuff happening, ranging from ultra-high priority interrupts that need micro-second accuracy scheduling, down to background loop stuff that doesn't need to be done more often than every few seconds. Every embedded system uses this approach.
A single loop running round is fine if your code needs to do nothing more complex than a Windows program, which any 16-year-old kiddie can write. The moment it breaks this complexity, you're screwed. For example, consider a car engine controller (which I design software for, BTW). Scheduling the start and stop times for injector and ignition pulses requires the processor to recalculate the times a fraction of a second before the pulse, to make sure the fuel and ignition pulses are accurate for the current conditions. And importantly, the number of times you need to do this changes with engine speed, since you need to update every engine rev. It is unacceptable to burden this ultra-fast processing with stuff which doesn't need to be run 7000 times a second, eg. toggling the indicators.
So the solution is to go to a multi-rate system. Stuff which needs to run fast, runs fast; stuff which can run slow, runs slow. This frees up processing time for the fast stuff which can then handle more iterations per second. And in order to work this, you need something to tell all your functions when to run. Sometimes it's designed as part of your main application, sometimes it's a separate bit of object code bought-in, but it's always required. Even your autopilot will be doing this - as a minimum there'll be a fast loop controlling the aircraft, and a slow loop sending info back to the pilots.
So there's many different task rates, all running at their own time frame. For example, in the Ford project I'm working on currently, there's a task happens twice per rev to schedule fuel and spark, there's another task happens once per cam, and there's time-based tasks at 10ms, 16ms, 32ms, 50ms and 100ms rates. And this allows us to allocate resources to the processing that needs it, such as critical tasks like keeping ppl alive.
Grab.