lkml.org 
[lkml]   [2004]   [Aug]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [RFC/PATCH] FUSYN Realtime & robust mutexes for Linux, v2.3.1
Ulrich Drepper <drepper@redhat.com> wrote:
>
> Andrew Morton wrote:
>
> > How large is the slowdown, and on what workloads?
>
> The fast path for all locking primitives etc in nptl today is entirely
> at userlevel. Normally just a single atomic operation with a dozen
> other instructions. With the fusyn stuff each and every locking
> operation needs a system call to register/unregister the thread as it
> locks/unlocks mutex/rwlocks/etc. Go figure how well this works. We are
> talking about making the fast path of the locking primitives
> two/three/four orders of magnitude more expensive. And this for
> absolutely no benefit for 99.999% of all the code which uses threads.
>

ouch, OK. But doesn't the current futex code continue to work unchanged?

> > Passing the lock to a non-rt task when there's an rt-task waiting for it
> > seems pretty poor form, too.
>
> No no, that's not what is wanted. Robust mutexes are a special kind of
> mutex and not related to rt issues.

I was referring to "scheduling-policy based unlock/wakeup", actually.
-
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.058 / U:0.576 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site