Re: [RFC/PATCH] FUSYN Realtime & robust mutexes for Linux, v2.3.1
From: Chris Friesen
Date: Thu Aug 05 2004 - 09:15:16 EST
Ulrich Drepper 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.
Just a small clarification. (Rusty already touched on this briefly, but I think
he made a mistake.)
If the arch has atomic compare-and-exchange, then the non-contended case is
entirely userspace and no syscall is needed. I don't think that the cmpxchg
need be 64-bit. From the OLS 2004 talk:
int vfulock_lock (&vfulock, flags, pid, &timeout) {
unsigned old = VFULOCK_UNLOCKED;
if (cmpxchg(vfulock,old,pid) != old) return 0;
return SYSCALL(ufulock_lock,3,vfulock,flags,to);
}
That looks like a 32-bit cmpxchg to me.
Also, Inaky reported general operation about 10% slower than NPTL, but said that
he wanted to fix that if possible.
Chris
-
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/