[lkml]   [2004]   [Oct]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
Subject[ANNOUNCE] mmLinux (preemptable kernel for multimedia)

[Try it again, this time to the correct linux-kernel address. :)]

This is a LynuxWorks project.

Project Page:

Source tarball against 2.6.7-mm7:

mmLinux is a project that is dedicated to making Linux 2.6
series kernels fully preemptable. A short description of the
project's goals are on the web site itself, but the ultimate
target is to server multimedia applications under high
computational load without latency glitches using hard RT

Code from this project is not meant for inclusion into the
Linux kernel.

We use:

1) Scott Wood's (TimeSys) patches for irq-threads.

2) The stock rw/semaphore from Linux for all blocking
synchronization including standard semaphore operations
by overloading it using exclusive operation, not shared,
via {down,up}_write with no priority inheritance.
Priority inheritance is something that can be added later.

3) All {read,write,spin}_(bh,irq}{,save,restore), basically
everything but plain read/write/spin locks, have been
transformed to use (2) a type overloaded blocking semaphore.

This has the advantage that a single locking primitive
can be used for both priority inheritance and deadlock
detection, which will simplify development of theses
features into a single mutex primitive.

Priority inheritance can be built on top of a the current
include/linux/rwsem.h implementation by using simple
priority borrowing at block points, specifically at
read->write promotions or write->read demotions. The
latter can simply apply the write threads's priority to
all remaining readers to get basic late priority inheritance.
In the case were there's is 1 reader and writer, it
functions as a normal priority inheritance semaphore.
We plan to do and implementation of this, but are open
to using other mutex implementation through use of a
simple series of #define substitutions.

The current code tree is used primarily as a testing harness
for overall kernel correctness and as a testing framework
for radical synchronization changes at this time. All future
work is dependent on a hard real time core.

This kernel boots as of 8/5/04, two months ago. With
recent sleep violation fixes across the entire IO and
file system layer, the kernel is stable under heavy
load on specific with these fixes. This however
outlines various structural problems with the Linux
kernel itself and the lock reversions to fix sleeping
violations can be used as a path for targetting various
places where top-level locks in the lock graph must be

These are:
1) RCU and dcache_lock.
This forces many locks, sb_lock and friends, back to
being non-preemptable.

Making RCU critical sections preemptable fixes this.

Some per-CPU lock like (pseudo code):



void per_cpu_lock()
int cpu_id;

cpu_id = smp_processor_id();


save_cpu_migration_state(); // in task_struct


void per_cpu_unlock()
int cpu_id = current->cpu_id_cpu_local;

restore_cpu_migration_state(); // in task_struct


"dcache_lock" effects all file systems. With this lock
replaced, many file systems should be free of this

2) local_bh_*.
{spin,read,write}_bh use preempt_count() > 0. This
effects things like the block IO layers, IO schedulers
and down to the SCSI driver.

If this lock is made preempt safe, then it would allow
for all of the IO layer locking to substituted with
blocking mutexes in place without any spinlock reversions.

It might be good to use the per-CPU lock to convert

3) Various places that need to use mm_struct->page_lock_table.
Think about this more...

This runs under a dual processor machine with only a single CPU
enabled on Adaptec SCSI controllers. SMP is an option for a later
development cycle at this time.

kgdb works with this system.

Sync up with Ingo Molnar's tree and migrate whatever changes
are needed to remove non-preemptable locks in the system. This
is going to happen in days.

[I've been talking to him about these issues and he's got a
number of fixes that I'm wait on... per CPU locks specifically]

Crazy, nutty, brain twisting stuff. :)

[I expect this to be resolve within a few days. And I'm observing
various parallel projects and have been suggesting things that
need to be solved. I'll probably move/merge into either Ingo's
or "Open Source Real-Time" projects tree. We'll see. ]

More to come...


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:07    [W:0.036 / U:0.500 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site