lkml.org 
[lkml]   [2004]   [Aug]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRE: [RFC/PATCH] FUSYN Realtime & robust mutexes for Linux, v2.3.1
Date
From
> From: Ulrich Drepper [mailto:drepper@redhat.com]
>
> Andrew Morton wrote:
>
> > This fixes what appear to be some fairly significant shortcomings. What do
> > the futex and NPTL people have to say about the gravity of the problems
> > which this solves, and the offered implementation?
>
> This code will not be suppoerted by the glibc code. Using these
> primitives would mean significant slowdown of all operations and this
> for problems which only a few people have. I asked to get the useful
> parts of the code to be made available using the current futex interface
> (robust mutexes are useful) but Inaky and rest rest never acted on this
> and instead invented this completely incompatible interface. IMO this
> code should not go into the mainstream kernel. Let those who want to do
> realtime work bear the costs.

But I told you many times why it is not possible and you keep ignoring
those reasons.

Read the paper, read the slides. In a nutshell [again]: the idea of
robustness requires that there is a concept of ownership and that the
kernel knows about it. Futexes are just waitqueues, and as they are
used all around the code in glibc and other apps, the ownership concept
doesn't work with them.

[same thing applies to the advanced real-time features, priority
inheritance and protection, as they require kernel knowledge about
ownership].

With the current futex interface it cannot be done--I tried and it
resulted in a mess [lookup for rtfutex patches I sent last year].

On top of that, many people has voiced that the sys_futex() multiplexing
should have been unfolded long time ago.

The fusyn patch provides exactly the same capabilities than futexes
using the fuqueues [except for the requeue bits and the FUTEX_FD, that
should be quick to implement], albeit using different system calls.
It should not be hard to redirect sys_futex() to the sys_ufuqueue_*()
calls.

As people has pointed out already, there is a fast path--the slowdown
that we see is caused by the in-kernel overhead, and we are looking
into that, because even 10% is not acceptable.

[for the record, my belief is that it is caused because we need to
use IRQ locks--and a total of some more spinlocks to do the lock/
unlock operations in the kernel--this is what we are profiling now].

Iñaky Pérez-González -- Not speaking for Intel -- all opinions are my own (and my fault)
-
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/

\
 
 \ /
  Last update: 2005-03-22 14:04    [W:0.048 / U:0.328 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site