From: Joel Schopp <jschopp@austin.ibm.com>
To: Ingo Molnar <mingo@elte.hu>
Cc: lkml <linux-kernel@vger.kernel.org>,
Linus Torvalds <torvalds@osdl.org>, Andrew Morton <akpm@osdl.org>,
Arjan van de Ven <arjan@infradead.org>,
Nicolas Pitre <nico@cam.org>,
Jes Sorensen <jes@trained-monkey.org>,
Al Viro <viro@ftp.linux.org.uk>, Oleg Nesterov <oleg@tv-sign.ru>,
David Howells <dhowells@redhat.com>,
Alan Cox <alan@lxorguk.ukuu.org.uk>,
Christoph Hellwig <hch@infradead.org>, Andi Kleen <ak@suse.de>,
Russell King <rmk+lkml@arm.linux.org.uk>,
Anton Blanchard <anton@samba.org>,
PPC64-dev <linuxppc64-dev@ozlabs.org>
Subject: Re: [patch 00/21] mutex subsystem, -V14
Date: Thu, 05 Jan 2006 17:06:26 -0600 [thread overview]
Message-ID: <43BDA672.4090704@austin.ibm.com> (raw)
In-Reply-To: <20060105222106.GA26474@elte.hu>
[-- Attachment #1: Type: text/plain, Size: 1211 bytes --]
> ISYNC_ON_SMP flushes all speculative reads currently in the queue - and
> is hence a smp_rmb_backwards() primitive [per my previous mail] - but
> does not affect writes - correct?
>
> if that's the case, what prevents a store from within the critical
> section going up to right after the EIEIO_ON_SMP, but before the
> atomic-dec instructions? Does any of those instructions imply some
> barrier perhaps? Are writes always ordered perhaps (like on x86 CPUs),
> and hence the store before the bne is an effective write-barrier?
It really makes more sense after reading PowerPC Book II, which you can find at
this link, it was written by people who explain this for a living:
http://www-128.ibm.com/developerworks/eserver/articles/archguide.html
While isync technically doesn't order stores it does order instructions. The
previous bne- must complete, that bne- is dependent on the previous stwcx being
complete. So no stores are slipping up. To get a better explanation you will
have to read the document yourself.
Here is a first pass at a powerpc file for the fast paths just as an FYI/RFC.
It is completely untested, but compiles.
Signed-off-by: Joel Schopp <jschopp@austin.ibm.com>
[-- Attachment #2: powerpcmutex.patch --]
[-- Type: text/plain, Size: 2812 bytes --]
Index: 2.6.15-mutex14/include/asm-powerpc/mutex.h
===================================================================
--- 2.6.15-mutex14.orig/include/asm-powerpc/mutex.h 2006-01-04 14:46:31.%N -0600
+++ 2.6.15-mutex14/include/asm-powerpc/mutex.h 2006-01-05 16:25:41.%N -0600
@@ -1,9 +1,83 @@
/*
- * Pull in the generic implementation for the mutex fastpath.
+ * include/asm-powerpc/mutex.h
*
- * TODO: implement optimized primitives instead, or leave the generic
- * implementation in place, or pick the atomic_xchg() based generic
- * implementation. (see asm-generic/mutex-xchg.h for details)
+ * PowerPC optimized mutex locking primitives
+ *
+ * Please look into asm-generic/mutex-xchg.h for a formal definition.
+ * Copyright (C) 2006 Joel Schopp <jschopp@austin.ibm.com>, IBM
*/
+#ifndef _ASM_MUTEX_H
+#define _ASM_MUTEX_H
+#define __mutex_fastpath_lock(count, fail_fn)\
+do{ \
+ long tmp; \
+ __asm__ __volatile__( \
+"1: lwarx %0,0,%1\n" \
+" addic %0,%0,-1\n" \
+" stwcx. %0,0,%1\n" \
+" bne- 1b\n" \
+" isync \n" \
+ : "=&r" (tmp) \
+ : "r" (&(count)->counter) \
+ : "cr0", "memory"); \
+ if (unlikely(tmp < 0)) \
+ fail_fn(count); \
+} while (0)
+
+#define __mutex_fastpath_unlock(count, fail_fn)\
+do{ \
+ long tmp; \
+ __asm__ __volatile__(SYNC_ON_SMP \
+"1: lwarx %0,0,%1\n" \
+" addic %0,%0,1\n" \
+" stwcx. %0,0,%1\n" \
+" bne- 1b\n" \
+ : "=&r" (tmp) \
+ : "r" (&(count)->counter) \
+ : "cr0", "memory"); \
+ if (unlikely(tmp <= 0)) \
+ fail_fn(count); \
+} while (0)
+
+
+static inline int
+__mutex_fastpath_trylock(atomic_t* count, int (*fail_fn)(atomic_t*))
+{
+ long tmp;
+ __asm__ __volatile__(
+"1: lwarx %0,0,%1\n"
+" cmpwi 0,%0,1\n"
+" bne- 2f\n"
+" stwcx. %0,0,%1\n"
+" bne- 1b\n"
+" isync\n"
+"2:"
+ : "=&r" (tmp)
+ : "r" (&(count)->counter)
+ : "cr0", "memory");
+
+ return (int)tmp;
+
+}
+
+#define __mutex_slowpath_needs_to_unlock() 1
-#include <asm-generic/mutex-dec.h>
+static inline int
+__mutex_fastpath_lock_retval(atomic_t* count, int (*fail_fn)(atomic_t *))
+{
+ long tmp;
+ __asm__ __volatile__(
+"1: lwarx %0,0,%1\n"
+" addic %0,%0,-1\n"
+" stwcx. %0,0,%1\n"
+" bne- 1b\n"
+" isync \n"
+ : "=&r" (tmp)
+ : "r" (&(count)->counter)
+ : "cr0", "memory");
+ if (unlikely(tmp < 0))
+ return fail_fn(count);
+ else
+ return 0;
+}
+#endif
next prev parent reply other threads:[~2006-01-05 23:06 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-01-04 14:41 [patch 00/21] mutex subsystem, -V14 Ingo Molnar
2006-01-04 23:45 ` Joel Schopp
2006-01-05 2:38 ` Nicolas Pitre
2006-01-05 2:51 ` Linus Torvalds
2006-01-05 3:21 ` Nick Piggin
2006-01-05 3:39 ` Anton Blanchard
2006-01-05 18:04 ` Jesse Barnes
2006-01-05 14:40 ` Ingo Molnar
2006-01-05 16:21 ` Linus Torvalds
2006-01-05 22:03 ` Ingo Molnar
2006-01-05 22:17 ` Linus Torvalds
2006-01-05 22:43 ` Ingo Molnar
2006-01-06 3:49 ` Keith Owens
2006-01-06 7:34 ` Denis Vlasenko
2006-01-05 14:35 ` Ingo Molnar
2006-01-05 16:42 ` Joel Schopp
2006-01-05 22:21 ` Ingo Molnar
2006-01-05 23:06 ` Joel Schopp [this message]
2006-01-05 23:26 ` Linus Torvalds
2006-01-05 23:36 ` Joel Schopp
2006-01-05 23:42 ` Ingo Molnar
2006-01-06 0:29 ` Olof Johansson
2006-01-07 17:49 ` PowerPC fastpaths for mutex subsystem Joel Schopp
2006-01-07 22:37 ` Andrew Morton
2006-01-08 7:43 ` Anton Blanchard
2006-01-08 8:00 ` Andrew Morton
2006-01-08 8:23 ` Anton Blanchard
2006-01-09 11:13 ` David Howells
2006-01-08 9:48 ` Ingo Molnar
2006-01-10 22:31 ` Joel Schopp
2006-01-10 23:09 ` Ingo Molnar
2006-01-11 10:52 ` Ingo Molnar
2006-01-11 17:44 ` Joel Schopp
2006-01-08 10:43 ` Ingo Molnar
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=43BDA672.4090704@austin.ibm.com \
--to=jschopp@austin.ibm.com \
--cc=ak@suse.de \
--cc=akpm@osdl.org \
--cc=alan@lxorguk.ukuu.org.uk \
--cc=anton@samba.org \
--cc=arjan@infradead.org \
--cc=dhowells@redhat.com \
--cc=hch@infradead.org \
--cc=jes@trained-monkey.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linuxppc64-dev@ozlabs.org \
--cc=mingo@elte.hu \
--cc=nico@cam.org \
--cc=oleg@tv-sign.ru \
--cc=rmk+lkml@arm.linux.org.uk \
--cc=torvalds@osdl.org \
--cc=viro@ftp.linux.org.uk \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.