[lkml]   [2004]   [Oct]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    Subject[patch] CONFIG_PREEMPT_REALTIME, 'Fully Preemptible Kernel', VP-2.6.9-rc4-mm1-T4

    i've released the -T4 VP patch:

    the big change in this release is the addition of PREEMPT_REALTIME,
    which is a new implementation of a fully preemptible kernel model:

    - spinlocks and rwlocks use semaphores and are preemptible by default

    - the _irq variants of these locks do not disable interrupts but rely
    on IRQ threading to exclude against interrupt contexts.

    note that this implementation is different from other kernel-preemption
    patches, in a number of key areas. Initially i looked at merging the
    MontaVista patchset from two days ago but decided to implement a new one
    from scratch to cure a number of conceptual problems:

    - this patch auto-detects the 'type' of the lock at compilation time.

    All fully-preemptible kernel patches i've seen so far suffer from one
    nasty problem: they are very large because they redefine _all_ the
    spinlock APIs to provide separation between 'mutex based' and
    'original' spinlocks. E.g. check out the sheer size of the MontaVista
    patchset: Linux-2.6.9-rc3-RT_spinlock1.patch and
    Linux-2.6.9-rc3-RT_spinlock2.patch are 84K and 92K and they convert
    ~30 core spinlocks to new APIs.

    OTOH this patch converts _90_ spinlocks in roughly half the
    patchsize, which makes a large difference in maintainability.

    How it works: this implementation uses a gcc feature to detect the
    type of the spinlock compile-time and to switch to the mutex or
    raw_spinlock API accordingly. Only one, very isolated change has to
    be done to switch a generic spinlock to a spin-only lock: spinlock_t
    is changed to raw_spinlock_t and the initializer is fixed up. All the
    other code remains untouched - and this even if a single C module
    contains both mutex-based and spinlock-based API calls. This approach
    is quite close to a simple object-oriented lock type - but written in
    C and compatible with the existing spinlock APIs.

    - i used the native Linux semaphores/rwsems to implement
    spinlock/rwlock preemption. E.g. the MontaVista patches use separate
    synchronization objects (kmutex/pmutex) to implement this.

    I believe using native semaphores is the better approach
    architecturally because this means that we have to add priority
    inheritance handling only once and to the native Linux semaphores.
    This has the additional benefit of fixing all mutex-using
    kernel code's priority inheritance problems. (which kmutex/pmutex
    does not solve.)

    OTOH the MontaVista patches naturally have the advantage of having a
    working priority-inheritance mechanism in the pmutex code, right now.
    (I did a brief attempt to plug the pmutex code into this patch but it
    didnt look good of a match - but others might want to try to
    integrate it nevertheless.)

    also, another bad property of the kmutex/pmutex code is that it uses
    assembly which makes it quite hard to port to non-x86 architectures.
    OTOH, the native Linux semaphores and rwsems work on every

    - the patch converts rwlocks too, while e.g. the MontaVista patchset
    still keeps rwlocks as spinlocks. It is important to convert rwlocks
    to rw-semaphores, most notably this allow the conversion of the
    tasklist and signal spinlocks.

    - finally, i went for correctness primarily, not latencies. I checked
    out the MontaVista patches and they categorize roughly 30 spinlocks
    as the ones that are necessary to be 'raw'. Unfortunately this is
    inadequate, my patch excludes 90 such locks and it's still probably
    not a 100% correct conversion. The core kernel needs changes in the
    locking infrastructure to get rid of most of the these 90 non-mutex

    it is highly recommended to enable DEBUG_PREEMPT when enabling
    PREEMPT_REALTIME. It will warn about all the places that are unsafe. The
    patch is x86-only for the time being, but the changes necessary for
    other architectures should be relatively low.

    NOTE: CONFIG_PREEMPT_REALTIME is default-off and i'd only suggest to
    enable it on non-critical systems. It is the first iteration of this
    feature and it will sure have rough edges. Not for the faint hearted!

    NOTE2: some of the lock-break functionality offered by the -VP patchset
    is disabled if PREEMPT_REALTIME is enabled - this is temporary. This
    will likely result in an increase of the maximum measured latencies.

    NOTE3: since so many spinlocks are still non-mutex, even average
    latencies will be well above what we could achieve - but i wanted to
    reach a known-correct codebase first. For example, most of the
    networking spinlocks had to be made non-mutex because of networking's
    use of RCU locking primitives and per-CPU data structures. The same is
    true for the VFS - many of its locks are non-mutex still due to RCU.
    Once this infrastructure work is done the size of the patch will
    decrease significantly.

    to build a -T4 tree from scratch the patching order is:

    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.027 / U:6.072 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site