Messages in this thread | | | Date | Tue, 20 Dec 2005 14:43:30 -0500 (EST) | From | Steven Rostedt <> | Subject | Re: [patch 04/15] Generic Mutex Subsystem, add-atomic-call-func-x86_64.patch |
| |
On Tue, 20 Dec 2005, Russell King wrote:
> On Tue, Dec 20, 2005 at 11:35:22AM -0500, Nicolas Pitre wrote: > > So 14 instructions total with preemption disabling, and that's with the > > best implementation possible by open coding everything instead of > > relying on generic functions/macros. > > I agree with your analysis Nicolas. > > However, don't forget to compare this with our existing semaphore > implementation which is 9 instructions, or 8 for the SMP version. > > In total, this means that mutexes will be _FAR MORE EXPENSIVE_ on ARM > than our semaphores. > > Forcing architectures down the "lets make everything generic" path > does not always hack it. It can't do by its very nature. Generic > implementations are *always* sub-optimal and it is pretty clear > that any gain that mutexes _may_ give is completely wasted on ARM > by the overhead of having a generic framework imposed upon us. > > So, to sum up, if this path is persued, mutexes will be a bloody > disaster on ARM. We'd be far better off sticking to semaphores > and ignoring this mutex stuff. >
So what's wrong with having the generic code, and for those with a fast semapore add an arch specific?
#define mutex_lock down #define mutex_unlock up #define mutex_trylock(x) (!down_trylock(x))
Until the mutex code is updated to a fast arch specific implementation.
Let me restate, that the generic code should not be this, but each arch can have this if they already went through great lengths in making a fast semaphore.
Heck put the above defines in the generic code, with a define
linux/mutex.h:
#ifdef HAVE_ARCH_MUTEX #include <asm/mutex.h> #else
#ifdef HAVE_FAST_SEMAPHORE
#define <defines here>
#else
generic code here
#endif /* HAVE_FAST_SEMAPHORE */
#endif /* HAVE_ARCH_MUTEX */
-- Steve
- 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/
| |