Messages in this thread | | | Subject | RE: [RFC/PATCH] FUSYN Realtime & robust mutexes for Linux, v2.3.1 | Date | Thu, 5 Aug 2004 11:16:57 -0700 | From | "Perez-Gonzalez, Inaky" <> |
| |
> 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/
| |