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

[Andrew Morton]

Ulrich Drepper <drepper@xxxxxxxxxx> 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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/