RE: [RFC/PATCH] FUSYN Realtime & robust mutexes for Linux, v2.3.1

[Perez-Gonzalez, Inaky]

Iñaky Pérez-González -- Not speaking for Intel -- all opinions are my own (and my fault)


> -----Original Message-----
> From: Ingo Molnar [mailto:mingo@xxxxxxx]
> Sent: Thursday, August 05, 2004 3:59 AM
> To: Perez-Gonzalez, Inaky
> Cc: linux-kernel@xxxxxxxxxxxxxxx; robustmutexes@xxxxxxxxxxxxxx; Andrew Morton; Ulrich Drepper
> Subject: Re: [RFC/PATCH] FUSYN Realtime & robust mutexes for Linux, v2.3.1
> 
> 
> * Ingo Molnar <mingo@xxxxxxx> wrote:
> 
> > but, couldnt there be more sharing between futex.c and fusyn.c? In
> > particular on the API side, why arent all these ops done as an
> > extension to sys_futex()? That would keep the glibc part much simpler
> > (and more compatible) as well. [...]
> 
> i believe the key to integration of this feature is to try to make it
> used by normal (non-RT) apps as much as possible. I.e. try to make
> current futexes a subset of fusyn.c and to merge the two APIs if
> possible (essentially renaming your fusyn.c to futex.c and implementing
> the futex API). Is this possible without noticeable performance overhead
> (and without too many special-cases)?

I mentioned it in some other answer...I think. Nevermind. One of the fusyn
layers (ufuqueue) can emulate futexes completely [except for a few extra 
errno codes and the scheduling policy based wakeup and the missing requeue
[easy to do] and FUTEX_FD -- only NGPT uses it, afaik]. 

The interface is now through a three system calls (sys_ufuqueue_{wait,wake,ctl}), 
but it should be easy to redirect sys_futex().

> such an approach would ensure that key portions of the code would be
> triggered by everyday apps. Developers wouldnt break the feature every
> other day, etc. Deadlock detection and priority boosting might not be
> tested this way, but the basic locking/waking/VM-keying mechanism sure
> could be.

That makes sense. Performance overhead wise would be related only to the
extra spinlocks we take...I'll work on that redirection layer--I am going
on vacation tonight, but it should be ready in a couple of days as soon
as I come back.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/