On Thu, Jul 16, 2015 at 03:14:55PM +1000, Benjamin Herrenschmidt wrote:
> On Thu, 2015-07-16 at 15:03 +1000, Benjamin Herrenschmidt wrote:
> > On Thu, 2015-07-16 at 12:00 +1000, Michael Ellerman wrote:
> > > That would fix the problem with smp_mb__after_unlock_lock(), but not
> > > the original
On Thu, Jul 16, 2015 at 03:14:55PM +1000, Benjamin Herrenschmidt wrote:
> On Thu, 2015-07-16 at 15:03 +1000, Benjamin Herrenschmidt wrote:
> > On Thu, 2015-07-16 at 12:00 +1000, Michael Ellerman wrote:
> > > That would fix the problem with smp_mb__after_unlock_lock(), but not
> > > the original
On Tue, 2015-08-25 at 17:27 -0700, Paul E. McKenney wrote:
> On Thu, Aug 20, 2015 at 04:56:04PM +0100, Will Deacon wrote:
> > On Thu, Aug 20, 2015 at 10:45:05AM +0100, Michael Ellerman wrote:
> > > On Tue, 2015-08-18 at 09:37 +0100, Will Deacon wrote:
> > > >
> > > > Thanks, that sounds great.
On Thu, Aug 20, 2015 at 04:56:04PM +0100, Will Deacon wrote:
> On Thu, Aug 20, 2015 at 10:45:05AM +0100, Michael Ellerman wrote:
> > On Tue, 2015-08-18 at 09:37 +0100, Will Deacon wrote:
> > > On Tue, Aug 18, 2015 at 02:50:55AM +0100, Michael Ellerman wrote:
> > > > On Mon, 2015-08-17 at 09:57
On Tue, 2015-08-25 at 17:27 -0700, Paul E. McKenney wrote:
On Thu, Aug 20, 2015 at 04:56:04PM +0100, Will Deacon wrote:
On Thu, Aug 20, 2015 at 10:45:05AM +0100, Michael Ellerman wrote:
On Tue, 2015-08-18 at 09:37 +0100, Will Deacon wrote:
Thanks, that sounds great. FWIW, there are
On Thu, Aug 20, 2015 at 04:56:04PM +0100, Will Deacon wrote:
On Thu, Aug 20, 2015 at 10:45:05AM +0100, Michael Ellerman wrote:
On Tue, 2015-08-18 at 09:37 +0100, Will Deacon wrote:
On Tue, Aug 18, 2015 at 02:50:55AM +0100, Michael Ellerman wrote:
On Mon, 2015-08-17 at 09:57 +0100, Will
On Thu, Aug 20, 2015 at 10:45:05AM +0100, Michael Ellerman wrote:
> On Tue, 2015-08-18 at 09:37 +0100, Will Deacon wrote:
> > On Tue, Aug 18, 2015 at 02:50:55AM +0100, Michael Ellerman wrote:
> > > On Mon, 2015-08-17 at 09:57 +0100, Will Deacon wrote:
> > > > On Mon, Aug 17, 2015 at 07:15:01AM
On Tue, 2015-08-18 at 09:37 +0100, Will Deacon wrote:
> On Tue, Aug 18, 2015 at 02:50:55AM +0100, Michael Ellerman wrote:
> > On Mon, 2015-08-17 at 09:57 +0100, Will Deacon wrote:
> > > On Mon, Aug 17, 2015 at 07:15:01AM +0100, Paul E. McKenney wrote:
> > > > On Mon, Aug 17, 2015 at 02:06:07PM
On Tue, 2015-08-18 at 09:37 +0100, Will Deacon wrote:
On Tue, Aug 18, 2015 at 02:50:55AM +0100, Michael Ellerman wrote:
On Mon, 2015-08-17 at 09:57 +0100, Will Deacon wrote:
On Mon, Aug 17, 2015 at 07:15:01AM +0100, Paul E. McKenney wrote:
On Mon, Aug 17, 2015 at 02:06:07PM +1000,
On Thu, Aug 20, 2015 at 10:45:05AM +0100, Michael Ellerman wrote:
On Tue, 2015-08-18 at 09:37 +0100, Will Deacon wrote:
On Tue, Aug 18, 2015 at 02:50:55AM +0100, Michael Ellerman wrote:
On Mon, 2015-08-17 at 09:57 +0100, Will Deacon wrote:
On Mon, Aug 17, 2015 at 07:15:01AM +0100, Paul
On Tue, Aug 18, 2015 at 02:50:55AM +0100, Michael Ellerman wrote:
> On Mon, 2015-08-17 at 09:57 +0100, Will Deacon wrote:
> > On Mon, Aug 17, 2015 at 07:15:01AM +0100, Paul E. McKenney wrote:
> > > On Mon, Aug 17, 2015 at 02:06:07PM +1000, Michael Ellerman wrote:
> > > > On Wed, 2015-08-12 at
On Tue, Aug 18, 2015 at 02:50:55AM +0100, Michael Ellerman wrote:
On Mon, 2015-08-17 at 09:57 +0100, Will Deacon wrote:
On Mon, Aug 17, 2015 at 07:15:01AM +0100, Paul E. McKenney wrote:
On Mon, Aug 17, 2015 at 02:06:07PM +1000, Michael Ellerman wrote:
On Wed, 2015-08-12 at 08:43 -0700,
On Mon, 2015-08-17 at 09:57 +0100, Will Deacon wrote:
> On Mon, Aug 17, 2015 at 07:15:01AM +0100, Paul E. McKenney wrote:
> > On Mon, Aug 17, 2015 at 02:06:07PM +1000, Michael Ellerman wrote:
> > > On Wed, 2015-08-12 at 08:43 -0700, Paul E. McKenney wrote:
> > > I thought the end result of this
On Mon, Aug 17, 2015 at 07:15:01AM +0100, Paul E. McKenney wrote:
> On Mon, Aug 17, 2015 at 02:06:07PM +1000, Michael Ellerman wrote:
> > On Wed, 2015-08-12 at 08:43 -0700, Paul E. McKenney wrote:
> > > On Wed, Aug 12, 2015 at 02:44:15PM +0100, Will Deacon wrote:
> > > > On Fri, Jul 24, 2015 at
On Mon, Aug 17, 2015 at 02:06:07PM +1000, Michael Ellerman wrote:
> On Wed, 2015-08-12 at 08:43 -0700, Paul E. McKenney wrote:
> > On Wed, Aug 12, 2015 at 02:44:15PM +0100, Will Deacon wrote:
> > > Hello Paul,
> > >
> > > On Fri, Jul 24, 2015 at 04:30:46PM +0100, Paul E. McKenney wrote:
> > > >
On Mon, Aug 17, 2015 at 07:15:01AM +0100, Paul E. McKenney wrote:
On Mon, Aug 17, 2015 at 02:06:07PM +1000, Michael Ellerman wrote:
On Wed, 2015-08-12 at 08:43 -0700, Paul E. McKenney wrote:
On Wed, Aug 12, 2015 at 02:44:15PM +0100, Will Deacon wrote:
On Fri, Jul 24, 2015 at 04:30:46PM
On Mon, 2015-08-17 at 09:57 +0100, Will Deacon wrote:
On Mon, Aug 17, 2015 at 07:15:01AM +0100, Paul E. McKenney wrote:
On Mon, Aug 17, 2015 at 02:06:07PM +1000, Michael Ellerman wrote:
On Wed, 2015-08-12 at 08:43 -0700, Paul E. McKenney wrote:
I thought the end result of this thread was
On Mon, Aug 17, 2015 at 02:06:07PM +1000, Michael Ellerman wrote:
On Wed, 2015-08-12 at 08:43 -0700, Paul E. McKenney wrote:
On Wed, Aug 12, 2015 at 02:44:15PM +0100, Will Deacon wrote:
Hello Paul,
On Fri, Jul 24, 2015 at 04:30:46PM +0100, Paul E. McKenney wrote:
On Fri, Jul 24,
On Wed, 2015-08-12 at 08:43 -0700, Paul E. McKenney wrote:
> On Wed, Aug 12, 2015 at 02:44:15PM +0100, Will Deacon wrote:
> > Hello Paul,
> >
> > On Fri, Jul 24, 2015 at 04:30:46PM +0100, Paul E. McKenney wrote:
> > > On Fri, Jul 24, 2015 at 12:31:01PM +0100, Will Deacon wrote:
> > > > On Wed,
On Wed, 2015-08-12 at 08:43 -0700, Paul E. McKenney wrote:
On Wed, Aug 12, 2015 at 02:44:15PM +0100, Will Deacon wrote:
Hello Paul,
On Fri, Jul 24, 2015 at 04:30:46PM +0100, Paul E. McKenney wrote:
On Fri, Jul 24, 2015 at 12:31:01PM +0100, Will Deacon wrote:
On Wed, Jul 15, 2015 at
On Thu, Aug 13, 2015 at 11:49:28AM +0100, Will Deacon wrote:
> On Wed, Aug 12, 2015 at 06:59:38PM +0100, Paul E. McKenney wrote:
> > On Wed, Aug 12, 2015 at 08:43:46AM -0700, Paul E. McKenney wrote:
> > > On Wed, Aug 12, 2015 at 02:44:15PM +0100, Will Deacon wrote:
> > > > The generic relaxed
On Wed, Aug 12, 2015 at 06:59:38PM +0100, Paul E. McKenney wrote:
> On Wed, Aug 12, 2015 at 08:43:46AM -0700, Paul E. McKenney wrote:
> > On Wed, Aug 12, 2015 at 02:44:15PM +0100, Will Deacon wrote:
> > > The generic relaxed atomics are now queued in -tip, so it would be really
> > > good to see
On Wed, Aug 12, 2015 at 06:59:38PM +0100, Paul E. McKenney wrote:
On Wed, Aug 12, 2015 at 08:43:46AM -0700, Paul E. McKenney wrote:
On Wed, Aug 12, 2015 at 02:44:15PM +0100, Will Deacon wrote:
The generic relaxed atomics are now queued in -tip, so it would be really
good to see this
On Thu, Aug 13, 2015 at 11:49:28AM +0100, Will Deacon wrote:
On Wed, Aug 12, 2015 at 06:59:38PM +0100, Paul E. McKenney wrote:
On Wed, Aug 12, 2015 at 08:43:46AM -0700, Paul E. McKenney wrote:
On Wed, Aug 12, 2015 at 02:44:15PM +0100, Will Deacon wrote:
The generic relaxed atomics are
On Wed, Aug 12, 2015 at 08:43:46AM -0700, Paul E. McKenney wrote:
> On Wed, Aug 12, 2015 at 02:44:15PM +0100, Will Deacon wrote:
> > Hello Paul,
> >
> > On Fri, Jul 24, 2015 at 04:30:46PM +0100, Paul E. McKenney wrote:
> > > On Fri, Jul 24, 2015 at 12:31:01PM +0100, Will Deacon wrote:
> > > > On
On Wed, Aug 12, 2015 at 02:44:15PM +0100, Will Deacon wrote:
> Hello Paul,
>
> On Fri, Jul 24, 2015 at 04:30:46PM +0100, Paul E. McKenney wrote:
> > On Fri, Jul 24, 2015 at 12:31:01PM +0100, Will Deacon wrote:
> > > On Wed, Jul 15, 2015 at 02:12:21PM +0100, Paul E. McKenney wrote:
> > > > > >
Hello Paul,
On Fri, Jul 24, 2015 at 04:30:46PM +0100, Paul E. McKenney wrote:
> On Fri, Jul 24, 2015 at 12:31:01PM +0100, Will Deacon wrote:
> > On Wed, Jul 15, 2015 at 02:12:21PM +0100, Paul E. McKenney wrote:
> > > > > commit 695c05d4b9666c50b40a1c022678b5f6e2e3e771
> > > > > Author: Paul E.
On Wed, Aug 12, 2015 at 02:44:15PM +0100, Will Deacon wrote:
Hello Paul,
On Fri, Jul 24, 2015 at 04:30:46PM +0100, Paul E. McKenney wrote:
On Fri, Jul 24, 2015 at 12:31:01PM +0100, Will Deacon wrote:
On Wed, Jul 15, 2015 at 02:12:21PM +0100, Paul E. McKenney wrote:
commit
Hello Paul,
On Fri, Jul 24, 2015 at 04:30:46PM +0100, Paul E. McKenney wrote:
On Fri, Jul 24, 2015 at 12:31:01PM +0100, Will Deacon wrote:
On Wed, Jul 15, 2015 at 02:12:21PM +0100, Paul E. McKenney wrote:
commit 695c05d4b9666c50b40a1c022678b5f6e2e3e771
Author: Paul E. McKenney
On Wed, Aug 12, 2015 at 08:43:46AM -0700, Paul E. McKenney wrote:
On Wed, Aug 12, 2015 at 02:44:15PM +0100, Will Deacon wrote:
Hello Paul,
On Fri, Jul 24, 2015 at 04:30:46PM +0100, Paul E. McKenney wrote:
On Fri, Jul 24, 2015 at 12:31:01PM +0100, Will Deacon wrote:
On Wed, Jul 15,
On Fri, Jul 24, 2015 at 12:31:01PM +0100, Will Deacon wrote:
> Hi Paul,
>
> On Wed, Jul 15, 2015 at 02:12:21PM +0100, Paul E. McKenney wrote:
> > On Wed, Jul 15, 2015 at 11:51:35AM +0100, Will Deacon wrote:
> > > On Wed, Jul 15, 2015 at 02:38:20AM +0100, Paul E. McKenney wrote:
> > > > On Tue,
Hi Paul,
On Wed, Jul 15, 2015 at 02:12:21PM +0100, Paul E. McKenney wrote:
> On Wed, Jul 15, 2015 at 11:51:35AM +0100, Will Deacon wrote:
> > On Wed, Jul 15, 2015 at 02:38:20AM +0100, Paul E. McKenney wrote:
> > > On Tue, Jul 14, 2015 at 12:31:44PM -0700, Paul E. McKenney wrote:
> > > > On Tue,
Hi Paul,
On Wed, Jul 15, 2015 at 02:12:21PM +0100, Paul E. McKenney wrote:
On Wed, Jul 15, 2015 at 11:51:35AM +0100, Will Deacon wrote:
On Wed, Jul 15, 2015 at 02:38:20AM +0100, Paul E. McKenney wrote:
On Tue, Jul 14, 2015 at 12:31:44PM -0700, Paul E. McKenney wrote:
On Tue, Jul 14,
On Fri, Jul 24, 2015 at 12:31:01PM +0100, Will Deacon wrote:
Hi Paul,
On Wed, Jul 15, 2015 at 02:12:21PM +0100, Paul E. McKenney wrote:
On Wed, Jul 15, 2015 at 11:51:35AM +0100, Will Deacon wrote:
On Wed, Jul 15, 2015 at 02:38:20AM +0100, Paul E. McKenney wrote:
On Tue, Jul 14, 2015
On Mon, Jul 20, 2015 at 10:18:14PM +0100, Benjamin Herrenschmidt wrote:
> On Mon, 2015-07-20 at 14:39 +0100, Will Deacon wrote:
> > On Fri, Jul 17, 2015 at 11:14:14PM +0100, Benjamin Herrenschmidt wrote:
> > > On Fri, 2015-07-17 at 10:32 +0100, Will Deacon wrote:
> > > > static inline void
On Mon, Jul 20, 2015 at 10:18:14PM +0100, Benjamin Herrenschmidt wrote:
On Mon, 2015-07-20 at 14:39 +0100, Will Deacon wrote:
On Fri, Jul 17, 2015 at 11:14:14PM +0100, Benjamin Herrenschmidt wrote:
On Fri, 2015-07-17 at 10:32 +0100, Will Deacon wrote:
static inline void
On Mon, 2015-07-20 at 14:39 +0100, Will Deacon wrote:
> On Fri, Jul 17, 2015 at 11:14:14PM +0100, Benjamin Herrenschmidt wrote:
> > On Fri, 2015-07-17 at 10:32 +0100, Will Deacon wrote:
> > > static inline void arch_spin_unlock(arch_spinlock_t *lock)
> > > {
> > > - SYNC_IO;
> > > -
On Mon, Jul 20, 2015 at 02:48:49PM +0100, Paul E. McKenney wrote:
> On Mon, Jul 20, 2015 at 02:39:06PM +0100, Will Deacon wrote:
> > On Fri, Jul 17, 2015 at 11:14:14PM +0100, Benjamin Herrenschmidt wrote:
> > > On Fri, 2015-07-17 at 10:32 +0100, Will Deacon wrote:
> > > > static inline void
On Mon, Jul 20, 2015 at 02:39:06PM +0100, Will Deacon wrote:
> On Fri, Jul 17, 2015 at 11:14:14PM +0100, Benjamin Herrenschmidt wrote:
> > On Fri, 2015-07-17 at 10:32 +0100, Will Deacon wrote:
> > > static inline void arch_spin_unlock(arch_spinlock_t *lock)
> > > {
> > > - SYNC_IO;
> > > -
On Fri, Jul 17, 2015 at 11:14:14PM +0100, Benjamin Herrenschmidt wrote:
> On Fri, 2015-07-17 at 10:32 +0100, Will Deacon wrote:
> > static inline void arch_spin_unlock(arch_spinlock_t *lock)
> > {
> > - SYNC_IO;
> > - __asm__ __volatile__("# arch_spin_unlock\n\t"
> > -
On Fri, Jul 17, 2015 at 11:14:14PM +0100, Benjamin Herrenschmidt wrote:
On Fri, 2015-07-17 at 10:32 +0100, Will Deacon wrote:
static inline void arch_spin_unlock(arch_spinlock_t *lock)
{
- SYNC_IO;
- __asm__ __volatile__(# arch_spin_unlock\n\t
-
On Mon, Jul 20, 2015 at 02:39:06PM +0100, Will Deacon wrote:
On Fri, Jul 17, 2015 at 11:14:14PM +0100, Benjamin Herrenschmidt wrote:
On Fri, 2015-07-17 at 10:32 +0100, Will Deacon wrote:
static inline void arch_spin_unlock(arch_spinlock_t *lock)
{
- SYNC_IO;
- __asm__
On Mon, Jul 20, 2015 at 02:48:49PM +0100, Paul E. McKenney wrote:
On Mon, Jul 20, 2015 at 02:39:06PM +0100, Will Deacon wrote:
On Fri, Jul 17, 2015 at 11:14:14PM +0100, Benjamin Herrenschmidt wrote:
On Fri, 2015-07-17 at 10:32 +0100, Will Deacon wrote:
static inline void
On Mon, 2015-07-20 at 14:39 +0100, Will Deacon wrote:
On Fri, Jul 17, 2015 at 11:14:14PM +0100, Benjamin Herrenschmidt wrote:
On Fri, 2015-07-17 at 10:32 +0100, Will Deacon wrote:
static inline void arch_spin_unlock(arch_spinlock_t *lock)
{
- SYNC_IO;
- __asm__
On Fri, 2015-07-17 at 10:32 +0100, Will Deacon wrote:
> static inline void arch_spin_unlock(arch_spinlock_t *lock)
> {
> - SYNC_IO;
> - __asm__ __volatile__("# arch_spin_unlock\n\t"
> - PPC_RELEASE_BARRIER: : :"memory");
> + smp_mb();
>
On Fri, Jul 17, 2015 at 12:15:35PM +0200, Peter Zijlstra wrote:
> On Fri, Jul 17, 2015 at 10:32:21AM +0100, Will Deacon wrote:
> > @@ -158,9 +140,7 @@ void arch_spin_lock_flags(arch_spinlock_t *lock,
> > unsigned long flags)
> >
> > static inline void arch_spin_unlock(arch_spinlock_t *lock)
>
On Fri, Jul 17, 2015 at 10:32:21AM +0100, Will Deacon wrote:
> @@ -158,9 +140,7 @@ void arch_spin_lock_flags(arch_spinlock_t *lock, unsigned
> long flags)
>
> static inline void arch_spin_unlock(arch_spinlock_t *lock)
> {
> - SYNC_IO;
> - __asm__ __volatile__("# arch_spin_unlock\n\t"
On Thu, Jul 16, 2015 at 11:54:25PM +0100, Benjamin Herrenschmidt wrote:
> On Thu, 2015-07-16 at 08:11 -0700, Paul E. McKenney wrote:
> > > So isync in lock in architecturally incorrect, despite being what
> > the
> > > architecture recommends using, yay !
> >
> > Well, the architecture isn't
On Fri, Jul 17, 2015 at 12:15:35PM +0200, Peter Zijlstra wrote:
On Fri, Jul 17, 2015 at 10:32:21AM +0100, Will Deacon wrote:
@@ -158,9 +140,7 @@ void arch_spin_lock_flags(arch_spinlock_t *lock,
unsigned long flags)
static inline void arch_spin_unlock(arch_spinlock_t *lock)
{
-
On Thu, Jul 16, 2015 at 11:54:25PM +0100, Benjamin Herrenschmidt wrote:
On Thu, 2015-07-16 at 08:11 -0700, Paul E. McKenney wrote:
So isync in lock in architecturally incorrect, despite being what
the
architecture recommends using, yay !
Well, the architecture isn't expecting that
On Fri, Jul 17, 2015 at 10:32:21AM +0100, Will Deacon wrote:
@@ -158,9 +140,7 @@ void arch_spin_lock_flags(arch_spinlock_t *lock, unsigned
long flags)
static inline void arch_spin_unlock(arch_spinlock_t *lock)
{
- SYNC_IO;
- __asm__ __volatile__(# arch_spin_unlock\n\t
-
On Fri, 2015-07-17 at 10:32 +0100, Will Deacon wrote:
static inline void arch_spin_unlock(arch_spinlock_t *lock)
{
- SYNC_IO;
- __asm__ __volatile__(# arch_spin_unlock\n\t
- PPC_RELEASE_BARRIER: : :memory);
+ smp_mb();
lock-slock =
On Thu, 2015-07-16 at 08:11 -0700, Paul E. McKenney wrote:
> > So isync in lock in architecturally incorrect, despite being what
> the
> > architecture recommends using, yay !
>
> Well, the architecture isn't expecting that crazies like myself would
> want to have an unlock-lock provide ordering
On Thu, Jul 16, 2015 at 03:14:55PM +1000, Benjamin Herrenschmidt wrote:
> On Thu, 2015-07-16 at 15:03 +1000, Benjamin Herrenschmidt wrote:
> > On Thu, 2015-07-16 at 12:00 +1000, Michael Ellerman wrote:
> > > That would fix the problem with smp_mb__after_unlock_lock(), but not
> > > the original
On Thu, Jul 16, 2015 at 03:14:55PM +1000, Benjamin Herrenschmidt wrote:
On Thu, 2015-07-16 at 15:03 +1000, Benjamin Herrenschmidt wrote:
On Thu, 2015-07-16 at 12:00 +1000, Michael Ellerman wrote:
That would fix the problem with smp_mb__after_unlock_lock(), but not
the original worry we
On Thu, 2015-07-16 at 08:11 -0700, Paul E. McKenney wrote:
So isync in lock in architecturally incorrect, despite being what
the
architecture recommends using, yay !
Well, the architecture isn't expecting that crazies like myself would
want to have an unlock-lock provide ordering to some
On Thu, 2015-07-16 at 15:03 +1000, Benjamin Herrenschmidt wrote:
> On Thu, 2015-07-16 at 12:00 +1000, Michael Ellerman wrote:
> > That would fix the problem with smp_mb__after_unlock_lock(), but not
> > the original worry we had about loads happening before the SC in lock.
>
> However I think
On Thu, 2015-07-16 at 12:00 +1000, Michael Ellerman wrote:
> That would fix the problem with smp_mb__after_unlock_lock(), but not
> the original worry we had about loads happening before the SC in lock.
However I think isync fixes *that* :-) The problem with isync is as you
said, it's not a
On Wed, 2015-07-15 at 11:44 +0100, Will Deacon wrote:
> Hi Michael,
>
> On Wed, Jul 15, 2015 at 04:06:18AM +0100, Michael Ellerman wrote:
> > On Tue, 2015-07-14 at 08:31 +1000, Benjamin Herrenschmidt wrote:
> > > On Mon, 2015-07-13 at 13:15 +0100, Will Deacon wrote:
> > > > This didn't go
On Wed, 2015-07-15 at 07:18 -0700, Paul E. McKenney wrote:
> On Wed, Jul 15, 2015 at 01:06:18PM +1000, Michael Ellerman wrote:
> > On Tue, 2015-07-14 at 08:31 +1000, Benjamin Herrenschmidt wrote:
> > > Michael, at some point you were experimenting a bit with that and tried
> > > to get some perf
On Wed, Jul 15, 2015 at 01:06:18PM +1000, Michael Ellerman wrote:
> On Tue, 2015-07-14 at 08:31 +1000, Benjamin Herrenschmidt wrote:
> > On Mon, 2015-07-13 at 13:15 +0100, Will Deacon wrote:
> > > smp_mb__after_unlock_lock is used to promote an UNLOCK + LOCK sequence
> > > into a full memory
On Wed, Jul 15, 2015 at 11:51:35AM +0100, Will Deacon wrote:
> Hi Paul,
>
> On Wed, Jul 15, 2015 at 02:38:20AM +0100, Paul E. McKenney wrote:
> > On Tue, Jul 14, 2015 at 12:31:44PM -0700, Paul E. McKenney wrote:
> > > On Tue, Jul 14, 2015 at 03:12:16PM +0100, Will Deacon wrote:
> > > > On Tue,
Hi Paul,
On Wed, Jul 15, 2015 at 02:38:20AM +0100, Paul E. McKenney wrote:
> On Tue, Jul 14, 2015 at 12:31:44PM -0700, Paul E. McKenney wrote:
> > On Tue, Jul 14, 2015 at 03:12:16PM +0100, Will Deacon wrote:
> > > On Tue, Jul 14, 2015 at 03:00:14PM +0100, Paul E. McKenney wrote:
> > > > On Tue,
Hi Michael,
On Wed, Jul 15, 2015 at 04:06:18AM +0100, Michael Ellerman wrote:
> On Tue, 2015-07-14 at 08:31 +1000, Benjamin Herrenschmidt wrote:
> > On Mon, 2015-07-13 at 13:15 +0100, Will Deacon wrote:
> > > This didn't go anywhere last time I posted it, but here it is again.
> > > I'd really
On Thu, 2015-07-16 at 12:00 +1000, Michael Ellerman wrote:
That would fix the problem with smp_mb__after_unlock_lock(), but not
the original worry we had about loads happening before the SC in lock.
However I think isync fixes *that* :-) The problem with isync is as you
said, it's not a
On Wed, 2015-07-15 at 11:44 +0100, Will Deacon wrote:
Hi Michael,
On Wed, Jul 15, 2015 at 04:06:18AM +0100, Michael Ellerman wrote:
On Tue, 2015-07-14 at 08:31 +1000, Benjamin Herrenschmidt wrote:
On Mon, 2015-07-13 at 13:15 +0100, Will Deacon wrote:
This didn't go anywhere last time
On Thu, 2015-07-16 at 15:03 +1000, Benjamin Herrenschmidt wrote:
On Thu, 2015-07-16 at 12:00 +1000, Michael Ellerman wrote:
That would fix the problem with smp_mb__after_unlock_lock(), but not
the original worry we had about loads happening before the SC in lock.
However I think isync
On Wed, 2015-07-15 at 07:18 -0700, Paul E. McKenney wrote:
On Wed, Jul 15, 2015 at 01:06:18PM +1000, Michael Ellerman wrote:
On Tue, 2015-07-14 at 08:31 +1000, Benjamin Herrenschmidt wrote:
Michael, at some point you were experimenting a bit with that and tried
to get some perf numbers of
Hi Paul,
On Wed, Jul 15, 2015 at 02:38:20AM +0100, Paul E. McKenney wrote:
On Tue, Jul 14, 2015 at 12:31:44PM -0700, Paul E. McKenney wrote:
On Tue, Jul 14, 2015 at 03:12:16PM +0100, Will Deacon wrote:
On Tue, Jul 14, 2015 at 03:00:14PM +0100, Paul E. McKenney wrote:
On Tue, Jul 14,
Hi Michael,
On Wed, Jul 15, 2015 at 04:06:18AM +0100, Michael Ellerman wrote:
On Tue, 2015-07-14 at 08:31 +1000, Benjamin Herrenschmidt wrote:
On Mon, 2015-07-13 at 13:15 +0100, Will Deacon wrote:
This didn't go anywhere last time I posted it, but here it is again.
I'd really appreciate
On Wed, Jul 15, 2015 at 01:06:18PM +1000, Michael Ellerman wrote:
On Tue, 2015-07-14 at 08:31 +1000, Benjamin Herrenschmidt wrote:
On Mon, 2015-07-13 at 13:15 +0100, Will Deacon wrote:
smp_mb__after_unlock_lock is used to promote an UNLOCK + LOCK sequence
into a full memory barrier.
On Wed, Jul 15, 2015 at 11:51:35AM +0100, Will Deacon wrote:
Hi Paul,
On Wed, Jul 15, 2015 at 02:38:20AM +0100, Paul E. McKenney wrote:
On Tue, Jul 14, 2015 at 12:31:44PM -0700, Paul E. McKenney wrote:
On Tue, Jul 14, 2015 at 03:12:16PM +0100, Will Deacon wrote:
On Tue, Jul 14, 2015
On Tue, 2015-07-14 at 08:31 +1000, Benjamin Herrenschmidt wrote:
> On Mon, 2015-07-13 at 13:15 +0100, Will Deacon wrote:
> > smp_mb__after_unlock_lock is used to promote an UNLOCK + LOCK sequence
> > into a full memory barrier.
> >
> > However:
> >
> > - This ordering guarantee is already
On Tue, Jul 14, 2015 at 12:31:44PM -0700, Paul E. McKenney wrote:
> On Tue, Jul 14, 2015 at 03:12:16PM +0100, Will Deacon wrote:
> > On Tue, Jul 14, 2015 at 03:00:14PM +0100, Paul E. McKenney wrote:
> > > On Tue, Jul 14, 2015 at 01:51:46PM +0100, Will Deacon wrote:
> > > > On Tue, Jul 14, 2015 at
On Tue, Jul 14, 2015 at 03:12:16PM +0100, Will Deacon wrote:
> On Tue, Jul 14, 2015 at 03:00:14PM +0100, Paul E. McKenney wrote:
> > On Tue, Jul 14, 2015 at 01:51:46PM +0100, Will Deacon wrote:
> > > On Tue, Jul 14, 2015 at 01:45:40PM +0100, Paul E. McKenney wrote:
> > > > On Tue, Jul 14, 2015 at
On Tue, Jul 14, 2015 at 03:00:14PM +0100, Paul E. McKenney wrote:
> On Tue, Jul 14, 2015 at 01:51:46PM +0100, Will Deacon wrote:
> > On Tue, Jul 14, 2015 at 01:45:40PM +0100, Paul E. McKenney wrote:
> > > On Tue, Jul 14, 2015 at 11:04:29AM +0100, Will Deacon wrote:
> > > > Given that RCU is
On Tue, Jul 14, 2015 at 01:51:46PM +0100, Will Deacon wrote:
> Hi Paul,
>
> On Tue, Jul 14, 2015 at 01:45:40PM +0100, Paul E. McKenney wrote:
> > On Tue, Jul 14, 2015 at 11:04:29AM +0100, Will Deacon wrote:
> > > Given that RCU is currently the only user of this barrier, how would you
> > > feel
Hi Paul,
On Tue, Jul 14, 2015 at 01:45:40PM +0100, Paul E. McKenney wrote:
> On Tue, Jul 14, 2015 at 11:04:29AM +0100, Will Deacon wrote:
> > Given that RCU is currently the only user of this barrier, how would you
> > feel about making the barrier local to RCU and not part of the general
> >
On Tue, Jul 14, 2015 at 11:04:29AM +0100, Will Deacon wrote:
> On Tue, Jul 14, 2015 at 12:04:06AM +0100, Paul E. McKenney wrote:
> > On Tue, Jul 14, 2015 at 12:23:46AM +0200, Peter Zijlstra wrote:
> > > If we look at the inside of the critical section again -- similar
> > > argument as before:
> >
On Mon, Jul 13, 2015 at 11:31:29PM +0100, Benjamin Herrenschmidt wrote:
> On Mon, 2015-07-13 at 13:15 +0100, Will Deacon wrote:
> > This didn't go anywhere last time I posted it, but here it is again.
> > I'd really appreciate some feedback from the PowerPC guys, especially as
> > to whether this
On Tue, Jul 14, 2015 at 12:04:06AM +0100, Paul E. McKenney wrote:
> On Tue, Jul 14, 2015 at 12:23:46AM +0200, Peter Zijlstra wrote:
> > If we look at the inside of the critical section again -- similar
> > argument as before:
> >
> > *A = a
> > smp_mb()
> > store M
> > load N
> >
On Tue, Jul 14, 2015 at 08:43:44AM +1000, Benjamin Herrenschmidt wrote:
> On Tue, 2015-07-14 at 00:15 +0200, Peter Zijlstra wrote:
>
> > > This is instead the sequence that is of concern:
> > >
> > > store a
> > > unlock M
> > > lock N
> > > load b
> >
> > So its late and that table
On Mon, Jul 13, 2015 at 11:31:29PM +0100, Benjamin Herrenschmidt wrote:
On Mon, 2015-07-13 at 13:15 +0100, Will Deacon wrote:
This didn't go anywhere last time I posted it, but here it is again.
I'd really appreciate some feedback from the PowerPC guys, especially as
to whether this change
On Tue, Jul 14, 2015 at 08:43:44AM +1000, Benjamin Herrenschmidt wrote:
On Tue, 2015-07-14 at 00:15 +0200, Peter Zijlstra wrote:
This is instead the sequence that is of concern:
store a
unlock M
lock N
load b
So its late and that table didn't parse, but that
On Tue, Jul 14, 2015 at 12:04:06AM +0100, Paul E. McKenney wrote:
On Tue, Jul 14, 2015 at 12:23:46AM +0200, Peter Zijlstra wrote:
If we look at the inside of the critical section again -- similar
argument as before:
*A = a
smp_mb()
store M
load N
smp_mb()
On Tue, Jul 14, 2015 at 11:04:29AM +0100, Will Deacon wrote:
On Tue, Jul 14, 2015 at 12:04:06AM +0100, Paul E. McKenney wrote:
On Tue, Jul 14, 2015 at 12:23:46AM +0200, Peter Zijlstra wrote:
If we look at the inside of the critical section again -- similar
argument as before:
*A
Hi Paul,
On Tue, Jul 14, 2015 at 01:45:40PM +0100, Paul E. McKenney wrote:
On Tue, Jul 14, 2015 at 11:04:29AM +0100, Will Deacon wrote:
Given that RCU is currently the only user of this barrier, how would you
feel about making the barrier local to RCU and not part of the general
On Tue, Jul 14, 2015 at 03:00:14PM +0100, Paul E. McKenney wrote:
On Tue, Jul 14, 2015 at 01:51:46PM +0100, Will Deacon wrote:
On Tue, Jul 14, 2015 at 01:45:40PM +0100, Paul E. McKenney wrote:
On Tue, Jul 14, 2015 at 11:04:29AM +0100, Will Deacon wrote:
Given that RCU is currently the
On Tue, Jul 14, 2015 at 01:51:46PM +0100, Will Deacon wrote:
Hi Paul,
On Tue, Jul 14, 2015 at 01:45:40PM +0100, Paul E. McKenney wrote:
On Tue, Jul 14, 2015 at 11:04:29AM +0100, Will Deacon wrote:
Given that RCU is currently the only user of this barrier, how would you
feel about
On Tue, Jul 14, 2015 at 03:12:16PM +0100, Will Deacon wrote:
On Tue, Jul 14, 2015 at 03:00:14PM +0100, Paul E. McKenney wrote:
On Tue, Jul 14, 2015 at 01:51:46PM +0100, Will Deacon wrote:
On Tue, Jul 14, 2015 at 01:45:40PM +0100, Paul E. McKenney wrote:
On Tue, Jul 14, 2015 at 11:04:29AM
On Tue, Jul 14, 2015 at 12:31:44PM -0700, Paul E. McKenney wrote:
On Tue, Jul 14, 2015 at 03:12:16PM +0100, Will Deacon wrote:
On Tue, Jul 14, 2015 at 03:00:14PM +0100, Paul E. McKenney wrote:
On Tue, Jul 14, 2015 at 01:51:46PM +0100, Will Deacon wrote:
On Tue, Jul 14, 2015 at 01:45:40PM
On Tue, 2015-07-14 at 08:31 +1000, Benjamin Herrenschmidt wrote:
On Mon, 2015-07-13 at 13:15 +0100, Will Deacon wrote:
smp_mb__after_unlock_lock is used to promote an UNLOCK + LOCK sequence
into a full memory barrier.
However:
- This ordering guarantee is already provided without
On Tue, Jul 14, 2015 at 12:23:46AM +0200, Peter Zijlstra wrote:
> On Mon, Jul 13, 2015 at 01:20:32PM -0700, Paul E. McKenney wrote:
> > On Mon, Jul 13, 2015 at 06:50:29PM +0100, Will Deacon wrote:
>
> > > So if I'm following along, smp_mb__after_unlock_lock *does* provide
> > > transitivity when
On Tue, Jul 14, 2015 at 12:15:03AM +0200, Peter Zijlstra wrote:
> On Mon, Jul 13, 2015 at 01:16:42PM -0700, Paul E. McKenney wrote:
> > On Mon, Jul 13, 2015 at 03:41:53PM -0400, Peter Hurley wrote:
> > > > Does that answer the question, or am I missing the point?
> > >
> > > Yes, it shows that
On Tue, 2015-07-14 at 00:15 +0200, Peter Zijlstra wrote:
> > This is instead the sequence that is of concern:
> >
> > store a
> > unlock M
> > lock N
> > load b
>
> So its late and that table didn't parse, but that should be ordered too.
> The load of b should not be able to
On Mon, 2015-07-13 at 17:54 +0200, Peter Zijlstra wrote:
> That said, I don't think this could even happen on PPC because we have
> load_acquire and store_release, this means that:
>
> *A = a
> lwsync
> store_release M
> load_acquire N
> lwsync
> *B = b
>
>
On Mon, 2015-07-13 at 13:15 +0100, Will Deacon wrote:
> smp_mb__after_unlock_lock is used to promote an UNLOCK + LOCK sequence
> into a full memory barrier.
>
> However:
>
> - This ordering guarantee is already provided without the barrier on
> all architectures apart from PowerPC
>
> -
On Mon, Jul 13, 2015 at 01:20:32PM -0700, Paul E. McKenney wrote:
> On Mon, Jul 13, 2015 at 06:50:29PM +0100, Will Deacon wrote:
> > So if I'm following along, smp_mb__after_unlock_lock *does* provide
> > transitivity when used with UNLOCK + LOCK, which is stronger than your
> > example here.
>
On Mon, Jul 13, 2015 at 01:16:42PM -0700, Paul E. McKenney wrote:
> On Mon, Jul 13, 2015 at 03:41:53PM -0400, Peter Hurley wrote:
> > > Does that answer the question, or am I missing the point?
> >
> > Yes, it shows that smp_mb__after_unlock_lock() has no purpose, since it
> > is defined only for
On Mon, Jul 13, 2015 at 06:50:29PM +0100, Will Deacon wrote:
> On Mon, Jul 13, 2015 at 04:54:47PM +0100, Peter Zijlstra wrote:
> > However I think we should look at the insides of the critical sections;
> > for example (from Documentation/memory-barriers.txt):
> >
> > " *A = a;
> >
1 - 100 of 132 matches
Mail list logo
