Slashdot Mirror
Robert Love, Preemptible Kernel Maintainer Interviewed
Tom F writes: "LinuxDevices did an interesting interview with Robert Love, the maintainer of the Linux preemptible kernel along with MontaVista. It is an exciting read and has Robert's usual wit and insight."
Pre-emptable kernel: Bringing the multitasking of MacOS 9 to Linux since 2.3!
The preemption patch is available now, and works now, and I am using it now.
The problems with the preempt patch are several:
1. It makes kernel debugging considerably harder
2. It introduces potential livelocks which could hang the system (this is an inherent part of the design and not an implementation bug)
3. It doesn't work with SMP (yet), this is fixable
4. It doesn't improve the worst-case latency.
#4 means it isn't a viable alternative to low-latency style patches; Love has said as much on linux-kernel, though obviously he feels it's a nice complement. 1 is a large hill to climb on its own, and 2 basically dooms it unless a clean solution can be found (most proposed solutions involve some sort of priority inheritance, which is a rat's nest).
In other words, the patch "works" only in a very limited sense; it doesn't decrease worst-case latency, can potentially hang the system, and doesn't interact well with SMP. It does decrease average-case latency.
The preemption patch is comparatively small and elegant.
Uh, that's in the eye of the beholder I guess. It is small, but it's not really elegant; it essentially causes conditional reschedules to happen all over the place, and by design cannot deal with latency in noninterruptable interrupt contexts--which happen to be exactly where the worst-case latencies are. So preempt as it's currently designed simply cannot address the worst-case latency. And it causes far more runtime conditional reschedules than the LL patches.
The low-latency patch decreases both worst and average-case latencies. It also doesn't have livelocks as an inherent part of its design. And average-case latencies with LL are as good as those with LL+preempt (in other words, preempt gains you nothing over LL). LL, unfortunately, touches a lot of code and has conditional schedules sprinkled all over the place--it's not elegant either, and certainly not small. But unlike preempt, it actually decreases the worst-case latency, which is what's important to the soft realtime applications that gave birth to both patches. There's a mini-LL patch as well which has far fewer conditional rescheds, that's being discussed for potential inclusion in 2.4.x and/or 2.5.x
My gut feeling is that preempt is the wrong approach to the latency problem, but the jury is still out on it. I don't think either the current preempt or the current LL are ready to go in the kernel. If you're doing e.g sound mixing or other latency-sensitive work right now, the full LL patches seem like the best alternative available. They get latencies down extremely low, well below those of e.g. BeOS.
Sumner
rage, rage against the dying of the light
> Like all true geeks, Love doesn't forget to include in his comments that, despite being a computer nerd, he does, in fact, have a girlfriend.
WhoTF cares if he has one or not? Are (other) geeks jealous because he has one, and they don't?
I care about the quality of his code, not about his love life.