Message ID | 1445854536-22645-1-git-send-email-boqun.feng@gmail.com (mailing list archive) |
---|---|
State | Superseded, archived |
Headers | show |
On Mon, 2015-26-10 at 10:15:36 UTC, Boqun Feng wrote: > This patch fixes two problems to make value-returning atomics and > {cmp}xchg fully ordered on PPC. Hi Boqun, Can you please split this into two patches. One that does the cmpxchg change and one that changes PPC_ATOMIC_ENTRY_BARRIER. Also given how pervasive this change is I'd like to take it via the powerpc next tree, so can you please send this patch (which will be two after you split it) as powerpc patches. And the rest can go via tip? cheers
On Tue, Oct 27, 2015 at 01:33:47PM +1100, Michael Ellerman wrote: > On Mon, 2015-26-10 at 10:15:36 UTC, Boqun Feng wrote: > > This patch fixes two problems to make value-returning atomics and > > {cmp}xchg fully ordered on PPC. > > Hi Boqun, > > Can you please split this into two patches. One that does the cmpxchg change > and one that changes PPC_ATOMIC_ENTRY_BARRIER. > OK, make sense ;-) > Also given how pervasive this change is I'd like to take it via the powerpc > next tree, so can you please send this patch (which will be two after you split > it) as powerpc patches. And the rest can go via tip? > One problem is that patch 5 will remove __xchg_u32 and __xchg_64 entirely, which are modified in this patch(patch 1), so there will be some conflicts if two branch get merged, I think. Alternative way is that all this series go to powerpc next tree as most of the dependent patches are already there. I just need to remove inc/dec related code and resend them when appropriate. Besides, I can pull patch 2 out and send it as a tip patch because it's general code and no one depends on this in this series. To summerize: patch 1(split to two), 3, 4(remove inc/dec implementation), 5, 6 sent as powerpc patches for powerpc next, patch 2(unmodified) sent as tip patch for locking/core. Peter and Michael, this works for you both? Regards,
On Tue, Oct 27, 2015 at 11:06:52AM +0800, Boqun Feng wrote: > On Tue, Oct 27, 2015 at 01:33:47PM +1100, Michael Ellerman wrote: > > On Mon, 2015-26-10 at 10:15:36 UTC, Boqun Feng wrote: > > > This patch fixes two problems to make value-returning atomics and > > > {cmp}xchg fully ordered on PPC. > > > > Hi Boqun, > > > > Can you please split this into two patches. One that does the cmpxchg change > > and one that changes PPC_ATOMIC_ENTRY_BARRIER. > > > > OK, make sense ;-) > > > Also given how pervasive this change is I'd like to take it via the powerpc > > next tree, so can you please send this patch (which will be two after you split > > it) as powerpc patches. And the rest can go via tip? > > > > One problem is that patch 5 will remove __xchg_u32 and __xchg_64 > entirely, which are modified in this patch(patch 1), so there will be > some conflicts if two branch get merged, I think. > > Alternative way is that all this series go to powerpc next tree as most > of the dependent patches are already there. I just need to remove > inc/dec related code and resend them when appropriate. Besides, I can > pull patch 2 out and send it as a tip patch because it's general code > and no one depends on this in this series. > > To summerize: > > patch 1(split to two), 3, 4(remove inc/dec implementation), 5, 6 sent as > powerpc patches for powerpc next, patch 2(unmodified) sent as tip patch > for locking/core. > > Peter and Michael, this works for you both? > Thoughts? ;-) Regards, Boqun
On Fri, Oct 30, 2015 at 08:56:33AM +0800, Boqun Feng wrote: > On Tue, Oct 27, 2015 at 11:06:52AM +0800, Boqun Feng wrote: > > On Tue, Oct 27, 2015 at 01:33:47PM +1100, Michael Ellerman wrote: > > > On Mon, 2015-26-10 at 10:15:36 UTC, Boqun Feng wrote: > > > > This patch fixes two problems to make value-returning atomics and > > > > {cmp}xchg fully ordered on PPC. > > > > > > Hi Boqun, > > > > > > Can you please split this into two patches. One that does the cmpxchg change > > > and one that changes PPC_ATOMIC_ENTRY_BARRIER. > > > > > > > OK, make sense ;-) > > > > > Also given how pervasive this change is I'd like to take it via the powerpc > > > next tree, so can you please send this patch (which will be two after you split > > > it) as powerpc patches. And the rest can go via tip? > > > > > > > One problem is that patch 5 will remove __xchg_u32 and __xchg_64 > > entirely, which are modified in this patch(patch 1), so there will be > > some conflicts if two branch get merged, I think. > > > > Alternative way is that all this series go to powerpc next tree as most > > of the dependent patches are already there. I just need to remove > > inc/dec related code and resend them when appropriate. Besides, I can > > pull patch 2 out and send it as a tip patch because it's general code > > and no one depends on this in this series. > > > > To summerize: > > > > patch 1(split to two), 3, 4(remove inc/dec implementation), 5, 6 sent as > > powerpc patches for powerpc next, patch 2(unmodified) sent as tip patch > > for locking/core. > > > > Peter and Michael, this works for you both? > > > > Thoughts? ;-) > Peter and Michael, I will split patch 1 to two and send them as patches for powerpc next first. The rest of this can wait util we are on the same page of where they'd better go. Regards, Boqun
On Mon, Nov 02, 2015 at 09:22:40AM +0800, Boqun Feng wrote: > > On Tue, Oct 27, 2015 at 11:06:52AM +0800, Boqun Feng wrote: > > > To summerize: > > > > > > patch 1(split to two), 3, 4(remove inc/dec implementation), 5, 6 sent as > > > powerpc patches for powerpc next, patch 2(unmodified) sent as tip patch > > > for locking/core. > > > > > > Peter and Michael, this works for you both? > > > > > > > Thoughts? ;-) > > > > Peter and Michael, I will split patch 1 to two and send them as patches > for powerpc next first. The rest of this can wait util we are on the > same page of where they'd better go. > I'm about to send patch 2(adding trivial tests) as a patch for the tip tree, and rest of this series will be patches for powerpc next. Will, AFAIK, you are currently working on variants on arm64, right? I wonder whether you depend on patch 3 (allow archictures to provide self-defined __atomic_op_*), if so I can also send patch 3 as a patch for tip tree and wait until it merged into powerpc next to send the rest. Thanks and Best Regards, Boqun
On Wed, Nov 04, 2015 at 09:22:13AM +0800, Boqun Feng wrote: > Will, AFAIK, you are currently working on variants on arm64, right? I > wonder whether you depend on patch 3 (allow archictures to provide > self-defined __atomic_op_*), if so I can also send patch 3 as a patch > for tip tree and wait until it merged into powerpc next to send the > rest. The arm64 patches are all queued in the arm64 tree and have been sitting in -next for a while. They don't dependent on anything else. Will
diff --git a/arch/powerpc/include/asm/cmpxchg.h b/arch/powerpc/include/asm/cmpxchg.h index ad6263c..d1a8d93 100644 --- a/arch/powerpc/include/asm/cmpxchg.h +++ b/arch/powerpc/include/asm/cmpxchg.h @@ -18,12 +18,12 @@ __xchg_u32(volatile void *p, unsigned long val) unsigned long prev; __asm__ __volatile__( - PPC_RELEASE_BARRIER + PPC_ATOMIC_ENTRY_BARRIER "1: lwarx %0,0,%2 \n" PPC405_ERR77(0,%2) " stwcx. %3,0,%2 \n\ bne- 1b" - PPC_ACQUIRE_BARRIER + PPC_ATOMIC_EXIT_BARRIER : "=&r" (prev), "+m" (*(volatile unsigned int *)p) : "r" (p), "r" (val) : "cc", "memory"); @@ -61,12 +61,12 @@ __xchg_u64(volatile void *p, unsigned long val) unsigned long prev; __asm__ __volatile__( - PPC_RELEASE_BARRIER + PPC_ATOMIC_ENTRY_BARRIER "1: ldarx %0,0,%2 \n" PPC405_ERR77(0,%2) " stdcx. %3,0,%2 \n\ bne- 1b" - PPC_ACQUIRE_BARRIER + PPC_ATOMIC_EXIT_BARRIER : "=&r" (prev), "+m" (*(volatile unsigned long *)p) : "r" (p), "r" (val) : "cc", "memory"); @@ -151,14 +151,14 @@ __cmpxchg_u32(volatile unsigned int *p, unsigned long old, unsigned long new) unsigned int prev; __asm__ __volatile__ ( - PPC_RELEASE_BARRIER + PPC_ATOMIC_ENTRY_BARRIER "1: lwarx %0,0,%2 # __cmpxchg_u32\n\ cmpw 0,%0,%3\n\ bne- 2f\n" PPC405_ERR77(0,%2) " stwcx. %4,0,%2\n\ bne- 1b" - PPC_ACQUIRE_BARRIER + PPC_ATOMIC_EXIT_BARRIER "\n\ 2:" : "=&r" (prev), "+m" (*p) @@ -197,13 +197,13 @@ __cmpxchg_u64(volatile unsigned long *p, unsigned long old, unsigned long new) unsigned long prev; __asm__ __volatile__ ( - PPC_RELEASE_BARRIER + PPC_ATOMIC_ENTRY_BARRIER "1: ldarx %0,0,%2 # __cmpxchg_u64\n\ cmpd 0,%0,%3\n\ bne- 2f\n\ stdcx. %4,0,%2\n\ bne- 1b" - PPC_ACQUIRE_BARRIER + PPC_ATOMIC_EXIT_BARRIER "\n\ 2:" : "=&r" (prev), "+m" (*p) diff --git a/arch/powerpc/include/asm/synch.h b/arch/powerpc/include/asm/synch.h index e682a71..c508686 100644 --- a/arch/powerpc/include/asm/synch.h +++ b/arch/powerpc/include/asm/synch.h @@ -44,7 +44,7 @@ static inline void isync(void) MAKE_LWSYNC_SECTION_ENTRY(97, __lwsync_fixup); #define PPC_ACQUIRE_BARRIER "\n" stringify_in_c(__PPC_ACQUIRE_BARRIER) #define PPC_RELEASE_BARRIER stringify_in_c(LWSYNC) "\n" -#define PPC_ATOMIC_ENTRY_BARRIER "\n" stringify_in_c(LWSYNC) "\n" +#define PPC_ATOMIC_ENTRY_BARRIER "\n" stringify_in_c(sync) "\n" #define PPC_ATOMIC_EXIT_BARRIER "\n" stringify_in_c(sync) "\n" #else #define PPC_ACQUIRE_BARRIER