Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1183570

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

Show all headers | View raw

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()
> > 	*B = b
> > 
> > A and B are fully ordered, and in this case even transitivity is
> > provided.
> > 
> > I'm stating that the order of M and N don't matter, only the
> > load/stores that are inside the acquire/release are constrained.
> 
> No argument here.
> 
> > IOW, I think smp_mb__after_unlock_lock() already works as advertised
> > with all our acquire/release thingies -- as is stated by the
> > documentation.
> > 
> > That said, I'm not aware of anybody but RCU actually using this, so its
> > not used in that capacity.
> 
> OK, I might actually understand what you are getting at.  And, yes, if
> someone actually comes up with a need to combine smp_mb__after_unlock_lock()
> with something other than locking, we should worry about it at that point.
> And probably rename smp_mb__after_unlock_lock() at that point, as well.
> Until then, why lock ourselves into semantics that no one needs, and
> that it is quite possible that no one will ever need?

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
memory-barrier API?

My main reason for proposing its removal is because I don't want to see
it being used (incorrectly) all over the place to order the new RELEASE
and ACQUIRE operations I posted separately, at which point we have to try
fixing up all the callers or retrofitting some semantics. It doesn't help
that memory-barriers.txt lumps things like LOCK and ACQUIRE together,
whereas this barrier is currently only intended to be used in conjunction
with the former.

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

Back to linux.kernel | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

[RFC PATCH v2] memory-barriers: remove smp_mb__after_unlock_lock() Will Deacon <will.deacon@arm.com> - 2015-07-13 14:20 +0200
  Re: [RFC PATCH v2] memory-barriers: remove  smp_mb__after_unlock_lock() Peter Zijlstra <peterz@infradead.org> - 2015-07-14 10:40 +0200
  Re: [RFC PATCH v2] memory-barriers: remove  smp_mb__after_unlock_lock() Will Deacon <will.deacon@arm.com> - 2015-07-14 12:10 +0200
    Re: [RFC PATCH v2] memory-barriers: remove  smp_mb__after_unlock_lock() "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> - 2015-07-14 21:40 +0200
      Re: [RFC PATCH v2] memory-barriers: remove  smp_mb__after_unlock_lock() "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> - 2015-07-15 03:40 +0200
        Re: [RFC PATCH v2] memory-barriers: remove  smp_mb__after_unlock_lock() Will Deacon <will.deacon@arm.com> - 2015-07-15 13:00 +0200
          Re: [RFC PATCH v2] memory-barriers: remove  smp_mb__after_unlock_lock() "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> - 2015-07-15 15:20 +0200
  Re: [RFC PATCH v2] memory-barriers: remove  smp_mb__after_unlock_lock() Michael Ellerman <mpe@ellerman.id.au> - 2015-07-15 05:10 +0200
    Re: [RFC PATCH v2] memory-barriers: remove  smp_mb__after_unlock_lock() Will Deacon <will.deacon@arm.com> - 2015-07-15 12:50 +0200
      Re: [RFC PATCH v2] memory-barriers: remove  smp_mb__after_unlock_lock() Michael Ellerman <mpe@ellerman.id.au> - 2015-07-16 04:10 +0200
        Re: [RFC PATCH v2] memory-barriers: remove  smp_mb__after_unlock_lock() "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> - 2015-07-16 17:20 +0200
          Re: [RFC PATCH v2] memory-barriers: remove  smp_mb__after_unlock_lock() Benjamin Herrenschmidt <benh@kernel.crashing.org> - 2015-07-17 01:00 +0200
            Re: [RFC PATCH v2] memory-barriers: remove  smp_mb__after_unlock_lock() Will Deacon <will.deacon@arm.com> - 2015-07-17 11:40 +0200
              Re: [RFC PATCH v2] memory-barriers: remove  smp_mb__after_unlock_lock() Peter Zijlstra <peterz@infradead.org> - 2015-07-17 12:20 +0200
                Re: [RFC PATCH v2] memory-barriers: remove  smp_mb__after_unlock_lock() "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> - 2015-07-17 14:50 +0200
              Re: [RFC PATCH v2] memory-barriers: remove  smp_mb__after_unlock_lock() Benjamin Herrenschmidt <benh@kernel.crashing.org> - 2015-07-18 00:20 +0200
                Re: [RFC PATCH v2] memory-barriers: remove  smp_mb__after_unlock_lock() Will Deacon <will.deacon@arm.com> - 2015-07-20 15:40 +0200
                Re: [RFC PATCH v2] memory-barriers: remove  smp_mb__after_unlock_lock() "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> - 2015-07-20 15:50 +0200
                Re: [RFC PATCH v2] memory-barriers: remove  smp_mb__after_unlock_lock() Will Deacon <will.deacon@arm.com> - 2015-07-20 16:00 +0200
    Re: [RFC PATCH v2] memory-barriers: remove  smp_mb__after_unlock_lock() "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> - 2015-07-15 16:20 +0200
      Re: [RFC PATCH v2] memory-barriers: remove  smp_mb__after_unlock_lock() Michael Ellerman <mpe@ellerman.id.au> - 2015-07-16 03:40 +0200

csiph-web