Groups > linux.kernel > #1209000

Re: [RFC PATCH v2] memory-barriers: remove smp_mb__after_unlock_lock()

From	Michael Ellerman <mpe@ellerman.id.au>
Newsgroups	linux.kernel
Subject	Re: [RFC PATCH v2] memory-barriers: remove smp_mb__after_unlock_lock()
Date	2015-08-18 04:00 +0200
Message-ID	<pYElX-7Y-3@gated-at.bofh.it> (permalink)
References	(6 earlier) <pWEzM-61F-25@gated-at.bofh.it> <pWGrU-hj-1@gated-at.bofh.it> <pYjUd-4vi-1@gated-at.bofh.it> <pYlW1-7oA-7@gated-at.bofh.it> <pYoqS-2nw-17@gated-at.bofh.it>
Organization	linux.* mail to news gateway

Show all headers | View raw

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 that we didn't *need* to change the
> > > powerpc lock semantics? Or did I read it wrong?
> > > 
> > > ie. the docs now say that RELEASE+ACQUIRE is not a full barrier, which is
> > > consistent with our current implementation.
> > 
> > That change happened about 1.5 years ago, and I thought that the
> > current discussion was about reversing it, based in part on the
> > recent powerpc benchmarks of locking primitives with and without the
> > sync instruction.  But regardless, I clearly cannot remove either the
> > smp_mb__after_unlock_lock() or the powerpc definition of it to be smp_mb()
> > if powerpc unlock/lock is not strengthened.
> 
> Yup. Peter and I would really like to get rid of smp_mb__after_unlock_lock
> entirely, which would mean strengthening the ppc spinlocks. Moving the
> barrier primitive into RCU is a good step to prevent more widespread usage
> of the barrier, but we'd really like to go further if the performance impact
> is deemed acceptable (which is what this thread is about).

OK, sorry for completely missing the point, too many balls in the air here.

I'll do some benchmarks and see what we come up with.

cheers


--
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/

Thread

Re: [RFC PATCH v2] memory-barriers: remove  smp_mb__after_unlock_lock() Will Deacon <will.deacon@arm.com> - 2015-08-12 15:50 +0200
  Re: [RFC PATCH v2] memory-barriers: remove  smp_mb__after_unlock_lock() "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> - 2015-08-12 17:50 +0200
    Re: [RFC PATCH v2] memory-barriers: remove  smp_mb__after_unlock_lock() "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> - 2015-08-12 20:00 +0200
      Re: [RFC PATCH v2] memory-barriers: remove  smp_mb__after_unlock_lock() Will Deacon <will.deacon@arm.com> - 2015-08-13 12:50 +0200
        Re: [RFC PATCH v2] memory-barriers: remove  smp_mb__after_unlock_lock() "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> - 2015-08-13 15:20 +0200
    Re: [RFC PATCH v2] memory-barriers: remove  smp_mb__after_unlock_lock() Michael Ellerman <mpe@ellerman.id.au> - 2015-08-17 06:10 +0200
      Re: [RFC PATCH v2] memory-barriers: remove  smp_mb__after_unlock_lock() "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> - 2015-08-17 08:20 +0200
        Re: [RFC PATCH v2] memory-barriers: remove  smp_mb__after_unlock_lock() Will Deacon <will.deacon@arm.com> - 2015-08-17 11:00 +0200
          Re: [RFC PATCH v2] memory-barriers: remove  smp_mb__after_unlock_lock() Michael Ellerman <mpe@ellerman.id.au> - 2015-08-18 04:00 +0200
            Re: [RFC PATCH v2] memory-barriers: remove  smp_mb__after_unlock_lock() Will Deacon <will.deacon@arm.com> - 2015-08-18 10:40 +0200

csiph-web