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

[Perez-Gonzalez, Inaky]

> From: Ulrich Drepper [mailto:drepper@xxxxxxxxxx]


> 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.

Just for the record, Ulrich. This is not correct--there is a fast path,
and you only need to use the kernel if 

a) there is contention
b) your architecture doesn't have the atomic cmpxchg for doing the fast-path

even in b), if you want fast-path, you can use the ufuqueue calls like
you would use futexes to do a fast-path, loosing the robustness and
advanced real-time thingies [you still get the scheduling-policy based
unlock/wakeup].

If one of those (b) arches wants the robustness and stuff, it then
_needs_ to go always through the kernel [slow]. 

Of course you don't want to penalize normal users, so it is easy to 
have a simple switch in user-space that will do it one way or the 
other depending on the attributes of the mutex they select [we haven't 
coded a proof-of-concept for  this yet, but we want to do it during fall].


> > 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.  Lockers of robust mutexes have to
> register with the kernel (i.e., the locking must actually be performed
> by the kernel) so that in case the thread goes away or the entire

Small point here--this only happens when there are waiters in the kernel
already. If there is no contention, the locker fast-locks in user space
only using his PID [this is weak, read the paper for some solutions to
avoid PID reusage collision]. If it dies, next time somebody tries to
lock sees the user space word (vfulock) locked and goes to the kernel.
The kernel looks it up, and if the PID doesn't exist, declares the mutex
dead and assigns 'current' ownership to it, back to user space.

 
> ... This is very useful for
> normal operations where mutexes are used inter-process.  This is the
> part which is independent from rt but it also must not be the default
> mode (i.e., normal pthread_mutex_t code must not be replaced) since it
> is significantly slower.

So even in the robustness case there is fast-path. It is not significantly
slower.

> The rest of the extensions like all the priority handling is not of
> general interest.  POSIX describes how a thread's priority would be
> temporarily raised if it holds a mutex which has a higher-priority
> waiter.  But this is all functionality of a realtime profile and widely
> not part of the normal implementation.

This is not what I am hearing from embedded and enterprise guys. I just
wish they were more vocal and not expressed themselves only in private
mails--I understand you need a proof though.

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