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

Comments

Process scheduling

[lupetto]

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.

Re:Process scheduling

[rtaylor]

Yes, and no...

It'll waste CPU cycles all right. But if it makes the network, disk and interface responsiveness faster odds are the CPU will have more information to do processing with.

There are very very few CPU constrained jobs a computer does anymore. The ones that are (Graphics rendering, key cracking) either have the budget to add an extra machine per 100 to get back the 1%, or are already working with a timeframe that the timelost doesn't really matter.

If you wait 3 months for something, whats an extra 12 hours?

That said, I don't know how much this actually slows a conjested machine down. But, one of the large benefits of Solaris on Sun hardware is that you can get it up to a load of about 1000 before it starts to choke (become choppy). Sure, no task is moving quickly -- but they're all moving.

FreeBSD I find gets slammed around 150, and Linux (last I tried was 2.0.x) was around 60.

It's the type of stuff that makes Bigiron worth the money.

DISCLAIMER: Load numbers are by my own independent testing on varying hardware. It was a large Sun box, but not an order of magnitude above the Linux / BSD one. Test consisted of FTP connections downloading varying sized files at varying speeds.

Re:This is a great example of why I love Linux

[Anonymous Coward]

Did you see that guy from Sun talking about why Sun has chosen to go with Linux? He said that part of it had to do with Linux's fabulous 30% growth rate per year--the fastest in the history of computing. With no end in sight, Linux keeps getting bigger and better. Linus might have been kidding, but world domination is a pretty realistic objective right now, especially since Linux now accounts for almost half of the server market.

Why not SoftUpdates for Linux iso Journalling?

[redelm]

I've used Kirk McKusick's SoftUpdates for *BSD and been very impressed. Pulled the plug on four kernel compiles near the end. In three of the four cases, `make` just picked up the compile losing ~45 seconds. In the fourth, a `make clean` was necessary. In _all_ cases the fsck on reboot was minor. I've only lost power once in Linux during a kernel compile. I had to reinstall. It was too far gone for e2fsck.

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?

Re:It's a baby step, so what's the big deal?

[Chirs]

Think about this for a minute. Linux runs on all kinds of hardware. There are some severely broken hardware interfaces out there that require interrupts to be turned off for substantial amounts of time.

As mentioned in the interview, this (and the preempt patch) are mostly aimed at the audio world, where a couple ms latency is no problem, but more than a few becomes problematic.

Finally, if you have total control over the hardware that you're running on it is possible to get better than the stated performance, simply because you know what software will be running and can profile it yourself.

Re:realtime?

[Grab]

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.