Re: 2.6.14-rc3-rt2

[Esben Nielsen <simlo@phys.au.dk>]

On Tue, 4 Oct 2005, Ingo Molnar wrote:

> 
> i have released the 2.6.14-rc3-rt2 tree, which can be downloaded from 
> the usual place:
> 
>   http://redhat.com/~mingo/realtime-preempt/
> 
> the biggest change in this release is the long-anticipated merge of a 
> streamlined version of the "robust futexes/mutexes with priority 
> queueing and priority inheritance" code into the -rt tree. The original 
> upstream patch is from Todd Kneisel, with further improvements, cleanups 
> and -RT integration done by David Singleton.
> 
> robustness is handled by extending the futex framework with 
> registering/unregistering ops and extended wait/wake ops. Priority 
> queueing and inheritance is implemented by embedding the rt_mutex object 
> into the robust-futex structure. This approach made the patches 
> significantly simpler and smaller (but still not trivial at all) than 
> e.g. the fusyn patchset was.
> 

This is great! Priority inheritance in user-space!
I try to follow this development a little when I get time. You might
already have addresses this on the list, but let me raise these two "buts"
anyway:
1) The rt_mutex can promote mutex-deadlocks to raw_spinlock deadlocks
according to the comment in the top of rt.c). Doesn't that mean that a
user-space mutex deadlock can become a raw_spinlock deadlock?
2) The PI traversal for nested interrupts is done with interrupts
disabled. I.e. you can increase the overall system latency by an arbitrary 
amount of time by constructing a code with deep enough lock-nesting.

A year ago, roughly, I worked on PI-mutex for the -RT branch. I didn't
finish  it fast enough for Ingo not to do his own. It was based on some of
the first principles as Ingo's. One of the ideas (which wasn't included in
the patch I send to the list) was to do the PI traversal in steps while
unlocking all the held spinlocks before going to the next depth in the
chain. I used get_task_struct() and put_task_struct() to make sure the
next task in the  traversal didn't get deleted during the periods where no
locks where held.
I'll try to cook something up based on this idea, but to be honest I don't
have any time for it :-(

Esben

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/