Re: [ANNOUNCE] Linux 2.6 Real Time Kernel

[Ingo Molnar <mingo@elte.hu>]

* Sven-Thorsten Dietrich <sdietrich@mvista.com> wrote:

> Announcing the availability of prototype real-time (RT)
> enhancements to the Linux 2.6 kernel.
> 
> We will submit 3 additional emails following this one, containing
> the remaining 3 patches (of 4) inline, with their descriptions.

cool! Basically the biggest problem is not the technology itself, but
its proper integration into Linux. As it can be seen from the 2.4 RT
patches (TimeSys and yours), just walking the path towards a fully
preemptible kernel is not fruitful because it generates lots of huge,
intrusive patches that end up being unmaintainable forks of the Linux
tree.

the other approach is what i'm currently doing with the
voluntary-preempt patchset: to improve the generic kernel for latency
purposes without actually adding too many extra features. Here is what
is happening in the -mm tree right now:

 - the generic irq subsystem: irq threading is a simple ~200-lines,
   architecture-independent add-on to this. It makes no sense to offer 3
   different implementations - pick one and help make it work well.

 - preemptible BKL. Related to this is new debugging infrastructure in
   -mm that allows the safe and slow conversion of spinlocks to mutexes. 
   In the case of the BKL this conversion is expected to be permanent, 
   for most of the other spinlocks it will be optional - but the 
   debugging code can still be used.

 - various fixes and latency improvements. A mutex based kernel is of
   little use if the only code you can execute reliably is user-space
   code and the moment you hit kernel-space your RT app is exposed to
   high latencies.

A couple of suggestions wrt. how to speed up the integration effort: you
might want to rebase this stuff to the -mm tree. Also, what i dont see
in your (and others') patches (yet?) is some of the harder stuff:

 - the handling of per-CPU data structures (get_cpu_var())

 - RCU and softirq data structures

 - the handling of the IRQ flag

These are basic correctness issues that affect UP just as much as SMP.
Without these the kernel is still not a "fully preemptible" kernel. 
These need infrastructure changes too, so they must preceed any addition
of a spinlock -> mutex conversion feature.

So the mutex patch will probably the one that can go upstream _last_,
which will do the "final step" of making the kernel fully preemptible.

	Ingo