[lkml]   [2004]   [Oct]   [10]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [ANNOUNCE] Linux 2.6 Real Time Kernel

    * Sven-Thorsten Dietrich <> 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

    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.

    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2005-03-22 14:06    [W:0.028 / U:6.512 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site