Preemptible Linux Kernel: Interviews and Info

An anonymous submitter sends: "MontaVista and Robert Love are developing a patch for the Linux kernel to make it fully preemptible. Lots of users are involved, and tests show huge reductions in latency. Robert's kernel patches are here. Finally, an interview with Robert, on preemption and more."

Comments

So will that make Linux a superior audio platform?

[geekplus]

The reductions in latency -- would that include the type of latency that plagues real-time audio applications like sound-on-sound recording?

Hmm

[drinkypoo]

I thought the Slack 2.0 release had a 1.1 kernel.

I'm wondering about this paragraph:

We had to modify the interrupt code in entry.S to prevent some situations and to allow preemption on return from an interrupt handler. However, we can't preempt within critical regions for the same reason we can't allow concurrency within them with SMP -- so we prevent preemption while holding a spinlock. The bottom half handler and scheduler were also modified to prevent preemption while they are executing.

Can anyone give a nice layman's description of what he's talking about here?

Re:I'm not sure...

[debrain]

Actually, given the current state of the vm parameters set almost exclusively for a workstation (since bdflush chokes a server real good), would seem to dictate that you have to tinker with the kernel anyway and that forking the kernel itself wouldn't necessarily help since the number of forks for each configuration of properly scalable high intensity server would be enormous. It works good for a workstation, and perhaps preemption should be default on a workstation (I use Love's patch on mine), but splitting the kernel between workstations and servers is probably not the best way to go about making servers customized to their personal best performance level since the configuration is quite sticky anyway.

Re:Windows 2000/NT

[RelliK]

Really? That's the first time I hear about that.

There is a difference between pre-emptive multitasking and pre-emptible kernel.
Pre-emptive multitasking means that the kernel can interrupt any thread and give control to another thread, so that a thread cannot hog the CPU resources. This is what all modern operating systems do, except Windows 3.1/9x/Me and MacOS (pre- X), though it could be argued that Windows 3.1/9x/Me is not an operating system much less a modern one ;-)

Pre-emptible kernel is a different beast. It means that the kernel can interrupt itself (i.e. a thread running in the kernel mode) and give control to another thread running in the kernel mode. This is used in real-time operating systems where you need to have a guaranteed maximum response time (i.e. a thread must not wait longer than a certain amount of time before it gets control). However, this is not all that useful for general-purpose OSes and may even be detrimental to servers, where throughput matter more than response time. So it's good to know that this will be a compile-time option.

Re:Preempt Patches in Kernel

[GGardner]

Linus himself said, that they should rather fix the CAUSE of those latencies instead of the symptoms.
Isn't that like saying that you'd rather fix all buggy applications instead of providing a protected memory environment?