[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.273 / U:3.852 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site