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

Wow!

[Free Bird]

Cool! I really hope this'll make it into the official kernel, hopefully even 2.4 (though I doubt so not that 2.5 has been started).

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?

Finally..

[Renraku]

You'd think this would have been one of the first few 'features' of the Linux core. If the latency were high, it would screw programs and things that rely on low latencies to compute. Better late than never.

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?

I'm not sure...

[TheMMaster]

I think this is a good short-term solution for the latency problems but I personally wouldn't include it in the main kernel releases. I believe that it *might* be a good idea to fork the kernel releases (temorarily) in two groups: One for servers and one for workstations until the problems have been solved.
I think that (for now) using this patch on workstations is a pretty good idea. And I think that there should be a better solution for the problem witch should THEN be something along the lines of kernel 3.0
I am not a kernel developer or anything, but I am currently reading up on the source and the mailing lists.
Basically all I am trying to say is: Make it work NOW and solve the real problem later. Just make sure that is WILL be solved... (no microsoft coding ways here ;-)). We still need a larger user base...

What does that mean?

[BlackGriffen]

I thought giving the Kernel the ability to preemt other programs was important. If you give programs the ability to preempt the kernel, doesn't that just change the system back to cooperative multi-tasking? I could just see programmers abusing the ability to preempt the kernel to squeeze a little more speed out of their app.

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.

When will the Linux HZ be bumped up to 1000?

[Anonymous Coward]

The last time I looked, the Linux process time slice HZ constant was an anemic 100. When will it finally be defaulted to a respectable 1000 so that programs that act on events are more responsive? You can't even make a smooth scrolling ticker on Linux without chewing up all the CPU if the HZ constant is 100 - too slow. I realize that more time will be spect in context switching - so be it - the time is miniscule.

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?

Re:When will the Linux HZ be bumped up to 1000?

[Anonymous Coward]

This article [byte.com] describes how the HZ value of 100 is obsolete for modern processors and should be increased to 1024. But the problem is that most user-level code is broken in that it assumes the Linux HZ constant is, well, constantly 100.

Re:needed badly

[Elladan]

There's a bug in recent 2.4 kernels where a multithreaded app dumping core could livelock the system. You might try setting a hard limit on core file size to zero and see if the crashes go away.

You'd want to do this in /etc/profile, of course.

Re:needed badly

[Peter La Casse]

Actually, there's some truth to his point. Say a process makes a system call and the kernel code for that call hangs in a loop. Since the scheduler won't preempt the kernel code, that process will run forever and the machine will hang. If the kernel can be preempted, the user can get to a shell and kill the stuck process. I have no idea how often this situation would happen in the real world, though.

Will the linux kernel allow a user process to be killed that is blocked in a kernel call? In my experience, Solaris and Tru64 do not: a user program that is blocked in a kernel call will stay blocked until the kernel call returns, regardless of any action (short of rebooting the machine) that a user can take. I assume that there is some well-thought-out reasoning behind this, but sometimes (e.g. during device driver development) I wish it were somehow a configurable behavior.

I'd think that infinite loops would be too much of a newbie bug.

Lots of times, the most junior person gets stuck writing device drivers. And even experienced programmers can have brain farts.