Re: [PATCH] Priority Lists for the RT mutex

[Ingo Molnar <mingo@elte.hu>]

* Sven-Thorsten Dietrich <sdietrich@mvista.com> wrote:

> On Fri, 2005-04-08 at 08:28 +0200, Ingo Molnar wrote:
> > * Daniel Walker <dwalker@mvista.com> wrote:
> > 
> > > 	This patch adds the priority list data structure from Inaky 
> > > Perez-Gonzalez to the Preempt Real-Time mutex.
> > 
> > this one looks really clean.
> > 
> > it makes me wonder, what is the current status of fusyn's? Such a light 
> > datastructure would be much more mergeable upstream than the former 
> > 100-queues approach.
> 
> Ingo,
> 
> Joe Korty has been doing a lot of work on Fusyn recently.
> 
> Fusyn is now a generic implementation, similar to the RT mutex. SMP 
> scalability is somewhat better for decoupled locks on PI (last I 
> checked). It has the extra bulk required to support user space.
> 
> The major issue that concerns the Fusym and the real-time patch is 
> that merging the kernel portion of Fusyn creates a collision of 
> redundant PI implementations with respect to the RT mutex.

i'd not mind merging the extra bits to PREEMPT_RT to enable fusyn's, if 
they come in small, clean steps. E.g. Daniel's plist.h stuff was nice 
and clean.

> There are a few mistakes on the page, (RT mutex does not do priority 
> ceiling), but for the most part the info is current.

is priority ceiling coming in via some POSIX feature that fusyn's need
to address? What would be needed precisely - a way to set a priority for
a lock (independently of the owner's task priority), and let that
control the PI mechanism?

Unless i'm missing something, this could be implemented by detaching
lock->owner_prio from lock->owner - via e.g. negative values. Thus some
minimal code would check whether we need the owner's priority in the PI
logic, or the semaphore's "own" priority level.

i.e. this doesnt seem to really affect the core design of RT mutexes.

OTOH, deadlock detection is another issue. It's quite expensive and i'm 
not sure we want to make it a runtime thing. But for fusyn's deadlock 
detection and safe teardown on owner-exit is a must-have i suspect?

> If the RT mutex could be exposed in non PREEMPT_RT configurations, the 
> fulock portion could be superseded by the RT mutex, and the remaining 
> pieces merged in. Or vice versa.

sure, RT mutexes could be exposed in !PREEMPT_RT.

	Ingo
-
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/