* Ingo Molnar <[email protected]> wrote:
> * Nicolas Pitre <[email protected]> wrote:
>
> > > here we go to great trouble trying to avoid the 'slowpath', while we
> > > unconditionally force the next unlock into the slowpath! So we have
> > > not won anything. (on a cycle count basis it's probably even a net
> > > loss)
> >
> > I disagree. [...elaborate analysis of the code ...]
>
> you are right, it should work fine, and should be optimal. I'll add
> your xchg variant to mutex-xchg.h.
the patch below adds it, and it boots fine on x86 with mutex.c hacked to
include asm-generic/mutex-xchg.h.
Ingo
Index: linux/include/asm-generic/mutex-xchg.h
===================================================================
--- linux.orig/include/asm-generic/mutex-xchg.h
+++ linux/include/asm-generic/mutex-xchg.h
@@ -82,7 +82,25 @@ do { \
static inline int
__mutex_fastpath_trylock(atomic_t *count, int (*fn)(atomic_t *))
{
- return fn(count);
+ int prev = atomic_xchg(count, 0);
+
+ if (unlikely(prev < 0)) {
+ /*
+ * The lock was marked contended so we must restore that
+ * state. If while doing so we get back a prev value of 1
+ * then we just own it.
+ *
+ * [ In the rare case of the mutex going to 1 and then to 0
+ * in this few-instructions window, this has the potential
+ * to trigger the slowpath for the owner's unlock path, but
+ * that's not a problem in practice. ]
+ */
+ prev = atomic_xchg(count, -1);
+ if (prev < 0)
+ prev = 0;
+ }
+
+ return prev;
}
#endif
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
